OpenID-Connect-Claims und ID-Tokens

OpenID Connect (OIDC) fügt OAuth 2.0 eine Identitätsschicht hinzu. Während OAuth 2.0 die Autorisierung regelt (auf welche Ressourcen darf diese App zugreifen?), beantwortet OIDC die Identitätsfrage (wer ist der Benutzer?). OIDC wird aktiviert, indem der Scope "openid" zu einer OAuth-2.0-Anfrage hinzugefügt wird. Dadurch gibt der Authorization Server neben dem Access-Token auch ein ID-Token zurück.

Das OIDC-ID-Token ist ein JSON Web Token (JWT), das Claims über den authentifizierten Benutzer enthält. Das JWT wird vom Authorization Server typischerweise mit dessen privatem Schlüssel signiert (RS256 oder ES256). Die Relying Party (Client-Anwendung) überprüft die Signatur mithilfe der veröffentlichten öffentlichen Schlüssel des Authorization Servers (JWKS-Endpunkt).

Erforderliche und häufig verwendete Claims eines ID-Tokens: "sub" (Subject, eindeutige Benutzerkennung), "iss" (Issuer, URL des Authorization Servers), "aud" (Audience, Client-ID), "exp" (Unix-Zeitstempel des Ablaufs), "iat" (Unix-Zeitstempel der Ausstellung). Optional: "auth_time" (Zeitpunkt der Authentifizierung), "nonce" (Schutz vor Replay-Angriffen), "at_hash" (Hash des Access-Tokens), "acr" (Klasse des Authentifizierungskontexts), "amr" (verwendete Authentifizierungsmethoden).

Der OIDC-UserInfo-Endpunkt gibt zusätzliche Claims über den authentifizierten Benutzer zurück, wenn er mit einem gültigen Access-Token aufgerufen wird. Clients fordern bestimmte Claim-Sätze über Scopes an: "profile" (Name, Bild, Sprache und Region), "email" (E-Mail-Adresse, Bestätigung der E-Mail-Adresse), "address" (formatierte Adresse), "phone" (Telefonnummer, Bestätigung der Telefonnummer). Die UserInfo-Antwort ist ein JSON-Objekt oder ein JWT.

Die Validierung eines ID-Tokens beginnt mit der Überprüfung der Signatur. Der Client ruft das JWKS (JSON Web Key Set) des Authorization Servers über den Well-Known-Endpunkt ab, sucht den Schlüssel, der zum "kid"-Parameter (Key-ID) im JWT-Header gehört, und überprüft die JWT-Signatur. Dadurch wird nachgewiesen, dass das Token vom legitimen Authorization Server ausgestellt und nicht manipuliert wurde.

Nach der Signaturprüfung muss der Client Folgendes validieren: "iss" muss exakt mit der erwarteten URL des Authorization Servers übereinstimmen (einschließlich Schema und Pfad). "aud" muss die eigene client_id des Clients enthalten. "exp" muss in der Zukunft liegen (abgelaufene Tokens werden abgelehnt). "iat" sollte ausreichend aktuell sein. Alle vier Prüfungen sind gemäß der OIDC-Spezifikation verpflichtend.

Der Claim nonce verhindert Replay-Angriffe mit ID-Tokens. Der Client erzeugt eine zufällige Nonce und fügt sie in die Autorisierungsanfrage ein. Der Authorization Server übernimmt die Nonce in das ID-Token. Der Client überprüft, ob die Nonce im ID-Token mit der gesendeten Nonce übereinstimmt. Dadurch wird verhindert, dass ein Angreifer, der ein ID-Token abfängt, es zur Authentifizierung in einer anderen Sitzung wiederverwendet.

Wenn OIDC den Implicit Flow verwendet (response_type=id_token), wird das ID-Token direkt im URL-Fragment zurückgegeben. Der Client muss at_hash (den Hash des Access-Tokens) validieren, um das Access-Token an das ID-Token zu binden. Ohne die Validierung von at_hash sind Angriffe durch das Austauschen des Access-Tokens möglich. Dies ist ein weiterer Grund dafür, dass der Implicit Flow als veraltet gilt.

OIDC definiert standardisierte Zuordnungen von Scopes zu Claims. Der Scope "openid" ist verpflichtend und gibt den Claim "sub" zurück. "profile" gibt name, given_name, family_name, nickname, picture, website, locale, zoneinfo und updated_at zurück. "email" gibt email und email_verified zurück. Das Anfordern unnötiger Scopes verstößt gegen das Prinzip der Datenminimierung und kann sensible Benutzerdaten offenlegen.

Bei der Implementierung einer OIDC-Anmeldung mit mehreren Providern (z. B. "Sign in with Google" und "Sign in with GitHub") sind Claim-Injection-Angriffe möglich. Wenn ein Angreifer bei Provider B ein Konto mit der E-Mail-Adresse eines Opfers erstellt, das Provider A verwendet, kann er möglicherweise Zugriff erlangen, wenn die Anwendung Konten ausschließlich anhand des E-Mail-Claims zusammenführt. Ordnen Sie Konten immer anhand des Paars (iss, sub) zu, nicht anhand der E-Mail-Adresse allein.

Der OIDC Hybrid Flow (response_type=code id_token) gibt sowohl einen Autorisierungscode als auch ein ID-Token vom Authorization-Endpunkt zurück. Das ID-Token ermöglicht eine sofortige Identitätsprüfung, während der Code über den Backchannel gegen Tokens eingetauscht wird. Dieser Flow wird verwendet, wenn der Client sofort Benutzerinformationen anzeigen muss, bevor der Token-Austausch über den Backchannel abgeschlossen ist.

Welche Kombination von Claims muss eine Relying Party in einem OIDC-ID-Token validieren?

OIDC fügt OAuth-2.0-Flows ein signiertes JWT-ID-Token hinzu. Validieren Sie die Signatur (JWKS), iss (exakte Übereinstimmung), aud (client_id), exp (nicht abgelaufen) und nonce (falls gesendet). Der UserInfo-Endpunkt stellt über Scopes zusätzliche Claims bereit. Ordnen Sie Konten anhand des Paars (iss, sub) zu, niemals nur anhand der E-Mail-Adresse, um Claim-Injection zu verhindern. Der Implicit Flow gilt als veraltet; verwenden Sie für OIDC den Authorization Code Flow mit PKCE.