RaiBnod
Ich muss den Benutzer dazu bringen, sich im System anzumelden, wenn der Benutzer es ist access_token ablaufen und der Benutzer möchte sich anmelden. Wie kann ich neu aktualisiert werden access_token mit Hilfe von refresh_token an Schlüsselumhang?
ich benutze vertx-auth für die Auth-Implementierung mit Schlüsselumhang an vert.x. Ist eine Auffrischung möglich access_token mit vertx-auth oder Schlüsselumhang‘s REST API selbst? Oder was wird eine andere Implementierung davon sein?
Yondra Mishra
keycloak verfügt über eine REST-API zum Erstellen einer access_token verwenden refresh_token. Es ist ein POST endpoint with application/x-www-form-urlencoded
So sieht es aus:
Method: POST
URL: https://keycloak.example.com/auth/realms/myrealm/protocol/openid-connect/token
Body type: x-www-form-urlencoded
Form fields:
client_id : <my-client-name>
grant_type : refresh_token
refresh_token: <my-refresh-token>
Dadurch erhalten Sie ein neues Zugriffstoken mit dem Aktualisierungstoken.
HINWEIS: Wenn Ihr Aktualisierungstoken abgelaufen ist, wird eine 400-Ausnahme ausgelöst, sodass Sie sich erneut anmelden können.
Schauen Sie sich ein Beispiel in Postman an, Sie können damit eine entsprechende API entwickeln.
Ich habe das mit probiert 2.5.4 und es erfordert immer noch das Client-Geheimnis für diese Anfrage. Es macht jetzt jedoch Sinn, warum das Clientgeheimnis erforderlich ist, wenn das Aktualisierungstoken bereitgestellt wird.
– rrrocky
13. Dezember 2018 um 6:42 Uhr
Das Clientgeheimnis ist nur erforderlich, wenn es sich um a handelt geheim Klient. Öffentlich Clients benötigen das Clientgeheimnis nicht.
– rrrocky
13. Dezember 2018 um 8:45 Uhr
Kann jemand erklären, warum das Clientgeheimnis erforderlich ist, wenn ein Token für einen vertraulichen Client aktualisiert wird?
– Kimble
21. Dezember 2018 um 8:42 Uhr
@all ,Warum ist das Aktualisierungstoken im JWT-Format? zustandslos, aber Google und auth0 verwenden zustandsbehaftet.
– Panup-Pong
12. September 2019 um 10:51 Uhr
@ Kimble vertraulicher Kunde in Keycloak ist für Serveranwendungen gedacht, bei denen das Speichern eines Client-Geheimnisses sicher ist. Sehen Sie sich die Dokumente an (hier)[keycloak.org/docs/6.0/server_admin/#oidc-clients]
– bck
20. August 2020 um 20:09 Uhr
@maslick ist richtig, Sie müssen auch das Client-Geheimnis angeben, in diesem Fall ist kein Autorisierungsheader erforderlich:
http://localhost:8080/auth/realms/{realm}/protocol/openid-connect/token
Im Falle eines abgelaufenen Aktualisierungstokens wird Folgendes zurückgegeben:
Wenn Sie das Geheimnis nicht hinzufügen, erhalten Sie 401 nicht autorisiert, obwohl das Aktualisierungstoken korrekt ist
Ich habe es gerade getestet, Sie brauchen nur das Client-Geheimnis, wenn der Client der den Token ausgegeben hat ist vertraulich
– Matteo
19. August 2021 um 0:35 Uhr
Ich habe es mit 4.8.2.Final versucht, es gibt folgendes unauthorized_client auch mit vorherigem Zugriffstoken als ‘Bearer’. Dann habe ich es mit versucht Basic YXBwLXByb3h5OnNlY3JldA== im Berechtigungskopf. Dann hat es funktioniert, aber ich bin mir immer noch nicht sicher, ob ich das Richtige tue.
Bei den Authorization-Headern kommt es darauf an, wonach der Server im Header-Wert sucht. Wenn dies funktioniert, liegen Sie wahrscheinlich nicht falsch.
– charliebeckwith
28. Januar 2019 um 5:45 Uhr
Sie verwenden wahrscheinlich einen vertraulichen Client, also müssen Sie ihn einschließen client_secret in der Anfrage
– Maslick
8. Februar 2019 um 15:12 Uhr
Warum sollte jemand das Aktualisierungstoken verwenden wollen, wenn ich client_secret als vertraulichen Client übergeben muss? IMO, Keycloak sollte access_token zurückgeben, indem einfach client_id und refresh_token übergeben werden, da es sich wie ein Geheimnis verhält.
– Ganesan Arunachalam
20. Mai 2020 um 13:30 Uhr
Erweiterung der Antwort von Yogendra Mishra. Beachten Sie, dass
client_id und client_secret kann auch im Authorization-Header gesendet werden.
Authorization: Basic ${Base64(<client_id>:<client_secret>)}
Dies funktioniert sowohl für den anfänglichen Token-Aufruf (ohne Aktualisierungstoken) als auch für den Aktualisierungstoken-Aufruf /openid-connect/token Endpunkt
Bezug:
https://developer.okta.com/docs/reference/api/oidc/#client-secret
