OpenID Connect (OIDC)

OpenID Connect ist eine schlanke Identitätsschicht auf Basis von OAuth 2.0. OAuth beantwortet die Frage was kann diese App tun; OIDC beantwortet die Frage wer ist der Benutzer.

• Es standardisiert, wie Clients Benutzer authentifizieren und verifizierte Identitäts-Claims empfangen.
• Es führt den ID-Token als kryptografisch signierten Authentifizierungsnachweis ein.

Vor OIDC verwendeten Entwickler OAuth-Access-Tokens missbräuchlich für die Anmeldung. Das führte zu Confused-Deputy- und Identitätsvortäuschungsfehlern.

Das zentrale OIDC-Artefakt ist der ID-Token, ein signiertes JWT, das das Authentifizierungsereignis beschreibt.

• Er enthält Claims darüber, wer sich wann angemeldet hat.
• Er ist für den Client bestimmt, nicht für den Ressourcenserver.

Senden Sie einen ID-Token niemals als Zugriffsberechtigung an eine API und akzeptieren Sie ihn niemals, ohne seine Signatur und Claims zu validieren.

Die Validierung eines ID-Tokens bedeutet, bestimmte Claims zu prüfen, nicht nur die Signatur.

• Der iss-Issuer muss mit dem erwarteten IdP übereinstimmen.
• Die aud-Audience muss Ihre client_id enthalten.
• Das Token mit exp / iat darf nicht abgelaufen und muss kürzlich ausgestellt worden sein.
• sub ist eine stabile, eindeutige Benutzerkennung.
• nonce muss mit dem Wert übereinstimmen, den Ihr Client gesendet hat.

OIDC verwendet den Authorization-Code-Flow erneut, ergänzt ihn aber um den openid-Scope und eine nonce.

• Der Client fordert den Scope openid an, optional ergänzt um profile und email.
• Der Token-Endpunkt gibt neben dem Access-Token auch einen ID-Token zurück.
• Die nonce verknüpft den ID-Token mit der ursprünglichen Anfrage und verhindert Replay-Angriffe.

OIDC-Provider veröffentlichen ihre Signaturschlüssel an einem JWKS-Endpunkt, der über das Well-Known-Konfigurationsdokument auffindbar ist.

• Rufen Sie die Schlüssel über jwks_uri ab und gleichen Sie sie mit dem kid-Header des Tokens ab.
• Prüfen Sie die Signatur mit dem aufgeführten asymmetrischen Algorithmus (RS256, ES256).

Lehnen Sie den none-Algorithmus ab und vertrauen Sie niemals einem ausschließlich vom Token gelieferten Algorithmuswert.

Die nonce ist für ID-Tokens das, was state für den Redirect ist: ein einmaliger Wert, der die Antwort an die Anfrage bindet.

• Der Client erzeugt eine zufällige nonce und speichert sie in der Sitzung.
• Der IdP übernimmt sie in den ID-Token.
• Beim Empfang überprüft der Client, ob die nonce übereinstimmt und zuvor noch nicht verwendet wurde.

Dadurch werden Token-Replay und das Einschleusen eines für eine andere Sitzung ausgestellten Tokens verhindert.

Für zusätzliche Profildaten über den ID-Token hinaus definiert OIDC den UserInfo-Endpunkt.

• Der Client ruft ihn mit dem Access-Token auf, nicht mit dem ID-Token.
• Er gibt Claims wie Name, E-Mail-Adresse und Bild für das authentifizierte Subjekt zurück.

Gleichen Sie das zurückgegebene sub immer mit dem sub des ID-Tokens ab, um die Ersetzung von Claims zu verhindern.

OIDC standardisiert die Discovery, damit Clients Endpunkte und unterstützte Funktionen automatisch konfigurieren können.

• Das Dokument /.well-known/openid-configuration listet Endpunkte, unterstützte Scopes und Algorithmen auf.
• Legen Sie den Issuer fest oder validieren Sie ihn. Folgen Sie Discovery nicht blind von einem Host, der von einem Angreifer kontrolliert wird.

Discovery vereinfacht die Integration, aber der Issuer bleibt ein Vertrauensanker, den Sie überprüfen müssen.

Die Beendigung von Sitzungen über föderierte Apps hinweg wird durch die OIDC-Logout-Spezifikationen geregelt.

• Front-Channel-Logout verwendet Browser-Redirects und -iframes, um jede Relying Party abzumelden.
• Back-Channel-Logout sendet serverseitige Logout-Tokens. Er ist zuverlässiger, erfordert aber entsprechende Endpunkte.

Ohne koordiniertes Logout kann sich ein Benutzer aus einer App abmelden und gleichzeitig bei anderen angemeldet bleiben – ein reales Risiko für die Sitzungsverwaltung.

Identitätsfehler entstehen häufig dadurch, dass Validierungsschritte übersprungen werden.

• Tokens werden akzeptiert, ohne aud zu prüfen, obwohl das Token für einen anderen Client bestimmt ist.
• iss wird ignoriert, wodurch ein IdP-Spoofing ermöglicht wird.
• Die Signatur wird nicht validiert oder alg: none wird akzeptiert.
• ID-Tokens und Access-Tokens werden verwechselt.
• Fehlende Nonce-Prüfungen ermöglichen Replay-Angriffe.

Wenn Ihr Ziel die Anmeldung ist, verwenden Sie OIDC und nicht reines OAuth.

• OAuth-Access-Tokens sind für den Client undurchsichtig und beweisen nichts über die Identität.
• Ein Access-Token kann für einen anderen Benutzer oder eine andere App gültig sein. Wird er zur Anmeldung verwendet, kann dies zur Identitätsvortäuschung führen.
• OIDC-ID-Tokens sind ausdrücklich an eine Audience gebundene Identitätsnachweise.

Diese Unterscheidung verhindert den klassischen Confused-Deputy-Fehler bei der Authentifizierung.

Die wichtigsten Punkte:

• OIDC ergänzt OAuth 2.0 um eine Identitätsschicht; der ID-Token ist ein signiertes JWT, das die Authentifizierung nachweist.
• Validieren Sie immer iss, aud, exp, signature (via JWKS) und nonce.
• ID-Tokens sind für den Client bestimmt, Access-Tokens für APIs. Vertauschen Sie diese Rollen niemals.
• Verwenden Sie nonce gegen Replay und state gegen CSRF.
• Verwenden Sie OIDC und nicht reines OAuth, wenn Sie Benutzer authentifizieren müssen.