在寫我自己的之前，我已經閱讀了多篇博客文章和 StackOverflow 問題。我有多個查詢，但沒有一個帖子回答它們。
我正在使用 Keycloak Spring Security Adapter 來保護我的舊 Spring 應用程式。
例如：訪問 localhost:8080/about.htm 會將我重定向到 keycloak 登錄螢屏，并且在成功驗證后，我將能夠查看我的頁面。我還使用以下代碼從令牌中讀取用戶詳細資訊，
KeycloakPrincipal<KeycloakSecurityContext> kp = (KeycloakPrincipal<KeycloakSecurityContext>) auth.getPrincipal();
IDToken idToken = kp.getKeycloakSecurityContext().getIdToken();
user.setUsername(idToken.getPreferredUsername());
現在當我使用郵遞員測驗這個應用程式并修改生成的訪問令牌時，顯然服務器給出了錯誤。參考：如何使用郵遞員測驗應用程式。
但是，這是流程：
客戶端向資源服務器發送請求，資源服務器檢查令牌 - 如果存在，則客戶端進行驗證。如果它不存在或無效，它會重定向到授權服務器（KC）。
我的問題是，
- 誰在驗證這個令牌？如果我擺弄令牌，郵遞員流程如何引發錯誤？
- 我真的需要在我的應用程式中為每個請求撰寫一個 JwtTokenValidator 嗎？會不會太過分了？
- 如果我使用 Client Authenticator as Signed Jwt with client secret，是否仍需要此驗證？我沒有使用它，因為它會引入延遲。
請協助。
uj5u.com熱心網友回復：
回答#1：
當您在應用程式中使用任何 Keycloak 配接器（在您的情況下是用于 Keycloak 的 Spring 配接器）時，這就是執行驗證并在必要時重定向到登錄的人。作為驗證的一部分，它會檢查 Keycloak 頒發的令牌的簽名。因此，當您擺弄令牌時，簽名不匹配，因此會引發錯誤。
回答#2
不，您不需要實作 JwtTokenValidator。配接器會為您執行此操作，并且僅當請求具有有效令牌時，它才應該到達您的端點/URL。如果您對驗證令牌有特殊要求（例如，針對某些服務檢查令牌中的特定宣告），您可能只需要這樣做。否則，您可以安全地使用從KeycloakSecurityContext. 您甚至可以根據您的 URL 模式設定授權，并且 Keycloak 也會強制執行它們，如果用戶具有必要的角色（如本示例），則允許請求通過。
回答#3：
該選項僅將用于對您的應用進行身份驗證的方法更改為 Keycloak，并且與您應用內的用戶令牌驗證無關。在您當前的設定中，當您的應用想要與 Keycloak 通信時（例如，使用身份驗證令牌交換身份驗證代碼），它會使用 client-id/client-secret 對向 Keycloak 進行身份驗證（否則 Keycloak 不會知道它是您的應用并且會拒絕請求）。
如果您選擇“Signed Jwt with Client Secret”選項，您的客戶端不能只使用客戶端密碼來向 Keycloak 進行身份驗證。它應該支持 RFC7523 規范。因此，與簡單的客戶秘密方法相比，它相當復雜。在您信任您的客戶的環境中（例如，他們都是公司內部開發的知名應用程式，您不會支持公共客戶加入您的 Keycloak 并使用其服務），使用 client-secret 非常普遍且安全方法。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/495515.html
上一篇：MySQL選擇查詢花費太多時間