如何在 Oauth2.0 中使用 refresh_token 重新生成 access_token

Question

我們使用 Spring Cloud Netflix Zull 作為后端服務的網關應用程序。 前端是 Angular。 但我們僅在 Postman 中測試端點（前端正在開發中）。 我們有一個名為LoginServiceModule模塊，另一個是ZullServerModule 。 LoginSericeModuke從前端獲取用戶名和密碼，並通過包含所需的標頭和正文來調用以下 oauth/token 端點。

 http://localhost:XXXX/login

和回應是

{
    "access_token": "XXXXXXXXX",
    "token_type": "bearer",
    "refresh_token": "XXXXXXXXX",
    "expires_in": 3600,
    "scope": "read write",
    "jti": "XXXXXXXXXXX"
}

ZullServerModule包含 ZullServerConfiguration、Authorization Server Configuration 和 Resource Server Configuration 等...

LoginModule像這樣在內部調用 oauth/token 端點。

ResponseEntity<String> loginResponse =  restTemplate.exchange("http://localhost:XXXX/oauth/token", HttpMethod.POST, entity, String.class);

和回應是..

{
    "access_token": "XXXXXXXXX",
    "token_type": "bearer",
    "refresh_token": "XXXXXXXXX",
    "expires_in": 3600,
    "scope": "read write",
    "jti": "XXXXXXXXXXX"
}

我們從響應中提取 access_token 並調用以下端點...

http://localhost:XXXX/ProjectName/api/endpointname?access_token={access_token}.

但是當 access_token 過期時，當我訪問上述后端服務 url 時，它說

{
    "error": "invalid_token",
    "error_description": "Access token expired:XXXXXXXXXXXXXXX(access_token)"
}

我知道它已過期並嘗試在終端中像這樣借助 refresh_token 重新生成 access_token

curl clientID:clientSecret@localhost:XXXX/oauth/token -d grant_type=refresh_token -drefresh_token={refresh_token}

但是我需要將它包含在我們的代碼中並且不知道將它放在哪里。 在網上搜索后，我遇到了ZullFilter 。 我嘗試了所有前置、路由和后置過濾器。 對於每個請求，它們都被執行（即只要 access_token 沒有過期），但是當令牌過期並且如果我測試端點時，沒有任何過濾器被執行並且我收到錯誤響應

{
    "error": "invalid_token",
    "error_description": "Access token expired: XXXXXXXXXX"
}

我已經在每個過濾器的運行方法中放置了 sysouts。 我也不太了解 filterOrder 。

@Override
public Object run() throws ZuulException {
    System.out.println("pre filter...");
    RequestContext context = 
    RequestContext.getCurrentContext();
    HttpServletResponse response = context.getResponse();
    System.out.println(response.getStatus());
    return null;
}

我想在 refresh_token 的幫助下控制 access_token 的生成。 我如何編碼，每當 access_token 過期時，如果我在過期后訪問資源，那么我就會知道該令牌已過期並重新生成 access_token 並使用新的 access_token 調用之前的調用。

Answer 1

通常是客戶端負責維護自己的令牌並在令牌即將到期時刷新它。 將此邏輯移動到您的 Zuul 層似乎是一個非常糟糕的主意。 考慮一下實現，它會如何工作？

一旦客戶端的令牌過期，它將使用永久過期的令牌調用您的端點，Zuul 必須嘗試每次請求刷新。 這將為每個 API 調用增加大量開銷。 您可能會引入某種黑客攻擊，您總是在響應標頭或其他內容中傳回新令牌……但此時您將違反OAuth2的授權流程。