{"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/oauth","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/oauth/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/oauth/"},"term":{"en":"OAuth","da":"OAuth"},"aka":{"en":["OAuth 2.0"],"da":["OAuth 2.0"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","era":2007,"summary":{"en":"A way to let one app act on your behalf in another service, with a limited pass instead of your password.","da":"En måde at lade én app handle på dine vegne i en anden tjeneste med et begrænset adgangsbevis i stedet for din adgangskode."},"body":{"formal":{"en":"An open standard for delegated authorization in which the owner of an account approves a limited request, and a trusted server then hands the requesting app a short-lived access token that its API accepts in place of the owner's credential.","da":"En åben standard for delegeret autorisation, hvor ejeren af en konto godkender en begrænset forespørgsel, hvorefter en betroet server giver den app, der beder om adgang, et kortlivet adgangstoken, som API'et godtager i stedet for ejerens loginoplysninger."},"plain":{"en":"Like a valet key for a car - it lets the attendant drive and park, but not open the boot or the glove box, and you never hand over your own key.","da":"Som en parkeringsnøgle til en bil - den lader betjenten køre og parkere, men ikke åbne bagagerummet eller handskerummet, og du afleverer aldrig din egen nøgle."},"inPractice":{"en":"A teacher at a Danish school connects a lesson-planning app to her Google calendar; she approves “read your calendar” on Google's own page, and the app gets a token that can read events but not her email.","da":"En lærer på en dansk skole kobler en app til lektionsplanlægning til sin Google-kalender; hun godkender “læs din kalender” på Googles egen side, og appen får et token, der kan læse aftaler, men ikke hendes mails."},"whyItMatters":{"en":"Before it, people typed their real password into third-party apps; now access can be narrow, time-limited and taken back without changing the password.","da":"Før det tastede folk deres rigtige adgangskode ind i fremmede apps; nu kan adgangen begrænses i både omfang og tid og trækkes tilbage, uden at adgangskoden skal skiftes."}},"deepDive":{"en":"OAuth 1.0 began as a community specification in 2007 and was published as RFC 5849 in 2010; every request was signed with the client's and token's secrets. OAuth 2.0 (RFC 6749, October 2012) dropped request signing in favour of bearer tokens protected by TLS (RFC 6750) and became a framework rather than a single protocol. RFC 6749 §1.1 defines four roles: resource owner, client, authorization server (AS) and resource server (RS). It defines four grants: authorization code (§4.1), implicit (§4.2), resource owner password credentials (§4.3) and client credentials (§4.4), plus refresh tokens (§6). Later RFCs added the device authorization grant for input-constrained devices (RFC 8628), token exchange (RFC 8693) and guidance for native apps (RFC 8252).\n\nThe authorization code flow with PKCE is now the default for almost every client. The client generates a random code_verifier and redirects the browser to the AS's authorize endpoint with response_type=code, client_id, an exactly registered redirect_uri, the requested scope, a state value against CSRF and a code_challenge, the SHA-256 hash of the verifier (RFC 7636, method S256). After the user authenticates and consents, the AS redirects back with a short-lived, single-use code. The client redeems it at the token endpoint with the code_verifier and, if confidential, its client authentication, and receives an access token, usually with a refresh token. Because the verifier never travelled through the browser, an intercepted code cannot be redeemed.\n\nRFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025), codifies the lessons: PKCE for all clients, exact string matching of redirect URIs, no implicit grant and no password grant, refresh-token rotation or sender-constraining for public clients, and defences against mix-up attacks such as the iss response parameter (RFC 9207). Sender-constrained tokens bind the token to a key the client holds, via mutual TLS (RFC 8705) or DPoP (RFC 9449), so a stolen token alone is not enough. Access tokens may be opaque and checked through introspection (RFC 7662), or self-contained JWTs (RFC 9068); revocation is standardised in RFC 7009. The OAuth 2.1 effort folds these practices into one consolidated document.\n\nOAuth is delegated authorization, not authentication. An access token is addressed to the resource server, so a client that treats \"I received a token\" as proof of who the user is can be fooled by a token issued to a different application; OpenID Connect's audience-bound ID token closes that gap. Other recurring problems are overly broad scopes, long-lived refresh tokens stored insecurely, leaked codes through open redirectors or Referer headers, and illicit consent grants, where users are tricked into authorising an attacker-registered app with mail or file scopes, which is why many tenants restrict user consent to verified publishers or low-risk permissions.","da":"OAuth 1.0 begyndte som en fællesskabsspecifikation i 2007 og blev udgivet som RFC 5849 i 2010; hver forespørgsel blev signeret med klientens og tokenets hemmeligheder. OAuth 2.0 (RFC 6749, oktober 2012) droppede signering af forespørgsler til fordel for bearer-tokens beskyttet af TLS (RFC 6750) og blev et rammeværk frem for én enkelt protokol. RFC 6749 §1.1 definerer fire roller: ressourceejer, klient, autorisationsserver (AS) og ressourceserver (RS). Den definerer fire grant-typer: authorization code (§4.1), implicit (§4.2), resource owner password credentials (§4.3) og client credentials (§4.4) samt refresh-tokens (§6). Senere RFC'er tilføjede device authorization grant til enheder med begrænset input (RFC 8628), token exchange (RFC 8693) og vejledning til native apps (RFC 8252).\n\nAuthorization code-flowet med PKCE er nu standardvalget for næsten alle klienter. Klienten genererer en tilfældig code_verifier og sender browseren til AS'ens authorize-endpoint med response_type=code, client_id, en præcist registreret redirect_uri, det ønskede scope, en state-værdi mod CSRF og en code_challenge, som er SHA-256-hashen af verifieren (RFC 7636, metoden S256). Når brugeren har autentificeret sig og givet samtykke, sender AS'en browseren tilbage med en kortlivet engangskode. Klienten indløser koden på token-endpointet med code_verifier og, hvis den er fortrolig, sin klientautentificering, og modtager et adgangstoken, som regel sammen med et refresh-token. Da verifieren aldrig har været gennem browseren, kan en opsnappet kode ikke indløses.\n\nRFC 9700, OAuth 2.0 Security Best Current Practice (januar 2025), samler erfaringerne: PKCE for alle klienter, eksakt strengsammenligning af redirect-URI'er, ingen implicit grant og ingen password grant, rotation eller afsenderbinding af refresh-tokens for offentlige klienter og forsvar mod mix-up-angreb som iss-parameteren i svaret (RFC 9207). Afsenderbundne tokens binder tokenet til en nøgle, klienten har, via gensidig TLS (RFC 8705) eller DPoP (RFC 9449), så et stjålet token ikke er nok alene. Adgangstokens kan være uigennemsigtige og kontrolleres via introspektion (RFC 7662) eller være selvindeholdte JWT'er (RFC 9068); tilbagekaldelse er standardiseret i RFC 7009. Arbejdet med OAuth 2.1 samler denne praksis i ét konsolideret dokument.\n\nOAuth er delegeret autorisation, ikke autentificering. Et adgangstoken er rettet mod ressourceserveren, så en klient, der opfatter \"jeg har fået et token\" som bevis for, hvem brugeren er, kan narres med et token, der er udstedt til en anden applikation; OpenID Connects audience-bundne ID-token lukker det hul. Andre tilbagevendende problemer er for brede scopes, langlivede refresh-tokens, der opbevares usikkert, lækkede koder via åbne redirects eller Referer-headere og ulovlige samtykker (illicit consent grants), hvor brugere narres til at godkende en app, som angriberen har registreret, med adgang til mail eller filer; derfor begrænser mange tenants brugernes samtykke til verificerede udgivere eller rettigheder med lav risiko."},"edges":[{"type":"requires","to":"cs/access-control","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/api","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/account","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/authorization","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/saas","why":{"en":"Cloud services use it to let one online app reach data in another without sharing passwords.","da":"Cloudtjenester bruger det til at give én onlineapp adgang til data i en anden uden at dele adgangskoder."},"confidence":"high","strength":"normal"}],"depth":5,"sources":[{"title":"RFC 6749 - The OAuth 2.0 Authorization Framework","url":"https://www.rfc-editor.org/rfc/rfc6749","tier":"standard","publisher":"IETF"},{"title":"OAuth Core 1.0","url":"https://oauth.net/core/1.0/","tier":"official-doc"},{"title":"RFC 9700 - Best Current Practice for OAuth 2.0 Security","url":"https://www.rfc-editor.org/rfc/rfc9700","tier":"standard","publisher":"IETF"}],"draft":true}