OpenID Connect
Die wichtigsten Befehle zum Merken
curl --fail --silent --show-error— das Discovery-Dokument des Anbieters abrufen.jq— Aussteller, Endpunkte und Protokollfähigkeiten untersuchen.
Befehle und Optionen
| Befehl oder Option | Bedeutung |
|---|---|
--fail |
Bei HTTP-Fehlern einen Fehlerstatus liefern. |
--silent --show-error |
Fortschritt ausblenden, Fehler anzeigen. |
--max-time 10 |
Höchstens zehn Sekunden übertragen. |
jq '{…}' |
Benannte Felder aus der JSON-Antwort auswählen. |
| |
Den Antwortinhalt an jq weitergeben. |
Die URL wählt die öffentliche Konfiguration eines bekannten Anbieters. Das Beispiel überträgt keine Benutzeridentität oder Sitzung.
Die entscheidenden Konzepte
1. OIDC liefert ein Authentifizierungsergebnis
OpenID Connect, kurz OIDC, ergänzt OAuth 2.0 um eine Identitätsschicht. Eine Anwendung lässt einen Identitätsanbieter eine Person authentifizieren und erhält ein definiertes Ergebnis. Der angeforderte Scope openid unterscheidet OIDC von einer gewöhnlichen OAuth-Autorisierungsanfrage.
Die Anwendung kann damit Anmeldung delegieren, bleibt aber für ihre Berechtigungen verantwortlich. Authentifizierung durch den Anbieter macht jemanden nicht automatisch zum Administrator deiner Anwendung.
2. Ein ID Token ist für den Client
Das ID Token ist ein JWT mit einem Authentifizierungsergebnis für den Client. Dieser prüft es anhand des konfigurierten Anbieters, seiner Zielgruppe, Zeitgrenzen und weiterer Protokollregeln. Ein Access Token erlaubt dagegen Zugriff auf eine geschützte Ressource.
Beide sind nicht austauschbar, nur weil sie möglicherweise wie JWTs aussehen. Eine API sollte kein ID Token als Access Token akzeptieren. Ein Client darf aus beliebigen Access-Token-Inhalten keinen Anmeldevertrag ableiten.
3. Discovery verbindet Konfiguration und vertrauenswürdige Schlüssel
Das Discovery-Dokument nennt Aussteller, Autorisierungs- und Token-Endpunkt sowie häufig eine JWKS-URI für öffentliche Signierschlüssel. Clients können diese Angaben verwenden, statt Dienst-URLs zu erraten.
Vertrauen beginnt beim bewusst konfigurierten Anbieter. Metadaten von einer beliebigen URL aus einem ungeprüften Token würden diesem die Wahl seiner eigenen Autorität erlauben. Schlüsselrotation ist normal; gepflegte OIDC-Bibliotheken aktualisieren vertrauenswürdige Metadaten und Schlüssel nach festgelegten Regeln.
4. Eine Anmeldung gehört zur richtigen Anfrage und Person
Der Client muss das Ergebnis seiner eigenen Anmeldetransaktion zuordnen und die Schutzmechanismen des gewählten Ablaufs anwenden. Ein gesendeter Nonce muss zum ID Token passen. Authorization-Code-Flows verwenden zusätzlich etwa PKCE und geeignete Zustandsprüfung.
Identifiziere Konten durch Aussteller und Subjektkennung zusammen. Anzeigenamen sind nicht eindeutig, E-Mail-Adressen können wechseln. Nach der Prüfung erstellt die Anwendung meist eine eigene Sitzung mit einer vom Anbieter-Token getrennten Lebensdauer.
Ein kleines Beispiel
Optional: Untersuche Googles öffentliches OIDC-Discovery-Dokument. Dafür sind weder Google-Konto noch registrierter Client nötig.
curl --fail --silent --show-error --max-time 10 https://accounts.google.com/.well-known/openid-configuration | jq '{issuer, authorization_endpoint, token_endpoint, jwks_uri, scopes_supported, response_types_supported}'Suche issuer und vergleiche den Autorisierungsendpunkt für den Browser mit dem Token-Endpunkt. jwks_uri nennt den Ort öffentlicher Prüfschlüssel, keinen privaten Signierschlüssel. Suche openid in den unterstützten Scopes.
Die Listen beschreiben Anbieterfähigkeiten und empfehlen nicht jeden beworbenen Ablauf. Ein erfolgreicher Abruf belegt weder Benutzeranmeldung noch Token-Gültigkeit. Dafür braucht es zusätzlich Client-Registrierung, exakte Redirect-Konfiguration und eine Bibliothek zur Antwortprüfung und Sitzungserstellung.
Merke dir: OIDC sagt dem Client, wer unter einem vertrauenswürdigen Aussteller authentifiziert wurde. Die Anwendung bestimmt weiterhin dessen Berechtigungen.