Kid stimmt nicht überein OAuth 2.0-Fluss

Ich verwende Okta für Identitätsmanagement. Als Client im Autorisierungsfluss sende ich eine Autorisierungsanfrage an Okta. Dies funktioniert erfolgreich und ich bekomme eine JWT-Nutzlast. Ich möchte die JWT-Signatur überprüfen, also rufe ich Okta erneut an, um die Schlüssel zu holen. Die Schlüssel-IDs (Kinder) stimmen jedoch nicht überein und die Überprüfung schlägt fehl.Kid stimmt nicht überein OAuth 2.0-Fluss

Initial authorise Anfrage:

https://{{site}}.okta.com/oauth2/v1/authorize 
    ?scope=openid 
    &response_type=id_token 
    &client_id={{client_id}} 
    &redirect_uri={{redirect_url}} 
    &nonce=4euiv0v52at3la15e7qlu1mt43 
    &state=7c92bqulrmdk2jk0ro9rd3mf5j

Response ist eine 403, mich Umleitung zu:

{{redirect_url}}/id_token={{id_token}}

Der Header des id_token decodiert in:

{ 
    "alg": "RS256", 
    "kid": "2YKtkekCjCRWN0YqGsjUrNwIQaxGg5ahfHW0_fK8t64" 
}

So weit, so gut. Ich weiß, dass die Autorisierung erfolgreich war. Zeit, das JWT zu validieren.

Wenn dies jedoch mit nachgegangen wird:

https://{{site}}.okta.com/oauth2/v1/keys

Oder

https://{{site}}.okta.com/oauth2/v1/keys?clientId={{client_id}}

(sie beide die gleiche Antwort zurück), erhalte ich wieder dieses:

{ 
    "keys": [ 
    { 
     "alg": "RS256", 
     "e": "AQAB", 
     "n": "gv1rI9A7mrOoViJZTzUfiZl7YdEzLEofvRoVbXCgeW7aOmoKcAkWGHvqNRGoFgi8auV5b_TSgTXKq_TV1fz643hpAtba3V0Uw2lXchTbqXpmVRYXI1t4FIwRMXLe4Q-kcvp9la21e3D1lszjdPbFNX5GLAhrCW0Thu2HYbTLg6TbDTMaiQCMo15hek0JgZqRGzCkt9kINnwPVLXV_bkSh_fHWo_6G1L0MKYYQcgE6zvPlULLek98-yZ6Nlg6nJUY9nHn0qjhzqqq-bz_Vin8qi3Bt7SjUKwk7HbaugM84AEgDxYE5JgsaALIl5SgIc3GgFEc69qKWymoD-w1a8f1HQ", 
     "kid": "SOxFkBSLWefjlZoDI49Hk0nqlYtC28cjhTlVAYEzAxs", 
     "kty": "RSA", 
     "use": "sig" 
    } 
    ] 
}

Wo Das Kind stimmt nicht mit dem überein, was ich in der ursprünglichen Antwort erhalten habe.

Wo ist mein Fehler?

Quelle

2017-08-31 Magua

Das ist eine gute Frage! Ich habe mir die Freiheit genommen, es leicht zu bearbeiten, um es für andere Leute lesbarer zu machen, die darauf stoßen könnten. Lass es mich wissen, wenn du denkst, dass meine Bearbeitung die Bedeutung deiner Frage zu sehr verändert hat. –

Sie benötigen einen Autorisierungsserver und verwenden Sie es als Endpunkt, zum Beispiel zu erstellen:

https://{{site}}.okta.com/oauth2/{authorizationServerId}/v1/authorize

Sie sollten auch in der Lage sein, einen den Standard zu verwenden:

https://{{site}}.okta.com/oauth2/default/v1/authorize

Hinweis, dass dies anders als die Route, die Sie verwendet haben (ohne Angabe eines Autorisierungsservers):

Sie sollten in Ihrem Fall einen Autorisierungsserver angeben (wie oben in Beispiel 1 und 2), sowohl für OAuth 2.0 als auch für OpenID Connect.

Quelle

2017-08-31 22:32:24

Danke für die Antwort. Ich sehe, dass dies für den OAuth2-Flow gilt, aber gemäß den Dokumenten für den OpenID-Flow ist kein Autorisierungsserver angegeben - Okta ist der einzige. Die Überprüfung bei /.well-known/openid-configuration zeigt die URLs an, die ich verwende, ohne dass ein Autorisierungsserver im Pfad angegeben ist. – Magua

In welcher Sprache validieren Sie das JWT? Wir könnten eine Bibliothek haben, die Ihnen helfen kann. –

@Magua Die Dokumentation scheint zu implizieren, dass Sie OIDC nicht mit einem benutzerdefinierten Autorisierungsserver verwenden können, aber Sie können.Sowohl OAuth 2.0 als auch OpenID Connect arbeiten mit einem benutzerdefinierten AS. Wie Matt schon sagte, haben Sie vielleicht schon ein benutzerdefiniertes AS namens 'default'. –

Das Problem bestand darin, dass dieses Konto mit fixierten, nicht rotierenden Schlüsseln eingerichtet wurde. oauth2/v1/keys erfordert, dass die Client-ID als Parameter übergeben wird, wenn Sie mit fixierten Schlüsseln eingerichtet sind. Der korrekte Parametername lautet "client_id", nicht "clientId". Dies führt zu der erwarteten Ausgabe.

Quelle

2017-09-13 17:54:22 Magua

Kid stimmt nicht überein OAuth 2.0-Fluss

Antwort

Verwandte Themen