OpenID Connect (OIDC)

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.

ID-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.

Der 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.

Typiske 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.