在上一篇文章中，我們整體介紹 OIDC / OAuth2.0 協議（ 點擊下方圖片即可查看 ），本次我們將重點圍繞授權碼模式（Authorization Code）以及接入 Authing 進行介紹，從而讓你的系統快速具備接入用戶認證的標準體系。

接入 Authing 后的優(yōu)勢：

在整個 Authing 的身份源中，已經包含了社會化登錄方式 微信、微博、QQ、FB、TW ...等等，企業(yè)登錄方式 飛書、釘釘、企微、AD 等等，只要你完成了接入 Authing 就意味著你的業(yè)務系統具備了這些能力。

01.授權碼模式（Authorization Code）

授權碼模式適合應用具備后端服務器的場景。授權碼模式要求應用必須能夠安全存儲密鑰，用于后續(xù)使用授權碼換 access_token。授權碼模式需要通過瀏覽器與終端用戶交互完成認證授權，然后通過瀏覽器重定向將授權碼發(fā)送到后端服務，之后進行授權碼換 token 以及 token 換用戶信息。

1.1 整體流程

整體上，有以下流程：

1. 在你的應用中，讓用戶訪問登錄鏈接，瀏覽器跳轉到 Authing，用戶在 Authing 完成認證。

2. 瀏覽器接收到一個從 Authing 服務器發(fā)來的授權碼。

3. 瀏覽器通過重定向將授權碼發(fā)送到你的應用后端。

4. 你的應用服務將授權碼發(fā)送到 Authing 獲取 AccessToken 和 IdToken，如果需要，還會返回 refresh token。

5. 你的應用后端現在知道了用戶的身份，后續(xù)可以保存用戶信息，重定向到前端其他頁面，使用 AccessToken 調用資源方的其他 API 等等。

流程圖如下：

1.2 準備接入

在 Authing 創(chuàng)建應用及配置

創(chuàng)建應用：

配置登錄回調和登出回調，配置為你實際項目的地址，我們在這里配置 localhost 用于測試。

若你想匹配多個登錄/登出回調，可以使用 ‘*’ 號進行通配，登錄/登出回調可以是如下格式：

在協議配置中，我們勾選 authorization_code 并且使用 code 作為返回類型，如下圖所示：

1.3 接入測試

01 所需調用接口列表

GET${host}/oidc/auth 發(fā)起登錄（拼接你的發(fā)起登錄地址）

POST${host}/oidc/token 獲取 Token

GET${host}/oidc/me 獲取用戶信息

POST${host}/oidc/token/introspection 校驗 Token

POST${host}/oidc/token 刷新 Token

POST${host}/oidc/revocation 吊銷 Token

GET${host}/session/end 登出

02 Run in Postman

以下要介紹的接口可以通過我們的在線 postman collection 自行 fork 體驗。

03 發(fā)起登錄

這是基于瀏覽器的 OIDC 的起點，請求對用戶進行身份驗證，并會在驗證成功后返回授權碼到您所指定的 redirect_uri。

拼接發(fā)起登錄地址（瀏覽器中打開）：

https://{host}/oidc/auth?scope=openid+profile+email+phone+username&redirect_uri={redirect_uri}&response_type=code&client_id={應用 ID}&state={state}

如您需要額外獲取 refresh_token 則請求格式為：

https://{host}/oidc/auth?

scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&client_id={應用 ID}&prompt=consent&state={state}

點此體驗：

https://oidc-authorization-code.authing.cn/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=054d3c0e-9df9-46f2-a8fa-a7f479032660&client_id=63eb4585156d977101dd3750&state=1676366724

參數說明：

04 獲取 Token

用戶在 Authing 側完成登錄操作后， Authing 會將生成的 code 作為參數回調到 redirect_uri 地址，此時通過 code 換 token 接口即可拿到對應的訪問令牌 access_token 。

1. 請求參數

2. 請求事例

3. 響應示例 (成功)

4. 響應示例 (失敗)

05 通過 AccessToken 獲取用戶信息

此端點是 OIDC 獲取用戶端點，可以通過 AccessToken 獲取有關當前登錄用戶的信息。

1. 請求參數

2. 請求示例

3.?響應示例 (成功)

4.?響應示例 (失敗)

06 校驗 Token

