{"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/openid-connect","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/openid-connect/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/openid-connect/"},"term":{"en":"OpenID Connect (OIDC)","da":"OpenID Connect (OIDC)"},"aka":{"en":["OIDC"],"da":["OIDC"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","era":2014,"summary":{"en":"A login standard built on top of OAuth that tells an app who the user is, not just what it may do.","da":"En loginstandard bygget oven på OAuth, der fortæller en app, hvem brugeren er, og ikke kun hvad den må."},"body":{"formal":{"en":"An identity layer on OAuth 2.0 in which the identity provider, after the user signs in, returns a signed ID token stating who the user is and when and how they logged in; the app checks it before starting its own session.","da":"Et identitetslag oven på OAuth 2.0, hvor identitetsudbyderen, når brugeren er logget ind, returnerer et signeret ID-token med oplysninger om, hvem brugeren er, og hvornår og hvordan vedkommende loggede ind. Appen kontrollerer tokenet, før den starter sin egen session."},"plain":{"en":"Like a valet key handed over together with a signed name badge - the key says what the holder may do with the car, the badge says who the holder is.","da":"Som en parkeringsnøgle, der udleveres sammen med et underskrevet navneskilt - nøglen siger, hvad indehaveren må gøre med bilen, skiltet siger, hvem indehaveren er."},"inPractice":{"en":"A small Danish web shop offers “Sign in with Google”; the shop receives a signed token with the customer's name and email address and never handles a password at all.","da":"En lille dansk webshop tilbyder “Log ind med Google”; shoppen modtager et signeret token med kundens navn og mailadresse og håndterer aldrig selv en adgangskode."},"whyItMatters":{"en":"Using OAuth alone for login led to serious mistakes; a shared, checked way to state identity lets small apps offer safe login and single sign-on without building their own.","da":"At bruge OAuth alene til login førte til alvorlige fejl; en fælles, kontrolleret måde at angive identitet på lader små apps tilbyde sikkert login og single sign-on uden at bygge deres eget."}},"deepDive":{"en":"OpenID Connect Core 1.0 was finalised by the OpenID Foundation in February 2014, replacing the earlier, incompatible OpenID 2.0. It is a profile of OAuth 2.0: a client requests the openid scope, and the provider returns an ID token next to the usual access token. Companion specifications cover Discovery (the /.well-known/openid-configuration document), Dynamic Client Registration and several logout mechanisms. In 2024 Core and eight related specifications were published as international standards ISO/IEC 26131 to 26139, with Core incorporating errata set 2.\n\nThe ID token is a JWT signed with JWS (optionally also encrypted). Core §2 requires the claims iss (issuer), sub (subject identifier, locally unique within the issuer and at most 255 ASCII characters), aud (which must contain the client_id), exp and iat, and defines auth_time, nonce, acr (authentication context class), amr (authentication methods) and azp (authorised party). Validation per §3.1.3.7 means checking that iss exactly matches the expected issuer, aud contains the client, the signature verifies with a key from the provider's JWKS using the expected algorithm, the token has not expired and the nonce matches the one the client sent. The only stable user key is the iss plus sub pair; email and preferred_username can change, and an email claim is not proof of ownership unless email_verified is true and the provider is authoritative for that domain.\n\nThree flows are defined: authorization code (response_type=code), implicit (id_token or id_token token) and hybrid (for example code id_token). Current practice, reflected in the OAuth security BCP, is the code flow with PKCE for every client type, with the ID token fetched from the token endpoint. Request parameters give the relying party control: prompt=login and max_age force reauthentication, and acr_values asks for a particular assurance level, which the RP must then verify in the returned acr claim rather than assume. Profiles such as FAPI 2.0 tighten these rules for open banking and similar high-risk APIs.\n\nCommon implementation errors are accepting an OAuth access token as proof of login, skipping audience or issuer checks (especially on multi-tenant endpoints, where the tenant claim must also be validated), omitting the nonce, and algorithm confusion, where a library accepts alg \"none\" or verifies an RS256 token as HS256 using the public key as an HMAC secret. Logout is the weak area: RP-Initiated, Front-Channel and Back-Channel Logout exist, but browsers' blocking of third-party cookies breaks iframe-based session checks and front-channel logout, so back-channel logout tokens are the more reliable choice. Compared with SAML, OIDC uses compact JSON and JWTs over simple redirects and suits single-page, mobile and API scenarios better, while SAML keeps a strong foothold in enterprise SaaS.","da":"OpenID Connect Core 1.0 blev færdiggjort af OpenID Foundation i februar 2014 og afløste det tidligere, inkompatible OpenID 2.0. Det er en profil af OAuth 2.0: En klient beder om scopet openid, og udbyderen returnerer et ID-token ved siden af det sædvanlige adgangstoken. Tilhørende specifikationer dækker Discovery (dokumentet /.well-known/openid-configuration), Dynamic Client Registration og flere logud-mekanismer. I 2024 blev Core og otte beslægtede specifikationer udgivet som internationale standarder, ISO/IEC 26131 til 26139, hvor Core indeholder errata set 2.\n\nID-tokenet er et JWT, der er signeret med JWS (og eventuelt også krypteret). Core §2 kræver claims som iss (udsteder), sub (subjekt-id, lokalt unikt hos udstederen og højst 255 ASCII-tegn), aud (som skal indeholde client_id), exp og iat og definerer auth_time, nonce, acr (autentificeringskontekstklasse), amr (autentificeringsmetoder) og azp (autoriseret part). Validering efter §3.1.3.7 betyder at kontrollere, at iss præcist svarer til den forventede udsteder, at aud indeholder klienten, at signaturen kan verificeres med en nøgle fra udbyderens JWKS med den forventede algoritme, at tokenet ikke er udløbet, og at nonce svarer til den, klienten sendte. Den eneste stabile brugernøgle er parret iss og sub; email og preferred_username kan ændre sig, og et mail-claim er ikke bevis for ejerskab, medmindre email_verified er sand, og udbyderen er autoritativ for domænet.\n\nDer er defineret tre flows: authorization code (response_type=code), implicit (id_token eller id_token token) og hybrid (fx code id_token). Nuværende praksis, som også afspejles i OAuth's sikkerheds-BCP, er code-flowet med PKCE for alle klienttyper, hvor ID-tokenet hentes fra token-endpointet. Forespørgselsparametre giver relying partyen kontrol: prompt=login og max_age tvinger genautentificering, og acr_values beder om et bestemt sikringsniveau, som RP'en derefter skal kontrollere i det returnerede acr-claim i stedet for at antage det. Profiler som FAPI 2.0 strammer reglerne for open banking og lignende API'er med høj risiko.\n\nTypiske implementeringsfejl er at acceptere et OAuth-adgangstoken som bevis for login, at springe kontrol af audience eller udsteder over (især på multi-tenant-endpoints, hvor også tenant-claimet skal valideres), at udelade nonce og algoritmeforveksling, hvor et bibliotek accepterer alg \"none\" eller verificerer et RS256-token som HS256 med den offentlige nøgle som HMAC-hemmelighed. Logud er det svage punkt: RP-Initiated, Front-Channel og Back-Channel Logout findes, men browsernes blokering af tredjepartscookies ødelægger iframe-baserede sessionstjek og front-channel-logud, så back-channel-logud-tokens er det mere pålidelige valg. Sammenlignet med SAML bruger OIDC kompakt JSON og JWT'er over simple redirects og passer bedre til single-page-apps, mobil og API'er, mens SAML fortsat står stærkt i virksomheders SaaS."},"edges":[{"type":"requires","to":"cs/oauth","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/identity-provider","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/federation","confidence":"high","strength":"normal"},{"type":"alternative-to","to":"cs/saml","why":{"en":"Both let an identity provider vouch for a user to another app; OIDC uses light web tokens suited to mobile and modern apps, SAML older signed documents common in enterprise systems.","da":"Begge lader en identitetsudbyder gå i god for en bruger over for en anden app; OIDC bruger lette webtokens, der passer til mobil og moderne apps, SAML ældre signerede dokumenter, der er udbredt i virksomhedssystemer."},"confidence":"high","strength":"primary"}],"depth":6,"sources":[{"title":"OpenID Connect Core 1.0","url":"https://openid.net/specs/openid-connect-core-1_0.html","tier":"standard","publisher":"OpenID Foundation"},{"title":"ISO/IEC 26131:2024 - OpenID Connect Core 1.0 incorporating errata set 2","url":"https://www.iso.org/standard/89056.html","tier":"standard","publisher":"ISO/IEC"}],"draft":true}