{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/authorization","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/authorization/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/authorization/"},"term":{"en":"Authorization","da":"Autorisation"},"aka":{"en":["authz","authorisation"],"da":["autorisering"]},"domain":["cs","security"],"cluster":"identity","layer":"identity","status":"current","summary":{"en":"Deciding what an already identified user is allowed to do, such as which files they may open or change.","da":"At afgøre, hvad en allerede identificeret bruger har lov til, fx hvilke filer vedkommende må åbne eller ændre."},"body":{"formal":{"en":"The decision, made after authentication, whether a given identity may perform a given action on a given resource, based on its permissions, roles or other rules.","da":"Afgørelsen, der træffes efter autentificering, om en given identitet må udføre en bestemt handling på en bestemt ressource, ud fra dens rettigheder, roller eller andre regler."},"plain":{"en":"Like the coloured band on your wrist at a festival - the gate already knows who you are, and the colour decides whether you may go backstage.","da":"Som armbåndet på en festival - indgangen ved allerede, hvem du er, og farven på armbåndet afgør, om du må komme backstage."},"inPractice":{"en":"A case officer at a municipal citizen service desk is logged in, but when she tries to open the payroll folder, the system checks her permissions and refuses, because only HR staff may read it.","da":"En sagsbehandler i en kommunes borgerservice er logget ind, men da hun prøver at åbne lønmappen, tjekker systemet hendes rettigheder og afviser hende, fordi kun HR må læse den."},"whyItMatters":{"en":"When authorization grants more than people need, a single stolen login or careless employee can expose far more data than necessary.","da":"Når autorisationen giver mere, end folk har brug for, kan ét stjålet login eller én uforsigtig medarbejder blotlægge langt flere data end nødvendigt."}},"deepDive":{"en":"Formally, an authorization decision is a function of subject, action, resource and context that returns permit or deny, sometimes with obligations such as \"log this\" or \"mask these fields\". How that function is expressed defines the model: access control lists attached to resources, roles in RBAC, attribute rules in ABAC (NIST SP 800-162), or relationship tuples in ReBAC. Google's Zanzibar paper (USENIX ATC 2019) stores tuples of the form object#relation@user and evaluates permissions by walking that graph; it introduced consistency tokens (\"zookies\") to avoid the \"new enemy\" problem, where a check runs against a snapshot older than a just-made revocation. Policy languages include OASIS XACML 3.0, Open Policy Agent's Rego and Cedar.\n\nDecisions are usually layered. Coarse checks at an API gateway or middleware look at the route and the token's scopes; fine-grained checks inside the service look at the specific object and its owner or tenant. OAuth scopes limit what a client has been delegated, not what the user is allowed to do, so the effective right is the intersection of both. Claims baked into a JWT at issuance stay valid until expiry even if the user's rights are revoked, which is why sensitive systems combine short token lifetimes with token introspection (RFC 7662) or a live policy lookup, and use token exchange (RFC 8693) instead of forwarding a broad token to downstream services.\n\nThe dominant failure mode is a missing object-level check. OWASP API Security Top 10 2023 ranks Broken Object Level Authorization as API1, Broken Object Property Level Authorization (including mass assignment) as API3 and Broken Function Level Authorization as API5; for web applications, Broken Access Control is A01 in OWASP Top 10:2021 and 2025. Typical bugs are taking a tenant or user ID from the request body instead of the authenticated token, enforcing rules only in the user interface, and trusting client-side role flags. The confused deputy pattern appears when a service authorises a request against its own broad rights rather than the caller's.\n\nIn control catalogues, NIST SP 800-53 Rev. 5 places enforcement under AC-3 (Access Enforcement), separation of duties under AC-5 and least privilege under AC-6. HTTP mirrors the boundary with authentication, although confusingly named: status 401 \"Unauthorized\" means the request lacks valid authentication, whereas 403 \"Forbidden\" means the server understood who is asking and refuses (RFC 9110 §15.5.2 and §15.5.4). Authorization always presupposes authentication, but a strong login says nothing about whether a particular request should be allowed.","da":"Formelt er en autorisationsbeslutning en funktion af subjekt, handling, ressource og kontekst, der returnerer tilladt eller afvist, nogle gange med forpligtelser som \"log dette\" eller \"maskér disse felter\". Måden, funktionen udtrykkes på, definerer modellen: adgangskontrollister knyttet til ressourcerne, roller i RBAC, attributregler i ABAC (NIST SP 800-162) eller relationstupler i ReBAC. Googles Zanzibar-artikel (USENIX ATC 2019) gemmer tupler på formen objekt#relation@bruger og vurderer rettigheder ved at gennemløbe grafen; den indførte konsistens-tokens (\"zookies\") for at undgå \"new enemy\"-problemet, hvor et tjek køres mod et øjebliksbillede, der er ældre end en netop gennemført tilbagekaldelse. Politiksprog omfatter OASIS XACML 3.0, Open Policy Agents Rego og Cedar.\n\nBeslutningerne ligger typisk i lag. Grove tjek i en API-gateway eller middleware ser på ruten og tokenets scopes; finkornede tjek inde i tjenesten ser på det konkrete objekt og dets ejer eller tenant. OAuth-scopes begrænser, hvad en klient har fået delegeret, ikke hvad brugeren har lov til, så den reelle rettighed er fællesmængden af de to. Claims, der bages ind i et JWT ved udstedelsen, gælder til udløb, selv om brugerens rettigheder trækkes tilbage; derfor kombinerer følsomme systemer korte levetider med token-introspektion (RFC 7662) eller et live opslag i politikken og bruger token exchange (RFC 8693) i stedet for at sende et bredt token videre til bagvedliggende tjenester.\n\nDen dominerende fejl er en manglende kontrol på objektniveau. OWASP API Security Top 10 2023 placerer Broken Object Level Authorization som API1, Broken Object Property Level Authorization (herunder mass assignment) som API3 og Broken Function Level Authorization som API5; for webapplikationer er Broken Access Control A01 i OWASP Top 10:2021 og 2025. Typiske fejl er at tage tenant- eller bruger-id fra forespørgslens indhold i stedet for fra det autentificerede token, kun at håndhæve regler i brugergrænsefladen og at stole på rolleflag fra klienten. Confused deputy-mønsteret opstår, når en tjeneste godkender en forespørgsel ud fra sine egne brede rettigheder i stedet for kalderens.\n\nI kontrolkataloger placerer NIST SP 800-53 Rev. 5 håndhævelsen under AC-3 (Access Enforcement), funktionsadskillelse under AC-5 og mindste privilegium under AC-6. HTTP afspejler grænsen til autentificering, dog med forvirrende navne: Statuskode 401 \"Unauthorized\" betyder, at forespørgslen mangler gyldig autentificering, mens 403 \"Forbidden\" betyder, at serveren ved, hvem der spørger, og afviser (RFC 9110 §15.5.2 og §15.5.4). Autorisation forudsætter altid autentificering, men et stærkt login siger intet om, hvorvidt en bestemt forespørgsel bør tillades."},"edges":[{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"part-of","to":"cs/access-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/permission","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/zero-trust","why":{"en":"Zero Trust makes a fresh authorization decision for every single request.","da":"Zero Trust træffer en ny autorisationsbeslutning for hver eneste forespørgsel."},"confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations","url":"https://doi.org/10.6028/NIST.SP.800-162","tier":"standard","publisher":"NIST"}],"draft":true}