OpenID Connect · OAuth 2.0

Die Abläufe in Diagrammen

Wer mit wem spricht, in welcher Reihenfolge. Durchgezogene Linien sind Anfragen, gestrichelte Antworten. Zur Auswahl beginnen Sie mit Welchen Ablauf soll ich wählen?

Authorization Code + PKCE · Hybrid (code id_token, code token…) · Implicit (id_token, id_token token) · Refresh Token · Client Credentials · Password (ROPC) · Device Code (RFC 8628) · Token Exchange (RFC 8693) · Logout (RP-initiiert und Back Channel) · Introspection und Revocation · private_key_jwt und JWT Bearer (RFC 7523) · PAR und JAR (RFC 9126 und 9101) · JARM (signierte Autorisierungsantwort) · DPoP (RFC 9449) · CIBA (Client-Initiated Backchannel)

Authorization Code + PKCE Empfohlen

Der Standardablauf: Der Browser sieht nur einen einmaligen Code, die Token laufen von Server zu Server.

BrowserApplicationProvider (OP)API1. Erzeugt code_verifier,state, nonce2. 302 zu /authorize(challenge, state, nonce)3. GET /authorize4. Anmelde- und Einwilligungsseite5. Zugangsdaten und Einwilligung der Person6. 302 redirect_uri?code=…&state=…7. GET /callback?code=…&state=…8. POST /token (code,code_verifier, secret)9. ID token + access token (+refresh token)10. Prüft Signatur, iss,aud, nonce11. Authorization: Bearer access_token12. Angeforderte Daten
Textversion des Diagramms
  1. Anwendung: Erzeugt code_verifier, state, nonce
  2. Anwendung → Browser : 302 zu /authorize (challenge, state, nonce)
  3. Browser → Provider (OP) : GET /authorize
  4. Provider (OP) → Browser: Anmelde- und Einwilligungsseite
  5. Browser → Provider (OP): Zugangsdaten und Einwilligung der Person
  6. Provider (OP) → Browser : 302 redirect_uri?code=…&state=…
  7. Browser → Anwendung : GET /callback?code=…&state=…
  8. Anwendung → Provider (OP) : POST /token (code, code_verifier, secret)
  9. Provider (OP) → Anwendung : ID-Token + Access-Token (+ Refresh-Token)
  10. Anwendung: Prüft Signatur, iss, aud, nonce
  11. Application → API : Authorization: Bearer access_token
  12. API → Anwendung: Angeforderte Daten

Einsetzen, wenn: Jede Website, mobile App, SPA oder Desktop-Anwendung, bei der sich eine Person anmeldet.

Was ihn auszeichnet: Das ist die Grundlage. Alle anderen Abläufe sind eine Variante oder ein Sonderfall davon.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Hybrid (code id_token, code token…) Besondere Fälle

Die Identität wird sofort im Browser empfangen, der Code zum sicheren Beziehen der Token ebenso.

BrowserApplicationProvider (OP)1. 302 zu /authorize(response_type=code id_token)2. GET /authorize, dann Anmeldung3. 302 redirect_uri#code=…&id_token=…&state=…4. Ein Skript liest das Fragmentund sendet es zurück5. POST /callback (code,id_token, state)6. Prüft id_token und c_hash7. POST /token (code,code_verifier)8. access token (+ refreshtoken)
Textversion des Diagramms
  1. Anwendung → Browser : 302 zu /authorize (response_type=code id_token)
  2. Browser → Provider (OP) : GET /authorize, dann Anmeldung
  3. Provider (OP) → Browser : 302 redirect_uri#code=…&id_token=…&state=…
  4. Browser: Ein Skript liest das Fragment und sendet es zurück
  5. Browser → Anwendung : POST /callback (code, id_token, state)
  6. Anwendung: Prüft id_token und c_hash
  7. Anwendung → Provider (OP) : POST /token (code, code_verifier)
  8. Provider (OP) → Anwendung : Access-Token (+ Refresh-Token)