此端點接受 access_token、id_token、refresh_token ，并返回一個布爾值，指示它是否處于活動狀態(tài)。如果令牌處于活動狀態(tài)，還將返回有關令牌的其他數據。如果 token 無效、過期或被吊銷，則認為它處于非活動狀態(tài)。

1. 驗證 Token 分為兩種方式：

本地驗證與使用 Authing 在線驗證。我們建議在本地驗證 JWT Token，因為可以節(jié)省你的服務器帶寬并加快驗證速度。你也可以選擇將 Token 發(fā)送到 Authing 的驗證接口由 Authing 進行驗證并返回結果，但這樣會造成網絡延遲，而且在網絡擁塞時可能會有慢速請求。

access_token 可以使用 RS256 簽名算法或 HS256 簽名算法進行簽名。下面是這兩種簽名算法的區(qū)別：

RS256?是使用RSA算法的一種數字簽名算法，它使用公鑰/私鑰對來加密和驗證信息。RS256 簽名生成的令牌比 HS256 簽名生成的令牌更加安全，因為使用RSA密鑰對進行簽名可以提供更高的保護級別。使用RS256簽名算法的令牌可以使用公鑰進行驗證，公鑰可以通過 JWK 端點獲取。

HS256?是使用對稱密鑰的一種數字簽名算法。它使用同一個密鑰進行簽名和驗證。HS256 簽名算法在性能方面比 RS256 簽名算法更快，因為它使用的是對稱密鑰，而不是使用 RSA 公鑰/私鑰對來簽名和驗證。使用 HS256簽名算法的令牌可以通過 shared secret （應用密鑰）進行驗證。

在實際應用中，RS256算法更加安全，但同時也更加消耗資源，如果系統需要高性能，可以選擇 HS256 簽名算法。

以下是本地驗證和在線驗證的優(yōu)劣對比：

2. 在線驗證

?? 需要注意的是，id_token 目前無法在線校驗，因為 id_token 只是一個標識，若需要校驗 id_token 則需要您在離線自行校驗。

請求參數

請求示例

校驗 access_token 響應示例（校驗通過）

校驗 access_token 響應示例（校驗未通過）

校驗 refresh_token 響應示例 (校驗通過)

校驗 refresh_token 響應示例（校驗未通過）

3. 離線校驗

可參考文檔：離線校驗

文檔鏈接：https://docs.authing.cn/v2/guides/faqs/how-to-validate-user-token.html#

我們簡單說下，若您使用離線校驗應該對 token 進行如下規(guī)則的校驗：

1. 格式校驗 - 校驗 token 格式是否是 JWT 格式

2. 類型校驗 - 校驗 token 是否是目標 token 類型，比如 access_token 、id_token、refresh_token

3. issuer 校驗 - 校驗 token 是否為信賴的 issuer 頒發(fā)

4. 簽名校驗 - 校驗 token 簽名是否由 issuer 簽發(fā)，防止偽造

5. 時間校驗 - 校驗 token 是否在有效期內

6. claims 校驗 - 是否符合與預期的一致

以上 6 點均校驗通過，我們才能認為 token 是有效且合法的。

下面是一個示例 Java 代碼，可以用于在本地校驗 OIDC RS256 和 HS256 簽發(fā)的 access_token 。

這段代碼使用 Nimbus JOSE+JWT 庫來解析和驗證 JWT token。它使用指定的 issuer 和 audience 值對access_token 進行驗證，并驗證 JWT 中 claims 的格式、類型、簽名、有效期和 issuer。如果發(fā)生任何驗證錯誤，則將拋出 RuntimeException。使用時需要傳入對應的 JWK URL 和 access_token 進行調用，例如：

這個示例只校驗了RS256和HS256簽名算法。

07?刷新 Token

此功能用于用戶 token 的刷新操作，在 token 獲取階段需要先獲取到 refresh_token 。

1. 請求參數

2. 請求示例

3.?響應示例(成功)

4.?響應示例（失?。?/strong>

08?撤回 Token

撤銷 access_token / refresh_token?

1. 請求參數

2. 請求示例

3.?響應示例（成功）

4. 響應示例（失敗）

09 用戶登出

使用此操作通過刪除用戶的瀏覽器會話來注銷用戶。

