Aktualisieren Sie access_token über refresh_token in Keycloak

Lesezeit: 3 Minuten

Benutzeravatar von RaiBnod
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?

Benutzeravatar von Yogendra Mishra
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.

Probe bei Postman

  • 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

Geben Sie hier die Bildbeschreibung ein

Im Falle eines abgelaufenen Aktualisierungstokens wird Folgendes zurückgegeben:

Geben Sie hier die Bildbeschreibung ein

Wenn Sie das Geheimnis nicht hinzufügen, erhalten Sie 401 nicht autorisiert, obwohl das Aktualisierungstoken korrekt ist

Geben Sie hier die Bildbeschreibung ein

  • 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

Grundlegende Authentifizierung1

Sie müssen Client-ID und Geheimnis nicht im Körper senden, nachdem Sie die Authentifizierungs-Header festgelegt haben

Bezug:
https://developer.okta.com/docs/reference/api/oidc/#client-secret

1441380cookie-checkAktualisieren Sie access_token über refresh_token in Keycloak

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy