OpenID Connect (OIDC) ist eine Identity-Ebene, die auf OAuth 2.0 aufbaut und es Anwendungen ermöglicht, Benutzende zu authentifizieren und ihre Profilinformationen abzurufen. OAuth 2.0 übernimmt die Autorisierung (worauf Benutzende zugreifen können) und OIDC fügt Authentifizierung (wer Benutzende sind) hinzu, wobei standardisierte ID-Token verwendet werden.

Beispiel: Wenn Sie auf „Weiter mit Google“ klicken, um sich bei Spotify anzumelden, überprüft OIDC Ihre Identität bei Google. Spotify erhält Ihre Profilinformationen, z. B. Ihren Namen und Ihre E-Mail-Adresse. Ihr Google-Passwort wird niemals weitergegeben. Google stellt ein ID-Token aus, das Identity-Claims wie Ihre Benutzer-ID und Profilinformationen enthält. Einige Claims (z. B. die E-Mail-Verifizierung) sind ausdrücklich als verifiziert gekennzeichnet.

OIDC ist für die Authentifizierung moderner mobiler und Web-Anwendungen weit verbreitet. Das Protokoll wurde 2014 von der OpenID Foundation veröffentlicht und kombiniert OAuth 2.0-Autorisierung mit Identitätsprüfung. Große Identity-Anbieter unterstützen OIDC, weshalb es häufig für Single Sign-On (SSO), Social Login und Consumer-Apps verwendet wird.

Vor OIDC standen Entwicklungsteams vor drei großen Herausforderungen:

1. Fehlen einer standardisierten Identity-Ebene

   OAuth 2.0 bietet Autorisierung, definiert aber keine standardisierte oder interoperable Authentifizierungsmethode. Dadurch entwickelten Entwicklungsteams maßgeschneiderte Lösungen, was zu Interoperabilitätsproblemen führte.

2. Komplexe Alternativen

   SAML 2.0 unterstützt Unternehmensauthentifizierung, verwendet aber ausführliches XML, erfordert Zertifikate und funktioniert schlecht auf Mobilgeräten.

3. Risiko von Anmeldedaten-Kompromittierung

   In der Vergangenheit speicherten Anwendungen oft Anmeldedaten oder erforderten das Weitergeben von Passwörtern, was zu Sicherheitsrisiken und einer unterdurchschnittlichen User Experience führte.

OIDC befasst sich mit diesen Problemen, d. h. Anwendungen erhalten kryptografisch signierte ID-Token mit Identity-Claims. Die Speicherung von Anmeldedaten ist nicht mehr erforderlich, und die Authentifizierung ist plattformübergreifend konsistent. OIDC authentifiziert Benutzende, verwaltet aber keine anwendungsspezifischen Benutzerdaten, Rollen oder Berechtigungen.

OIDC baut auf OAuth 2.0-Rollen und Identity-spezifischer Terminologie auf:

• End User: Die Person, deren Identität überprüft wird.
• Relying Party (RP): Die Anwendung, die eine Benutzerauthentifizierung anfordert.
• OpenID Provider (OP): Der Identity-Anbieter, der Benutzende authentifiziert und ID-Token ausstellt. In OIDC fungiert der OP als OAuth 2.0-Autorisierungsserver.

ID-Token-Claims

ID-Token sind JSON Web Token (JWTs), die Identity-Claims enthalten und vor der Verwendung validiert werden müssen:

• sub: Stabile, eindeutige Kennung, die der Aussteller für den Benutzenden verwendet
• iss: Token-Aussteller (OpenID Provider-URL)
  aud: beabsichtigte Anwendung (Client-ID)
• exp: Ablaufzeitpunkt (Unix-Zeitstempel)
• iat: Ausgestellt zum Zeitpunkt (Unix-Zeitstempel)
• auth_time: Zeitstempel der Authentifizierung
• nonce: Verhindert Replay-Angriffe (erforderlich, wenn in der Anfrage gesendet)

Allgemeine OIDC-Berechtigungsbereiche

Scopes (Berechtigungsbereiche) definieren die angeforderten Benutzerinformationen:

