Keycloak 管理員 REST API - 使用刷新令牌創建新的訪問令牌而不重新創建刷新令牌

Question

當我有一個有效的刷新令牌時，我正在嘗試使用 Keycloak 管理員 REST API 重新創建訪問令牌。

我通過調用 POST /auth/realms/{realm}/protocol/openid-connect/token 實現了這一點。

問題是端點每次也返回一個新的刷新令牌。 這是 JWT 授權流程應該工作的方式嗎？

我認為正確的流程是僅在調用 auth 端點時獲取新的訪問令牌，並且當刷新令牌過期時，再次登錄以獲取新的刷新令牌； 每次我們查詢新的訪問令牌時都不會獲得新的刷新令牌。

我也讀過這個堆棧溢出帖子。 我在這里錯過了什么嗎？ 您可能會在以下請求中找到一張圖片：

Answer 1

使用一次性刷新令牌是一種現代最佳實踐，因為如果相同的刷新令牌被使用兩次，這允許授權服務器踢出用戶。

怎么會這樣？ 例如，如果刷新令牌被盜，那么黑客和您的應用程序都會嘗試使用它！ 否則很難檢測到系統中的黑客

Answer 2

首先，你混淆了兩件事。 使用 JWT 和 Oauth 授權令牌和刷新令牌開放 ID Connect 身份驗證。

這是兩個不同的對象。 每次獲得訪問令牌時，您都會獲得一個新的 OAuth 刷新令牌。 這就是 OAuth 授予您“無限會話”的方式，但可以選擇在任何嘗試交換時拒絕新的訪問令牌。

另見 RFC https://datatracker.ietf.org/doc/html/rfc6749#section-1.5

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

               Figure 2: Refreshing an Expired Access Token