重要的事說在前頭

• 在/protocol/openid-connect/token請求過程中（認證，獲取code，刷新token等）， client_id要保持一致，不能混用
• 使用哪個client_id進行的表單登錄，生成的code碼，就用哪個client_id來獲取token
• token中是哪個client_id，就用哪個client_id來刷新token
• scope授權范圍是在授權碼認證中使用的，在keycloak中可以為客戶端添加默認的scope和可選的scope
  • 在獲取code環節protocol/openid-connect/auth使用scope參數，而不是通過code獲取token環節/protocol/openid-connect/token
  • keycloak中，默認的scope（Default Client Scopes）可以通過scope=openid獲取，而可選的scope(Optional Client Scopes)，必須在獲取code時手動指定，多個scope值之間使用空格連接

概念

OAuth 2.0 中(zhong)的授權(quan)碼(ma)認(ren)證（Authorization Code Grant）是一種常用(yong)(yong)的身(shen)份驗證和授權(quan)方式，主要用(yong)(yong)于用(yong)(yong)戶(hu)通過第三方應用(yong)(yong)訪(fang)問受保護的資源。以下是關(guan)于授權(quan)碼(ma)認(ren)證的詳細介紹：

授權碼認證流程

1. 用戶請求授權：

   • 用戶在客戶端應用（如移動應用或網頁）上點擊“登錄”或“授權”按鈕。
   • 客戶端將用戶重定向到授權服務器的授權端點，并附帶一些參數，包括：
     • response_type=code：表示請求授權碼。
     • client_id：客戶端的唯一標識符。
     • redirect_uri：用戶授權后重定向的地址。
     • scope：客戶端請求的權限范圍。
     • state：防止CSRF攻擊的隨機字符串。

2. 用戶登錄并授予權限：

   • 用戶在授權服務器上登錄（如果尚未登錄），并查看客戶端請求的權限范圍。
   • 用戶同意授權后，授權服務器會生成一個授權碼，并將其附加到重定向URI中返回給客戶端。

3. 客戶端使用授權碼獲取訪問令牌：

   • 客戶端接收到授權碼后，會向授權服務器的令牌端點發送請求，包含以下信息：
     • grant_type=authorization_code：表示使用授權碼模式。
     • code：剛才獲得的授權碼。
     • redirect_uri：與初始請求中的重定向URI相同。
     • client_id 和 client_secret：用于驗證客戶端身份。

4. 授權服務器返回訪問令牌：

   • 授權服務器驗證授權碼和其他信息是否有效。如果有效，將生成并返回訪問令牌（Access Token）和可選的刷新令牌（Refresh Token）。

5. 客戶端使用訪問令牌訪問資源：

   • 客戶端可以使用獲取到的訪問令牌來訪問受保護的資源，通常是在請求頭中添加 Authorization: Bearer {access_token}。

優勢

• 安全性高：由于訪問令牌是通過授權碼交換得到的，避免了在用戶的瀏覽器中直接暴露訪問令牌。
• 適用于用戶代理：特別適合需要用戶交互的場景，如Web應用和移動應用。
• 支持單點登錄：用戶只需登錄一次，即可在多個客戶端之間共享訪問令牌。

注意事項

• 使用 HTTPS 來保護通信，防止中間人攻擊。
• state 參數用于防止 CSRF 攻擊，確保請求的完整性。
• 授權碼通常是短期有效的，訪問令牌也可能有過期時間，需合理管理。

示例圖解

用戶 --> 客戶端 --> 授權服務器
    |             |
    |-- 登錄 ---->|
    |<--- 授權碼-|
    |             |
    |-- 訪問令牌->|
    |<--- 資源 ---|

keycloak中授權碼認證的過程

一 密碼認證[direct grant]

• POST /auth/realms/demo/protocol/openid-connect/token
• 請求體 x-www-form-urlencoded
• 不支持scope參數，密碼認證的scope就是client_id配置的scope

grant_type:password
username:test
password:123456
client_secret:ec0fd1c6-68b0-4c39-a9fa-c3be25c8ef01
client_id:democlient

• 響應

{
    "access_token": "xxx",
    "expires_in": 3000,
    "refresh_expires_in": 1800,
    "refresh_token": "xxx",
    "token_type": "bearer",
    "not-before-policy": 1619512543,
    "session_state": "765969ec-94da-4edb-9dcb-e15ea3e0ad3b",
    "scope": "roles email profile" // 當前democlient這個客戶端的默認權限范圍
}

二 授權碼登錄

請求code

對于沒有認證的接口，將會返回401，即沒有登錄，這時keycloak會將我們的請求重定向到keycloak的登錄而，這時有幾個參數將被發到keycloak服務端，用來獲取code信息。
主要包括以下(xia)幾個(ge)參數 ：

Response_type：表示響應類型，這里我們是code
Client_id：表示為你這個客戶端頒發的唯一標識
Redirect_uri：表示從keycloak服務端注冊的合法的回調地址，支持通配符
Scope：表示認證范圍，表示用戶的openid方式，可以根據調用它需要，使用對應范圍的scope

• GET /auth/realms/demo/protocol/openid-connect/auth
• QUERY

client_id:democlient
scope:openid // 表示客戶端默認的權限范圍，當為客戶端配置了多個可選的范圍時，可以在這里指定你想要的權限范圍
response_type:code
client_secret:ec0fd1c6-68b0-4c39-a9fa-c3be25c8ef01
redirect_uri://localhost:9090/callback

• 跳轉到kc的登錄頁，完成用戶名和密碼的登錄
  
• 登錄成功之后，跳回callback刪除，在url參數上帶上了code
  

請求token

• POST /auth/realms/fabao/protocol/openid-connect/token
• 請求體 x-www-form-urlencoded

grant_type:authorization_code
code:68058719-add6-4b40-ab96-8e71af03827a.7a31b1a9-c3e8-46d4-b8cc-345012fcf4a2.25e52f60-5991-43dd-9108-873f60af385d
client_id:democlient
client_secret:ec0fd1c6-68b0-4c39-a9fa-c3be25c8ef01
redirect_uri://localhost:9090/callback

• 響應

{
    "access_token": "xxx",
    "expires_in": 3000,
    "refresh_expires_in": 1800,
    "refresh_token": "xxx",
    "token_type": "bearer",
    "id_token": "xxx",
    "not-before-policy": 1619660302,
    "session_state": "14812f50-b9f7-4cee-be56-bf9bef5c961a",
    "scope": "openid roles email profile" // 我們獲取code時傳遞的scope是openid，它返回的scope是openid roles email profile，這說明roles email profile這三個是客戶端默認的授權范圍
}

客戶端授權范圍

三 JWT token解析

• PAYLOAD數據載體主要包括用戶ID，用戶名，用戶角色，過期時間等信息
• Sub：用戶ID
• preferred_username：賬號名稱
• Name:用戶姓名
• Email：電子郵件
• realm_access:領域角色
• resource_access：客戶端（資源服務）角色
• Azp：授權客戶端
• Typ：token的類型
• Aud：被授權的客戶端列表
• Exp：過期時間
• Iss: 當前領域的開放API

四 Scope對jwt的影響

我們可以配置域的scope，或者對指定的client配置 scope，如圖

圖中，我們把客戶端democlient的scope里的roles移除后，在返回的token里將不會出現和角色有關的信息，即realm_access和resource_access將被移除。