• openid: Erforderlich; löst OIDC aus
• profile: Name, Bild und grundlegende Profilinformationen
• email: E-Mail-Adresse und Verifizierung
• address: Physische Adresse
• phone: Telefonnummer und Verifizierung

Da OIDC das Protokoll OAuth 2.0 erweitert, ähnelt der Ablauf dem Autorisierungscode-Ablauf von OAuth mit OIDC-spezifischen Ergänzungen.

Der OIDC-Authentifizierungsablauf

1. Authentifizierungsanfrage: RP leitet den Benutzenden mit Client-ID, Redirect-URI, response_type=code und Berechtigungsbereich einschließlich openID an den OP weiter.
2. Benutzerauthentifizierung und Zustimmung: Der OP authentifiziert den Benutzenden per Passwort, MFA oder anhand biometrischer Daten. Der Zustimmungsbildschirm zeigt die angeforderten Daten.
3. Autorisierungsantwort: Der OP leitet mit einem Autorisierungscode und einem Status-Parameter zurück.
   Token-Anfrage: RP tauscht einen Code gegen drei Token aus: ein ID-Token, ein Access Token und ein optionales Refresh Token. Vertrauliche Clients machen das serverseitig. Öffentliche Clients verwenden PKCE.
4. Token-Validierung: RP validiert die Token-Signatur, den Ablaufzeitpunkt, den Aussteller, die Zielgruppe und die Nonce mithilfe der öffentlichen Schlüssel des Anbieters (JWKS). Das ID-Token ist nur für die Client-Anwendung bestimmt und darf niemals an APIs gesendet werden. APIs sollten stattdessen Access Token validieren.
5. Zugriff auf das Benutzerprofil: Optional ruft RP den UserInfo-Endpoint mit einem Access Token auf, um zusätzliche Profil-Claims abzurufen.

Proof Key for Code Exchange (PKCE)

PKCE verhindert Angriffe zum Abfangen von Autorisierungscodes. Öffentliche Clients (mobile Apps und SPAs) verwenden PKCE, da sie Client-Secrets nicht sicher speichern können. Vertrauliche Clients authentifizieren sich in der Regel mit einem Client-Secret. Viele moderne Bereitstellungen fügen auch PKCE hinzu, um lückenlosen Schutz zu erzielen.

Stellen Sie fest, welcher Ablauf verwendet werden soll:

Ablauf	Anwendungsfälle	Sicherheit	Status
Autorisierungscode mit PKCE	Alle modernen Apps (Web, Mobile, SPAs)	Höchste	Für alle Clients empfohlen
Impliziter Ablauf	none	Gering	Veraltet (RFC 8252)
Hybrider Ablauf	Komplexe Unternehmen	Mittel	Nur Legacy

• Autorisierungscode mit PKCE ist die empfohlene Best Practice und wird voraussichtlich in OAuth 2.1 obligatorisch sein.
• Implizierter Ablauf ist aufgrund von Sicherheitslücken veraltet.
• Hybrider Ablauf wird hauptsächlich in Legacy- und speziellen Unternehmensszenarien verwendet und ist in der Regel für die meisten modernen Anwendungen nicht erforderlich.

ID-Token-Validierung

ID-Token müssen für Signatur, Ablauf, Aussteller, Zielgruppe und Nonce validiert werden.

Validierungsschritte:

• Signatur mit JWKS-Schlüsseln überprüfen
• Prüfen, ob der Aussteller mit dem Anbieter übereinstimmt
• Sicherstellen, dass die Zielgruppe mit der Client-ID übereinstimmt
• Bestätigen, dass das Token nicht abgelaufen ist
• Prüfen, ob die Nonce mit der Anfrage übereinstimmt

Best Practice: Verwenden Sie etablierte OIDC-Bibliotheken, die die Validierung übernehmen.

Nonce-Handhabung

Nonce verhindert Replay-Angriffe. Angreifende könnten ein gültiges ID-Token ohne Nonce erneut abspielen. Vorhersehbare, wiederverwendete oder nicht verifizierte Nonces sind unsicher.