Einsetzen, wenn: Eine Anwendung, die die Person kennen muss, bevor sie den Code tauscht (serverseitige Sitzungsvalidierung, alte Bibliotheken).

Was ihn auszeichnet: Wie der Code-Flow, aber das ID-Token kommt direkt in der Weiterleitung an (mit c_hash, das es an den Code bindet).

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Implicit (id_token, id_token token) Nicht empfohlen

Die Token kommen direkt in der Adresse an: einfacher, aber exponiert.

Browser (SPA)Provider (OP)API1. Erzeugt state und nonce2. GET /authorize(response_type=id_token token)3. 302redirect_uri#id_token=…&access_token=…4. Liest das Fragment, prüft dasToken5. Authorization: Bearer access_token
Textversion des Diagramms
  1. Browser (SPA): Erzeugt state und nonce
  2. Browser (SPA) → Provider (OP) : GET /authorize (response_type=id_token token)
  3. Provider (OP) → Browser (SPA) : 302 redirect_uri#id_token=…&access_token=…
  4. Browser (SPA): Liest das Fragment, prüft das Token
  5. Browser (SPA) → API : Authorization: Bearer access_token

Einsetzen, wenn: Fast nie. Nur für alte SPAs oder um zu prüfen, dass eine Anwendung es korrekt verbietet.

Was ihn auszeichnet: Kein Code-Austausch: kein Back Channel, kein Refresh-Token, Token im Browserverlauf sichtbar.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Refresh Token Ergänzung

Ein kurzlebiges Access-Token erneuern, ohne die Person erneut zu fragen.

ApplicationProvider (OP)API1. Authorization: Bearer access_token2. 401 invalid_token (abgelaufen)3. POST /token(grant_type=refresh_token)4. Widerruft das alte Refresh-token (rotation)5. Neues Access-Token + neuesrefresh token6. Authorization: Bearer neues access_tokenWenn das alte Refresh-Tokenwiedergegeben wird, die ganze Token-Familiewird widerrufen.
Textversion des Diagramms
  1. Application → API : Authorization: Bearer access_token
  2. API → Anwendung: 401 invalid_token (abgelaufen)
  3. Anwendung → Provider (OP) : POST /token (grant_type=refresh_token)
  4. Provider (OP): Widerruft das alte Refresh-Token (Rotation)
  5. Provider (OP) → Anwendung : Neues Access-Token + neues Refresh-Token
  6. Anwendung → API : Authorization: Bearer neues access_token

Einsetzen, wenn: Sobald Sie kurze Access-Token wollen, aber die Person lange angemeldet halten möchten (Scope offline_access).

Was ihn auszeichnet: Das ist kein Anmeldeablauf: Er verlängert eine mit einem anderen Ablauf erhaltene Sitzung.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Client Credentials Maschine zu Maschine

Keine Person: Der Dienst authentifiziert sich mit seinem Geheimnis.

ServiceProvider (OP)API1. POST /token(grant_type=client_credentials,scope)2. Prüft das Client-Geheimnis3. access token4. Authorization: Bearer access_token5. Daten
Textversion des Diagramms
  1. Dienst → Provider (OP) : POST /token (grant_type=client_credentials, scope)
  2. Provider (OP): Prüft das Client-Geheimnis
  3. Provider (OP) → Dienst : Access-Token
  4. Service → API : Authorization: Bearer access_token
  5. API → Dienst: Daten

Einsetzen, wenn: Ein Dienst, eine geplante Aufgabe oder ein Daemon, der eine API in eigenem Namen aufruft.

Was ihn auszeichnet: Kein Browser, kein ID-Token, kein Refresh-Token: nur ein Access-Token, begrenzt auf die Scopes des Clients.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Password (ROPC) Vermeiden

Die Anwendung nimmt das Passwort selbst entgegen und sendet es an den Provider.

PersonApplicationProvider (OP)1. Gibt Benutzername undbestanden2. POST /token(grant_type=password, username,password)3. access token (+ refreshToken) oder Fehler
Textversion des Diagramms
  1. Person → Anwendung: Gibt Benutzername und Passwort ein
  2. Anwendung → Provider (OP) : POST /token (grant_type=password, username, password)
  3. Provider (OP) → Anwendung: Access-Token (+ Refresh-Token) oder Fehler

