Wie authentifiziert openID Connect einen Benutzer wirklich?

Question

Von meinem den Unterschied von OAuth zu OpenID Connect Verständnis ist, dass, wenn die Client Treffer/Token-Endpunkt von OAuth, OAuth mit folgendem antwortet:

HTTP/1.1 200 OK 
Content-Type: application/json 
Cache-Control: no-store 
Pragma: no-cache 

{ 
    "access_token": "SlAV32hkKG", 
    "token_type": "Bearer", 
    "refresh_token": "8xLOxBtZp8", 
    "expires_in": 3600, 
    "id_token": "e134j23jk432j" 
} 

ich aus der Lektüre der Dokumentation unter dem Eindruck war, dass die ID-Token enthalten ein Authentifizierungstyp, der angibt, ob der Benutzer die Autorisierung durch Eingabe eines Kennworts bestanden hat. Dies würde daher sicherstellen, dass der Benutzer sich authentifiziert und nicht nur autorisiert hat. Mir ist nur nicht klar, wie das Token dazu verwendet wird, dies zu verifizieren.

Es ist mein Verständnis der id_token ist nicht undurchsichtig für den Client, gibt es also eine Standard-Art, in der Informationen vom Client interpretiert wird?

Weiter, die Dokumentation, die ich unter http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html unter 5. Definitions of Multiple-Valued Response Type Combinations fand, zeigt eine Beispielanforderung für id_token gemacht/autorisieren. Sollte id_token nicht bei/token erhalten werden?

Answer 1

Es ist mein Verständnis der id_token nicht undurchlässig für den Kunden ist

Also das ist, wo Sie eine Klärung bedürfen. Id-Token ist ein JWT (rfc7519) und muss vom Client verifiziert werden.

Beachten Sie, dass "Client" hier die vertrauende Partei ist. Zum Beispiel ist es eine Website. Dieser Client stützt sich auf die Autorisierung, die bei Openid-Provider (Autorisierungsserver wie in rfc6749 beschrieben) erfolgt, und verwendet das ID-Token in der Antwort, um den "Endbenutzer" zu authentifizieren. zu authentifizierenden ist die ID-Token-Datenstruktur

Zitiert aus der Dokumentation,

Die primäre Verlängerung dass OpenID Connect zu OAuth 2.0 macht End-Benutzer zu ermöglichen. Der ID-Token ist ein Sicherheitstoken, das Ansprüche bezüglich der Authentifizierung eines Endbenutzers durch einen Autorisierungsserver bei der Verwendung eines Clients und möglicherweise anderer angeforderter Ansprüche enthält. Der ID-Token wird als JSON-Web-Token (JWT) dargestellt.

Nun zurück zur Frage. Wie man ein JWT liest und versteht und es verwendet, um einen Benutzer zu authentifizieren. Spezifikation für JWT ist hier - rfc7519. Es enthält im Wesentlichen drei Abschnitte in folgendem Format,

H.C.S

H (Header) - Enthält Typ und einen Algorithmus und andere Metainformationen

C (JWT Ansprüche) - Enthält Ansprüche in Bezug auf autorisierter Benutzer

S (JWS-Signatur rfc7515) - A basical ly ein MAC, der Header und Ansprüche zu überprüfen ist

Und jedes dieser Teile sind base64url codiert. Beachten Sie, dass JWS vom Tokenaussteller signiert wird.

aus der Dokumentation Zitiert

ID Tokens zu unterzeichnen ist unter Verwendung von JWS [JWS] und gegebenenfalls sowohl signiert und verschlüsselt dann unter Verwendung von JWS [JWS] und JWE [JWE] jeweils, wodurch eine Authentifizierung, Integrität, non -repudiation und gegebenenfalls Vertraulichkeit gemäß § 16,14

Was in einem id token validiert werden müssen, die specification erwähnen, was Sie tun müssen.

Hope this klärt Ihre Zweifel über JWT und wie es verwendet wird zur Authentifizierung von "end user"

Sollte nicht an/Token erhalten id_token werden?

Es hängt von dem Fluss ab, den Sie verwenden. Zum Beispiel können Sie mit der implicit flow ID-Token in der Autorisierungsantwort erhalten.

ps - Um den Inhalt eines ID-Token sehen Sie Debugger-Funktionalität von https://jwt.io/