OpenID Connect

OpenID Connect, das Wesentliche

OAuth 2.0 gewährt Zugriff auf eine Ressource. OpenID Connect fügt Identität hinzu: wer die sich anmeldende Person ist.

OAuth 2.0 und OpenID Connect: der Unterschied

OAuth 2.0 beantwortet „Darf diese Anwendung auf diese Daten zugreifen?“ Es erzeugt ein Access-Token. Über die Person sagt es nichts.

OpenID Connect (OIDC) ist eine Identitätsschicht über OAuth 2.0. Es fügt ein Identitäts-Token (ID-Token), einen userinfo-Endpunkt und Standard-Scopes (openid, profile, email) hinzu. Wenn Sie den Scope openid anfordern, nutzen Sie OIDC; sonst reines OAuth.

Die Akteure

• Benutzer (Resource Owner): die Person.
• Client (RP, Relying Party): die Anwendung, die die Person kennen oder auf eine API zugreifen will.
• OIDC-Provider (OP, Authorization Server): Entra ID, Okta, Keycloak, Google… er authentifiziert und stellt die Tokens aus.
• API (Resource Server): empfängt das Access-Token und validiert es.

Die drei Tokens

• ID-Token: ein signiertes JWT, das sagt, wer sich angemeldet hat (sub), von wem ausgestellt (iss), für wen (aud = Ihre client_id), wann (iat, exp) und Ihre nonce zurückgibt. Es ist für die Anwendung bestimmt, nie für die API.
• Access-Token: der Schlüssel, den die Anwendung einer API vorlegt. Opak oder JWT, kurzlebig. Die Anwendung darf es nicht lesen.
• Refresh-Token: erlaubt, ein neues Access-Token zu erhalten, ohne die Person erneut zu fragen. Langlebig, wie ein Passwort zu schützen.

Die Endpunkte

/.well-known/openid-configuration	Discovery: ein JSON-Dokument, das alle anderen Endpunkte und die Fähigkeiten des Providers auflistet. Ein seriöser Client braucht nur die Adresse des Issuers.
jwks_uri	Die öffentlichen Schlüssel zur Prüfung der Token-Signatur (Rotation möglich).
authorization_endpoint	Wohin der Browser die Person zur Authentifizierung schickt.
token_endpoint	Wo die Anwendung einen Code (oder anderes) gegen Tokens tauscht, von Server zu Server.
userinfo_endpoint	Die Informationen der Person, mit einem Access-Token.
introspection, revocation	Prüfen, ob ein Token noch aktiv ist (RFC 7662); es ungültig machen (RFC 7009).
end_session_endpoint	Von der Anwendung angeforderte Abmeldung (RP-initiated Logout).
device_authorization_endpoint	Einen „Device“-Ablauf starten (RFC 8628).

Die Prüfungen eines seriösen Clients

Bei einem ID-Token: Signatur (Schlüssel aus jwks_uri), exakter iss, aud enthält seine client_id, exp nicht überschritten, nonce identisch mit der gesendeten, at_hash/c_hash, falls vorhanden. Bei der Antwort: identischer state und PKCE (code_verifier) beim Code-Flow.