Einsetzen, wenn: Vermeiden. Nur für die Migration von einem Altsystem oder für automatisierte Tests.

Was ihn auszeichnet: Umgeht die Seite des Providers: kein MFA, kein SSO, leichteres Phishing.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Device Code (RFC 8628) Geräte ohne Browser

Das Gerät zeigt einen kurzen Code; die Person bestätigt ihn auf ihrem Telefon.

GerätProvider (OP)Telefon / Computer1. POST /device_authorization2. device_code, user_code,Adresse3. Zeigt „Gehen Sie zu … undgeben Sie ABCD-EFGH ein“4. Öffnet die Adresse, gibt denCode, meldet sich an5. POST /token (device_code) enSchleife6. authorization_pending, danndie Token
Textversion des Diagramms
  1. Gerät → Provider (OP) : POST /device_authorization
  2. Provider (OP) → Gerät : device_code, user_code, URL
  3. Gerät: Zeigt „Gehen Sie zu … und geben Sie ABCD-EFGH ein“
  4. Telefon / Computer → Provider (OP): Öffnet die Adresse, gibt den Code ein, meldet sich an
  5. Gerät → Provider (OP) : POST /token (device_code) in einer Schleife
  6. Provider (OP) → Gerät: authorization_pending, dann die Token

Einsetzen, wenn: Fernseher, Konsole, vernetztes Gerät, Kommandozeilenwerkzeug.

Was ihn auszeichnet: Die Anmeldung erfolgt auf einem anderen Gerät. Das Gerät fragt den Provider bis zur Bestätigung ab.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Token Exchange (RFC 8693) Besondere Fälle

Ein Token gegen ein anderes tauschen, für einen anderen Empfänger.

API AProvider (OP)API B1. POST /token(grant_type=token-exchange,subject_token, audience=B)2. Prüft Rechte und Audience3. Access-Token für API B4. Authorization: Bearer neues Token
Textversion des Diagramms
  1. API A → Provider (OP) : POST /token (grant_type=token-exchange, subject_token, audience=B)
  2. Provider (OP): Prüft Rechte und Audience
  3. Provider (OP) → API A: Access-Token für API B
  4. API A → API B : Authorization: Bearer neues Token

Einsetzen, wenn: Eine API, die im Namen der Person eine andere aufrufen muss, oder Microservices, die die Identität weitergeben.

Was ihn auszeichnet: Geht von einem bereits erhaltenen Token aus, ohne neue Anmeldung. Kann Rechte reduzieren oder die Audience ändern.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Logout (RP-initiiert und Back Channel) Session

Die Sitzung beim Provider beenden und die anderen Anwendungen benachrichtigen.

BrowserApplication AProvider (OP)Application B1. Klickt auf „Abmelden“2. 302 zu /logout(id_token_hint,post_logout_redirect_uri)3. GET /logout4. Schließt dieProvider5. POST logout_token(back-channel)6. 302 zu post_logout_redirect_uri
Textversion des Diagramms
  1. Browser → Anwendung A: Klickt auf „Abmelden“
  2. Anwendung A → Browser : 302 zu /logout (id_token_hint, post_logout_redirect_uri)
  3. Browser → Provider (OP) : GET /logout
  4. Provider (OP): Beendet die Provider-Sitzung
  5. Provider (OP) → Anwendung B : POST logout_token (Back Channel)
  6. Provider (OP) → Browser : 302 zu post_logout_redirect_uri

Einsetzen, wenn: Jede Anwendung mit Single Sign-On (SSO): Die Abmeldung muss sich fortpflanzen.

Was ihn auszeichnet: Der Back Channel benachrichtigt von Server zu Server, ohne über den Browser zu gehen (daher zuverlässig).

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

Introspection und Revocation Prüfen

Den Provider fragen, ob ein Token noch gültig ist, oder es ungültig machen.

