將Keycloak用作授權服務器，將Zuul用作API網關

Question

我目前正在使用Spring Boot構建一個微服務后端，Zuul作為API網關，而Keycloak作為身份驗證和身份提供者。 對於我的前端，我目前正在使用帶有授權代碼授予功能的Angular作為SPA。 在將請求發送到微服務之前，API網關應通過Keycloak驗證每個請求（如果用戶被授權）。 每個微服務（ResourceServer）都應該能夠使用自省端點獲取當前請求的用戶信息。

實施此方法的正確方法是什么，或者這甚至是一個錯誤的設計，而我的方法也不正確？

Answer 1

通常，您有兩個選擇：

1. 給客戶端的JWT ：客戶端（在您的情況下為Angular SPA）進行身份驗證並接收JWT。 一方可以使用Keycloak公鑰來驗證JWT令牌。 它還包含許多用戶信息。

2. 給后端的JWT：給予客戶端臨時授權碼授予。 它被轉發到后端系統，由后端系統將其交換為JWT。 后端系統將需要創建用戶會話，將JWT存儲在用戶會話中，並使用會話ID cookie（或類似機制）將客戶端與會話進行匹配。

擬議的體系結構是兩個世界的混合體。 選項1會更自然。

• 選項1 ：客戶端通過Keycloak進行身份驗證並獲取JWT。 然后，它將JWT附加到每個請求。 Zuul可以檢查JWT是否已由受信任的Keycloak實例簽名，並且尚未到期（無需聯系Keycloak）。 微服務可以做到這一點。 如果需要的不僅僅是基本用戶信息，則微服務可以聯系Keycloak。

• 選項2：我無法告訴您Zuul是否可以使用選項2。 讓我們假設它是。 如果是這樣，網關會將未經身份驗證的請求重定向到Keycloak。 客戶端收到授權碼授予后，它將被重定向到API網關。 然后，API網關聯系Keycloak交換JWT的代碼並將其保存在會話中。 給客戶端一個會話ID。 當請求轉發到微服務時，會將JWT添加到請求中。 客戶端永遠不會看到JWT。

這些描述假定您使用的是Keycloak支持的Open ID Connect 。 如果您使用OAuth 2設置，大多數情況仍然適用，但一些細節更為復雜，例如，代替包含所有信息的JWT，您將獲得一個不透明令牌，該令牌只能根據自省端點進行驗證。