Best Practice: Generieren Sie kryptografisch zufällige Nonces, speichern Sie sie serverseitig mit TTL (5–10 Minuten) und validieren Sie exakte Übereinstimmungen.

Token-Speicherung

ID-Token enthalten sensible Informationen. Verwenden Sie daher niemals localStorage oder sessionStorage, um Cross-Site-Scripting-Schwachstellen (XSS) zu vermeiden.

Best Practice: Verwenden Sie In-Memory-Speicher für SPAs oder sichere HttpOnly-Cookies, wenn Sie ein BFF-Muster (Backend-for-Frontend) verwenden. Serverseitig verschlüsselte Sessions sind sicherer.

Berechtigungsbereiche für Anfragen

Fordern Sie nur die Berechtigungsbereiche an, die Ihre App benötigt. Vermeiden Sie unnötige Profildaten.

UserInfo-Endpoint-Nutzung

Rufen Sie UserInfo nur ab, wenn dem ID-Token die erforderlichen Claims fehlen. Der Endpoint erfordert ein Access Token und ist oft ratenbegrenzt. Validieren Sie Access Token immer und speichern Sie Antworten nach Bedarf im Cache.

OIDC eignet sich am besten für Consumer-Apps, mobile Anwendungen und moderne Webauthentifizierung. Wählen Sie OIDC für Social Login, SSO und Szenarien, in denen sich Benutzende mit bestehenden Accounts authentifizieren.

SAML 2.0 ist in Legacy-Unternehmens- und Behördensystemen nach wie vor üblich, während OIDC zunehmend für neue Personalanwendungen eingesetzt wird. Viele Unternehmen verwenden beides: OIDC für moderne Anwendungen und SAML für Enterprise Federation.

• Validieren Sie ID-Token vollständig mit JWKS-Schlüsseln. Überprüfen Sie Signatur, exp, iss, aud und nonce. (ID-Token dürfen niemals an APIs gesendet werden.)
• Verwenden Sie HTTPS für die gesamte Kommunikation in Produktionsumgebungen. RFC 6749 erlaubt Ausnahmen für localhost nur zu Entwicklungszwecken.
• Implementieren Sie PKCE für alle Clients. (Wird voraussichtlich in OAuth 2.1 verpflichtend sein.)
• Implementieren Sie die sichere Token-Speicherung mit HttpOnly-Cookies oder serverseitigen Sessions.
• Validieren Sie Umleitungs-URIs explizit. Verwenden Sie niemals Platzhalter.
• Implementieren Sie den Statusparameter, um CSRF-Angriffe zu verhindern.
• Verwenden Sie kurzlebige Token (15–60 Minuten) und Refresh Token mit Rotation.
• Respektieren Sie die Zustimmung der Benutzenden und minimieren Sie die angeforderten Profildaten.

Aspekt	OIDC	OAuth 2.0	SAML 2.0
Zweck	Authentifizierung	Autorisierung	Authentifizierung und SSO
Basis	OAuth 2.0	IETF OAuth-Spezifikationen	XML-basierte SAML-Standards
Token-Format	JWT	Bearer Token (Format nicht spezifiziert)	XML
Identity-Claims	Standardisiert	Nicht definiert	Attributaussagen
Unterstützung für Mobilgeräte	Sehr gut	Sehr gut	Schlecht
Anwendungsfälle	Benutzerauthentifizierung, Social Login	API-Zugriff	Enterprise SSO
Komplexität	Gering	Gering	Hoch
Zielgruppe	Moderne Anwendungen	APIs	Enterprise Federation

OIDC und OAuth 2.0 ergänzen sich gegenseitig. OIDC beantwortet die Frage: „Wer ist dieser Benutzende?“ OAuth 2.0 beantwortet die Frage: „Worauf kann dieser Benutzende zugreifen?“ SAML wird häufig für Enterprise SSO verwendet. OIDC wird für moderne Anwendungen und mobilen Support bevorzugt.

Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?