APIProvider (OP)1. POST /introspect (token)2. { "active": true, scope, exp,sub }3. POST /revoke (token)4. 200 : Das Token ist ungültig
Textversion des Diagramms
  1. API → Provider (OP) : POST /introspect (token)
  2. Provider (OP) → API : { "active": true, scope, exp, sub }
  3. API → Provider (OP) : POST /revoke (token)
  4. Provider (OP) → API: 200 : Das Token ist ungültig

Einsetzen, wenn: Eine API, die ein undurchsichtiges Token erhält oder sofortigen Widerruf will.

Was ihn auszeichnet: Ein JWT lässt sich allein anhand seiner Signatur prüfen; ein undurchsichtiges Token erfordert diesen Aufruf.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

private_key_jwt und JWT Bearer (RFC 7523) In ID-Kit: Test-Provider

Der Client weist seine Identität mit einem mit seinem privaten Schlüssel signierten JWT nach, statt mit einem gemeinsamen Geheimnis.

ServiceProvider (OP)1. Signiert ein JWT (iss, sub,aud, exp, jti)2. POST /token(client_assertion,client_assertion_type)3. Prüft die Signatur mitden öffentlichen Schlüssel des Clients4. access token
Textversion des Diagramms
  1. Dienst: Signiert ein JWT (iss, sub, aud, exp, jti)
  2. Dienst → Provider (OP) : POST /token (client_assertion, client_assertion_type)
  3. Provider (OP): Prüft die Signatur mit dem öffentlichen Schlüssel des Clients
  4. Provider (OP) → Dienst : Access-Token

Einsetzen, wenn: Banken, Gesundheitswesen, sensible APIs, Unternehmensintegrationen: kein Geheimnis zu speichern oder zu rotieren.

Was ihn auszeichnet: Derselbe Austausch wie bei Client Credentials, aber die Authentifizierung ist eine signierte Assertion (client_assertion).

ID-Kit kann ihn auf der Seite des Test-Providers spielen (deklarieren Sie den öffentlichen Schlüssel Ihres Clients, Typ „Vertraulich per Schlüssel“). Auf Seite der Testanwendung noch nicht.

PAR und JAR (RFC 9126 und 9101) In ID-Kit

Die Autorisierungsanfrage wird von Server zu Server gepusht, statt im Klartext in der Adresse zu stehen.

BrowserApplicationProvider (OP)1. POST /par (alleParameter, signiert)2. request_uri (einigeSekunden)3. 302 zu/authorize?request_uri=…4. GET /authorize?request_uri=…5. Anmeldung, dann Weiterleitung mit dem Code
Textversion des Diagramms
  1. Anwendung → Provider (OP): POST /par (alle Parameter, signiert)
  2. Provider (OP) → Anwendung : request_uri (einige Sekunden gültig)
  3. Anwendung → Browser : 302 zu /authorize?request_uri=…
  4. Browser → Provider (OP) : GET /authorize?request_uri=…
  5. Provider (OP) → Browser: Anmeldung, dann Weiterleitung mit dem Code

Einsetzen, wenn: FAPI-Anforderungen: verhindern, dass ein Parameter im Browser verändert oder gelesen wird.

Was ihn auszeichnet: Der Browser transportiert nur eine undurchsichtige request_uri.

ID-Kit kann ihn spielen: Test-Provider (Ihre Anwendung gegen ID-Kit) und Testanwendung (Ihr Provider gegen ID-Kit).

JARM (signierte Autorisierungsantwort) In ID-Kit (Test-Provider)

Der Provider signiert auch seine Antwort: Der Code kommt in einem JWT an, nicht im Klartext in der Adresse.

