IT-Sicherheit
OpenID Connect
OpenID Connect (OIDC) ist eine Authentifizierungsschicht auf OAuth 2.0: Ein signiertes ID Token weist den Nutzer aus, moderner Standard für Single Sign-on.
- Authentifizierung auf OAuth 2.0
- ID Token als signiertes JWT
- Code Flow mit PKCE
- Discovery + JWKS
- SSO für Web, Mobile, API
OpenID Connect (OIDC) beantwortet die Frage „Wer ist dieser Nutzer?“. Es ist eine dünne Identitätsschicht über dem Autorisierungs-Framework OAuth 2.0: OAuth allein regelt nur den Zugriff auf Ressourcen, OIDC ergänzt den eigentlichen Identitätsnachweis in Form eines signierten ID Tokens.
Dieser Artikel erklärt das Verhältnis zu OAuth, die Rollen, das ID Token als JWT, das vereinfachende Zusammenspiel von Discovery und JWKS, den empfohlenen Authorization Code Flow mit PKCE samt veraltetem Implicit Flow, die korrekte Token-Validierung sowie die Logout-Mechanismen.
1. Identität über OAuth 2.0
OAuth 2.0 (RFC 6749) ist ein Autorisierungs-Framework: Es regelt, ob ein Client auf eine Ressource zugreifen darf, sagt aber nichts darüber aus, wer der Nutzer ist. OIDC legt genau diese Authentifizierungsschicht darüber. Die zentrale Abgrenzung, die in der Praxis oft verschwimmt: OIDC authentifiziert (wer ist es), OAuth autorisiert (worauf darf zugegriffen werden).
2. Die Rollen
- End-User der Nutzer, der sich anmeldet (in OAuth: Resource Owner).
- Relying Party (RP) die Anwendung, die eine Anmeldung verlangt (der OAuth-Client).
- OpenID Provider (OP) der Identity Provider, der den Nutzer authentifiziert und Angaben liefert (etwa Keycloak oder authentik).
3. Das ID Token
Kernstück von OIDC ist das ID Token, ein signiertes JSON Web Token (JWT) mit Angaben („Claims“) über die Anmeldung. Pflicht-Claims sind unter anderem iss (Aussteller), sub (eindeutige Nutzer-ID), aud (für welchen Client), exp (Ablauf) und iat (Ausstellungszeit); ein nonce (im Code Flow optional, aber empfohlen) bindet das Token an die Anmeldesitzung und schützt vor Wiedereinspielung. Wichtig: Das ID Token belegt die Anmeldung, es ist kein Access Token für den Zugriff auf Ressourcen-APIs.
Das ID Token ist kein Access Token. Wer das ID Token als Zugriffsausweis an Ressourcen-APIs schickt, baut eine Sicherheitslücke ein, das ist der häufigste OIDC-Fehler.
4. Discovery und JWKS
OIDC-Provider veröffentlichen ihre Metadaten maschinenlesbar unter /.well-known/openid-configuration: die Adressen der Endpunkte, unterstützte Verfahren und unter jwks_uri die öffentlichen Schlüssel zur Signaturprüfung. Das reduziert die Integration erheblich, weil ein Client die Konfiguration automatisch abrufen kann.
Provider-Metadaten abrufen
curl https://idp.example.de/.well-known/openid-configuration
# liefert u. a. authorization_endpoint, token_endpoint, jwks_uri5. Der empfohlene Flow: Code + PKCE
Empfohlen ist der Authorization Code Flow: Der Nutzer wird zum Provider geleitet, meldet sich an, der Client erhält einen kurzlebigen Code und tauscht ihn serverseitig gegen ID Token und Access Token, die nie im Browser sichtbar werden. Ergänzt um PKCE (RFC 7636, eine kryptografische Code-Bindung) ist dieser Flow für alle Client-Typen sicher, auch für Single-Page-Apps und mobile Anwendungen. Der frühere Implicit Flow, der Tokens direkt im URL-Fragment lieferte, gilt als unsicher, wird abgeraten und ist im OAuth-2.1-Entwurf gestrichen.
6. Token-Validierung
Eine Anwendung darf einem ID Token nur trauen, wenn sie es vollständig prüft: die Signatur gegen den öffentlichen Schlüssel aus dem JWKS, den Aussteller (iss), die Zielgruppe (aud muss die eigene Client-ID enthalten), den Ablauf (exp) und, falls gesendet, den nonce. Der Algorithmus none ist abzulehnen. Kurzlebige Access Tokens und rotierende Refresh Tokens runden das Sicherheitsbild ab.
7. Abmelden
Für das Abmelden kennt OIDC mehrere Wege: das RP-Initiated Logout (die Anwendung leitet zum Logout-Endpunkt des Providers), das Front-Channel Logout (über Browser-iframes, durch das Blockieren von Drittanbieter-Cookies zunehmend unzuverlässig) und das robustere Back-Channel Logout (der Provider benachrichtigt die Anwendungen direkt per signiertem Logout-Token, ohne Browser-Umweg).
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Schlank über REST/JSON, ideal für Mobile und API | kein feingranulares Berechtigungsmodell (nur Identität) |
| Discovery + JWKS senken den Integrationsaufwand | Token-Validierung muss korrekt umgesetzt sein |
| Code Flow + PKCE für alle Client-Typen sicher | Implicit Flow veraltet, darf nicht mehr genutzt werden |
| Klare Trennung Authentifizierung/Autorisierung | ID Token ≠ Access Token wird oft verwechselt |
| Breit standardisiert und unterstützt | Front-Channel Logout durch Cookie-Blocking fragil |
Häufige Fragen zu OpenID Connect
OAuth 2.0 ist ein Autorisierungs-Framework: Es regelt den delegierten Zugriff auf Ressourcen, sagt aber nicht aus, wer der Nutzer ist. OpenID Connect ist eine Authentifizierungsschicht darüber und liefert mit dem ID Token den geprüften Identitätsnachweis. Kurz: OIDC authentifiziert, OAuth autorisiert. Das ID Token von OIDC darf nicht als Access Token für den Ressourcenzugriff verwendet werden.
Der Authorization Code Flow mit PKCE. Er liefert die Tokens nicht über den Browser aus, sondern lässt sie serverseitig gegen einen kurzlebigen Code tauschen, und PKCE sichert diesen Tausch zusätzlich ab. Dieser Flow eignet sich für alle Client-Typen, auch für Single-Page-Apps und mobile Apps. Der ältere Implicit Flow gilt als unsicher und wird in OAuth 2.1 gestrichen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
OpenID Connect im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.