OAuth 2.0 ist für die Autorisierung verantwortlich. OIDC fügt zusätzlich eine Authentifizierungsebene hinzu. OAuth beantwortet die Frage: „Worauf kann diese Anwendung zugreifen?“ OIDC beantwortet die Frage: „Wer ist dieser Benutzende?“

Was ist ein ID-Token und warum ist es wichtig?

Ein ID-Token ist ein signiertes JWT, das Identity-Claims des Anbieters enthält. Es beweist, dass die Authentifizierung stattgefunden hat. Im Gegensatz zu Access Token dient es der Verifizierung der Benutzeridentität durch den Client. Die Signatur ermöglicht die Validierung, ohne dass eine Kontaktaufnahme mit dem Anbieter erforderlich ist. Zu den häufigsten Angaben gehören Benutzer-ID (sub), E-Mail-Adresse und Authentifizierungszeitpunkt. Validieren Sie immer die ID-Token.

Kann ich OIDC ohne OAuth 2.0 verwenden?

Nein. OIDC basiert auf OAuth 2.0. Jeder OIDC-Ablauf ist ein OAuth 2.0-Ablauf, bei dem der openID-Berechtigungsbereich und das ID-Token hinzugefügt wurden. OIDC erweitert OAuth 2.0; es ersetzt es nicht.

Ist OIDC sicherer als SAML?

Beide sind sicher, sofern sie korrekt implementiert werden. OIDC verwendet eine einfachere JWT-Validierung. SAML erfordert XML-Signaturen, die komplexer sind. Die meisten Sicherheitslücken entstehen durch Implementierungsfehler, nicht durch das Protokoll selbst. Das einfachere Token-Format von OIDC hilft, das Implementierungsrisiko zu reduzieren.

Was ist der UserInfo-Endpoint?

Der UserInfo-Endpoint gibt zusätzliche Benutzerprofil-Claims zurück und erfordert ein gültiges Access Token, nicht das ID-Token. Verwenden Sie den UserInfo-Endpoint nur, wenn das ID-Token nicht die erforderlichen Claims enthält. Der Endpoint ist oft ratenbegrenzt. Speichern Sie daher Antworten im Cache, um die Leistung zu verbessern.

Muss ich ID-Token von einem vertrauenswürdigen Anbieter validieren?

Ja. Validieren Sie immer die Signatur, den Aussteller, die Zielgruppe, das Ablaufdatum und das Nonce. Die Validierung stellt sicher, dass das Token echt, aktuell und für Ihre Anwendung bestimmt ist. Sogar Token von vertrauenswürdigen Anbietern müssen validiert werden, um Manipulationen und Replay-Angriffe zu verhindern.

Kann OIDC ohne HTTPS funktionieren?

Nein. Für den Produktivbetrieb ist HTTPS erforderlich. Angreifende können Token abfangen, die über HTTP gesendet werden. Ausnahmen für localhost sind nur zu Entwicklungszwecken zulässig.

Verwendung von OIDC-Bibliotheken

Ausgereifte Bibliotheken übernehmen die Token-Validierung, die JWKS-Schlüsselverwaltung und die Protokolldetails. Bibliotheken können helfen, Fehler zu reduzieren, aber sie benötigen ein Verständnis der OIDC-Konzepte.

Zu den beliebten Open-Source-Bibliotheken gehören:

• Node.js: OpenID-Client
• Python: authlib
• Python: pyoidc
• Java: Spring Security OAuth

Verwendung von Identity-Plattformen

Identity-Plattformen bieten OIDC- und OAuth 2.0-Implementierungen mit integrierten Funktionen für Sicherheit, Social Login und Protokollübersetzung. Sie können auch Updates, Compliance und Skalierung verwalten, sodass sich Entwicklungsteams auf die Anwendungslogik konzentrieren können.

Auth0 optimiert OIDC- und OAuth 2.0-Implementierungen und ermöglicht es Entwicklungsteams, sich auf die Erstellung von Anwendungen zu konzentrieren und gleichzeitig Authentifizierung und Identity-Management sicher abzuwickeln.

In unserer Reihe „Einführung in IAM“ erfahren Sie mehr zum Thema Identity and Access Management.

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.