post_logout_redirect_uri?可以指定在執(zhí)行注銷后重定向的地址。否則，瀏覽器將重定向到默認頁面

1. 請求參數

2. 請求示例?(瀏覽器訪問)

02.SSO (Single Sign-On) ?單點登錄 & SLO (Single Logout) 單點登出

2.1?SSO 實現

SSO(Single Sign-On) 單點登錄，即同時訪問多個應用僅需要登錄一次。

舉例：我們現在有兩個站點分別是

uthing.com?

ething.com?

我們希望用戶在 uthing.com 進行認證后，跳轉到 ething 后無需二次認證，反之也是一樣的。

具體流程：

1. 用戶訪問 uthing.com ，uthing 前端發(fā)現用戶未認證，跳轉至 Authing 進行認證。

2. 用戶在 Authing 發(fā)起認證完成，Authing 創(chuàng)建 SSO Session ，下發(fā)臨時授權碼 (code) 重定向到 uthing 后臺。

需要注意的是，在這里我們也可以重定向到前端頁面，再由前端頁面自行判斷如果是 Authing 回調請求，則攜帶臨時 code 到 uthing 后臺去獲取 token 。

3. uthing 后臺通過 code 向 Authing 換取 access_token、id_token、refresh_token 等，并下發(fā)給前端。

4. uthing 前端通過 access_token 可以直接向 Authing OIDC 用戶信息端點獲取當前用戶信息。

5. uthing 前端在在后續(xù)請求后臺時，攜帶由 Authing 頒發(fā)的 access_token ，后臺在接受到用戶請求后去 Authing 校驗 Token 是否有效，有效則可放行，若 Token 校驗失敗或已過期則返回錯誤信息。

6. 用戶訪問 ething.com ，ething 跳轉至 Authing 進行認證。

7. 由于用戶在 Authing 已經完成認證，創(chuàng)建了 sso_session ，Authing 側直接下發(fā)臨時授權碼 (code) ，無需二次認證，后續(xù)流程同 1 。

???

我們發(fā)現，用戶在 uthing 認證成功的時候，再訪問 ething 的時候會向 Authing 跳轉一下，才能完成后續(xù)流程，這是由于 ething.com 和 uthing.com 并不是同一個站點，無法實現 cookie 共享，如果你的產品地址是 ：

uthing.xxx.com?

ething.xxx.com?

我們則可以利用相同域下 cookie 共享的方式實現 SSO ，從而避免此問題。

2.2?SLO 實現

SLO(Single Logout) 單點登出，即多個應用僅需要登出一次，其他應用也自動登出 。

01 場景 1

如果你的產品地址是同一個域，例如：

uthing.xxx.com?

ething.xxx.com

則 SLO 流程如下：

1. 用戶在某個站點登出，我們則需要調用 OIDC 登出端點銷毀 Token，由于是 cookie 共享實現的 SSO ，然后清除 xxx.com 對應會話的 cookie 即可。

2. ething / uting 應當在每次發(fā)起請求前，判斷 cookie 中是否存在登錄態(tài)，若不存在，則需要跳轉默認頁面提示用戶已經登出。

02 場景 2

如果你的產品地址不是同一個域，例如：

uthing.com?

ething.com

則 SLO 流程如下：

1. 用戶在某個站點登出，我們則需要調用 OIDC 登出端點銷毀 Token，在 Authing 的應用配置中，你應當先把應用都添加到 SSO 中，或者 uthing.com 和 ething.com 使用 Authing 的同一個自建應用，當用戶在某個站點登出后，另外一個站點的 Token 也會失效。

2. 用戶未登出的站點發(fā)起請求，當后臺校驗 Token 失敗后，則下發(fā)清除 cookie 的命令并跳轉默認頁面提示用戶已經登出，需要登錄。

03.本章總結

本章我們介紹了 OIDC 授權碼模式的接入流程以及相關接口的調用方式，對于小白來說可能需要整體跑一遍流程才能熟悉，我們也建議你 fork 我們的 postman collection 跑一遍流程，對授權碼模式你就基本掌握啦。

接下來我們還會介紹 OIDC 的授權碼+PKCE 流程，以及接入 Authing 的方式，需要你對授權碼模式的流程有一定了解哦。

標簽：OAuth單點登錄IDaaSAuthingOIDC授權碼