BrowserApplicationProvider (OP)1. 302 zu/authorize?response_mode=jwt2. GET /authorize, dann Anmeldung3. Signiert ein JWT { iss, aud,code, state }4. Weiterleitung zur Anwendung ?response=JWT5. Leitet die Antwort weiter6. Prüft Signatur, iss,aud, dann liest er den Code
Textversion des Diagramms
  1. Anwendung → Browser : 302 zu /authorize?response_mode=jwt
  2. Browser → Provider (OP) : GET /authorize, dann Anmeldung
  3. Provider (OP): Signiert ein JWT { iss, aud, code, state }
  4. Provider (OP) → Browser : Weiterleitung zur Anwendung ?response=JWT
  5. Browser → Anwendung : Leitet die Antwort weiter
  6. Anwendung: Prüft die Signatur, iss, aud und liest dann den Code

Einsetzen, wenn: FAPI 2.0, regulierte Branchen, Schutz vor Mix-up-Angriffen zwischen Providern.

Was ihn auszeichnet: Ein einziger Parameter „response“ (JWT, signiert mit iss, aud, exp, code, state) ersetzt die einfachen Parameter.

ID-Kit kann ihn auf der Seite des Test-Providers spielen (deklarieren Sie den öffentlichen Schlüssel Ihres Clients, Typ „Vertraulich per Schlüssel“). Auf Seite der Testanwendung noch nicht.

DPoP (RFC 9449) In ID-Kit (Test-Provider)

Das Token ist an einen Schlüssel gebunden, den nur der Client besitzt: Ein gestohlenes Token ist unbrauchbar.

ApplicationProvider (OP)API1. Erzeugt ein Schlüsselpaar2. POST /token + DPoP-Header(signierter Nachweis)3. an den Schlüssel gebundenes Access-Token(cnf.jkt)4. Authorization: DPoP-Token + neuer DPoP-Nachweis5. Prüft den Nachweis und dieBindung an den Schlüssel
Textversion des Diagramms
  1. Anwendung: Erzeugt ein Schlüsselpaar
  2. Anwendung → Provider (OP): POST /token + DPoP-Header (signierter Nachweis)
  3. Provider (OP) → Anwendung: schlüsselgebundenes Access-Token (cnf.jkt)
  4. Anwendung → API : Authorization: DPoP-Token + neuer DPoP-Nachweis
  5. API: Prüft den Nachweis und die Bindung an den Schlüssel

Einsetzen, wenn: Hohe Sicherheit, exponierte SPAs, sensible APIs.

Was ihn auszeichnet: Jeder Aufruf kommt mit einem signierten Nachweis (DPoP-Header), der den Besitz des Schlüssels beweist.

ID-Kit kann ihn auf der Seite des Test-Providers spielen (deklarieren Sie den öffentlichen Schlüssel Ihres Clients, Typ „Vertraulich per Schlüssel“). Auf Seite der Testanwendung noch nicht.

CIBA (Client-Initiated Backchannel) In ID-Kit (Test-Provider)

Die Authentifizierung erfolgt auf dem Gerät der Person, vom Server ausgelöst.

ApplicationProvider (OP)Telefon1. POST /bc-authorize(login_hint, binding_message)2. auth_req_id3. Benachrichtigung: „DiesesZahlung?“4. Die Person akzeptiert5. POST /token (auth_req_id) enSchleife oder Callback6. Token
Textversion des Diagramms
  1. Anwendung → Provider (OP) : POST /bc-authorize (login_hint, binding_message)
  2. Provider (OP) → Anwendung : auth_req_id
  3. Provider (OP) → Telefon: Benachrichtigung: „Diese Zahlung autorisieren?“
  4. Telefon → Provider (OP): Die Person akzeptiert
  5. Anwendung → Provider (OP): POST /token (auth_req_id) in einer Schleife oder Callback
  6. Provider (OP) → Anwendung : Token

Einsetzen, wenn: Callcenter, Banken, Zahlungsbestätigung per Benachrichtigung.

Was ihn auszeichnet: Keine Browser-Weiterleitung: Der Provider kontaktiert die Person direkt.

ID-Kit kann ihn auf der Seite des Test-Providers spielen (deklarieren Sie den öffentlichen Schlüssel Ihres Clients, Typ „Vertraulich per Schlüssel“). Auf Seite der Testanwendung noch nicht.