技術文章 » 如何實現一套簡單的oauth2授權碼型別認證，一些思路，供參考

如何實現一套簡單的oauth2授權碼型別認證，一些思路，供參考

2023-11-21 06:00:29

背景

組內人不少，今年陸陸續續研發了不少系統，一般都會包括一個後臺管理系統，現在問題是，每個管理系統都有RBAC那一套使用者許可權體系，實在是有點浪費人力，於是今年我們搞了個統一管理各個應用系統的RBAC的系統，叫做應用許可權中心，大致就是：

  1. 各個應用在我們系統註冊，並錄入應用支援的各類許可權（如選單許可權、資料許可權、介面許可權等）；
  2. 統一管理所有使用者（包括公司員工、合作伙伴員工等）；
  3. 各個接入系統的管理員可以在自己的應用建立角色，賦予其某些許可權；接下來，又可以給人員分配這些角色。

在以上資料維護完成後，就可以由我們系統提供oauth2認證這一套體系，oauth2簡單理解，類似於平時那些網站的第三方渠道登入，比如，第一次去到一個陌生網站，不想註冊使用者、密碼那些，此時，如果網站支援微信、qq、google、github等登入方式，就很方便，登入完成後，這個網站就已經知道我們是誰了，知道我們是誰之後，再來做許可權也就簡單了，還是RBAC那一套。

由於我們的應用許可權中心管理了多個應用的許可權，所以可以給某個人分配各個系統下的角色，這個人也就有了各個系統下的許可權。

oauth2那一套，是在使用者完成身份認證的基礎下才能走完整個流程的，那就是說，已經知道這個使用者是誰了，那就可以去應用許可權中心獲取這個人在裡各個應用下有哪些角色，有哪些許可權了。

oauth2的整體資料流

oauth2這個東西，流程圖比較複雜，我就不從這方面去講了，我先說下大體思路，然後直接給大家看我們系統的網路抓包資料，來了解整個資料流向吧。

我們這裡涉及兩個系統的互動，一個是類似於微信、qq、github這種的oauth2授權伺服器，一個是需要接入到這些授權伺服器的應用，如應用A，它的角色是oauth2使用者端。

現在開發應用A，一般都是前後端分離，前端呼叫應用A後端介面，此時假設使用者是沒登入，後端介面判別到這種情況，給前端拋錯誤碼，前端此時就再呼叫後端另一個介面，該介面會組裝一個指向oauth2授權伺服器的授權請求url，意思是前端需要到授權伺服器那邊去進行身份認證、授權等，前端拿到這個url，就跳轉過去。

跳轉過去後，oauth2伺服器那邊會檢查使用者在這邊登入了沒有，沒登入的話，流程沒法繼續往下走，會先把這個授權請求給儲存下來，然後讓使用者登入；使用者登入成功後，再把之前儲存的那個請求拿出來執行。

授權請求主要做的事情就是，檢查引數是否合法，如這個第三方應用在自己這邊註冊了沒，如果檢查沒問題，就會隨機生成一個臨時的code，拼接到第三方應用提供的回撥url中，然後302重定向到第三方應用A。

第三方應用A需要拿著這個code，請求自己的後端，第三方應用的後端拿到code後，去通過後臺http呼叫，呼叫授權伺服器的根據code獲取token的介面，拿到token後，返回給第三方應用A的前端。

後續，第三方應用的前端每次請求就帶著這個token來請求後端，後端拿著token去請求授權伺服器，獲取這個token對應的使用者資訊，許可權資訊（如這個人在應用A中有哪些選單許可權等），進行許可權控制。

技術選型

目前，要實現oauth2使用者端的話，可以選擇spring security，具體可以看官網檔案。

要實現oauth2授權伺服器的話，有如下選擇：

spring-authorization-server

spring官方釋出的第二代的授權服務專案，但目前使用的人較少，感覺也還不是很成熟。且因為還在使用java8，所以只能用0.4.x的版本，就更不成熟了。

https://spring.io/projects/spring-authorization-server

版本 Initial Release End of Support jdk 備註
1.1.x 2023-05-16 2024-05-16 java17 https://docs.spring.io/spring-authorization-server/docs/current/reference/html/getting-started.html
1.0.x 2022-11-21 2025-11-21 java17 https://docs.spring.io/spring-authorization-server/docs/1.0.3/reference/html/getting-started.html
0.4.x 2022-11-20 2025-11-21 Java 8 https://docs.spring.io/spring-authorization-server/docs/0.4.3/reference/html/getting-started.html

座標：

https://mvnrepository.com/artifact/org.springframework.security/spring-security-oauth2-authorization-server

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
    <version>0.4.3</version>
</dependency>

OAuth2 For Spring Security

https://mvnrepository.com/artifact/org.springframework.security.oauth/spring-security-oauth2

座標：

<dependency>
    <groupId>org.springframework.security.oauth</groupId>
    <artifactId>spring-security-oauth2</artifactId>
    <version>2.5.2.RELEASE</version>
</dependency>

現狀：

已經不再維護，最新版本2.5.2也還有多個cve漏洞，由於我們目前要求必須解決各種cve漏洞（一般靠版本升級解決，但這個已經是最新版本了沒法升了）.

另外，其內部實現中使用了session+cookie機制，當時以為是有狀態的，不支援叢集部署，後來才知道也是支援用redis之類的（靠spring session專案）。

另外，前後端未分離，客製化頁面較為複雜

https://spring.io/blog/2022/06/01/spring-security-oauth-reaches-end-of-life

參考第二種實現的原始碼進行簡單實現

最終沒辦法，第二種因為cve漏洞的問題，加上前後端不分離可能導致以後擴充套件困難（比如登入要支援多因素認證等，會比較頭疼，還是做成前後端分離，交給專業前端比較好），最終決定第二種的原始碼進行修改。

實際的資料流

應用A：http://10.80.121.46:8086 前後端分離，後端介面都通過http://10.80.121.46:8086 nginx轉發

授權伺服器：http://10.80.121.46:8083 前後端分離，後端介面都通過http://10.80.121.46:8083 nginx轉發

應用A檢測到使用者未登入

比如，我們這邊的前端同事是這麼判斷：

const token = localStorage.getItem('token')
if (token == null) {
    window.location.href = "/v1/oAuth2Client/redirectToAuthorizeUrl";
}

我們以前的專案也有這樣的：

if (response.status === 401) {
	window.location.href = "/oauth2/authorization/";
}

反正都是通過前端或後端知道使用者沒登入後，呼叫本應用的另一個介面。

應用A組裝呼叫授權伺服器的url

直接看下面報文，後端組裝了一個指向授權伺服器（http://10.80.121.46:8083）的授權介面（v1/oauth2/authorize）的url，還帶了查詢引數，client_id代表應用A自己，redirect_uri表示授權伺服器回撥自己的地址，response_type=code，表示使用oauth2的授權碼流程

GET /v1/oAuth2Client/redirectToAuthorizeUrl HTTP/1.1
Host: 10.80.121.46:8086
Connection: keep-alive
...

HTTP/1.1 302 
Server: nginx/1.22.1
...
Location: http://10.80.121.46:8083/v1/oauth2/authorize?client_id=app-A&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

注意，這裡是直接後端返回了302，指示瀏覽器跳轉到授權伺服器，此時，如果有授權伺服器這個domain下的cookie，是可以攜帶過去的；一般，我們都會在使用者在授權伺服器登入完成後，在授權伺服器domain下寫個cookie，避免每次都要登入。

授權伺服器檢測到使用者未登入

第一次流程，使用者瀏覽器肯定是沒有授權伺服器domain下的cookie的，此時，我們後端就會把使用者302重定向到授權伺服器這邊的統一登入頁面：

GET /v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo HTTP/1.1
Host: 10.80.121.46:8083
...

HTTP/1.1 302 
Server: nginx/1.22.1
*
Location: http://10.80.121.46:8083/#/oauth-login?appCode=app-A&originUrl=aHR0cDovLzEwLjgwLjEyMS40Njo4MDgzL2FwcC1hdXRob3JpdHktYWRtaW4vdjEvb2F1dGgyL2F1dGhvcml6ZT9jbGllbnRfaWQ9YXBwLWRldi1wbGF0Zm9ybS1hZG1pbiZyZWRpcmVjdF91cmk9aHR0cDovLzEwLjgwLjEyMS40Njo4MDg2LyZyZXNwb25zZV90eXBlPWNvZGUmc2NvcGU9Zm9v

這個認證介面的後端處理也簡單，檢測請求攜帶了標識使用者已登入的cookie沒有，沒有的話，重定向到登入頁。

登入頁攜帶了一些引數，這裡最主要的是originUrl，這是因為，後端做的無狀態，在完成登入請求後，還需要繼續請求原始介面：

/v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

所以，我這邊選擇把原始介面base64編碼後，傳給前端，由前端在完成登入後再次發起呼叫。

另外，這個登入頁，大概下面這樣：

http://10.80.121.46:8083/#/oauth-login

登入

POST /v1/oauth2/oAuth2Login HTTP/1.1
Host: 10.80.121.46:8083
Connection: keep-alive
...

{"username":"admin","password":"f80e247e3ead3dd1f3a708b7ce4dcf54"}

這邊不重要的引數就省了，就是使用者名稱密碼那些，還包括驗證碼啥的。

響應：

HTTP/1.1 200 
...
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: http://10.80.121.46:8083
Access-Control-Allow-Credentials: true
Set-Cookie: SSO-JSESSIONID=f09b9e61d4114a058cd6f9b6b9ce85d7; Path=/; Domain=10.80.121.46; Max-Age=43200; Expires=Tue, 21 Nov 2023 01:11:42 GMT

登入邏輯：生成個亂數（token），然後作為key，使用者資訊為value，存redis，然後再就是把token寫到domain下，寫個cookie；

這塊必須用cookie，因為瀏覽器在從應用A跳過來的時候，只有cookie才能帶的過來，我們才知道使用者是登入了沒的。

前端在收到登入成功的code後，就把上一步的originUrl解碼，然後重新發起呼叫：

/v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

授權介面邏輯

主要就是各種引數校驗，如client_id是否在授權伺服器註冊，各個引數的值是否合法，這塊可以參考spring的程式碼實現。

一切沒問題的話，就是生成個隨機code，然後把code作為key，其他各種使用者資訊、認證請求的相關資訊為value，儲存到redis，然後就可以跳轉回應用A了。

跳到應用A的什麼地址呢，我們授權請求不是傳了個redirect_uri嗎，就重定向到哪裡，只是會給你拼個code在後面

GET /?code=eEg7t5 HTTP/1.1
Host: 10.80.121.46:8086
...

攜帶code跳轉回應用A

GET /?code=eEg7t5 HTTP/1.1
Host: 10.80.121.46:8086

我這邊是跳轉回應用A的前端的，前端拿到code，呼叫應用A的後端介面：利用code去請求授權伺服器，獲取token。

應用A前端呼叫後端介面，code換token

POST /v1/oAuth2Client/fetchAccessTokenByAuthorizeCode HTTP/1.1
Host: 10.80.121.46:8086
...

{"code":"eEg7t5"}

HTTP/1.1 200 
...

{"code":"0","message":"success","data":{"scope":"all","access_token":"eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQ3NDAsInVzZXJuYW1lIjoiYWRtaW4iLCJleHRlbmQiOm51bGwsImV4cCI6MTcwMDU3MjMwM30.HxH99Z3Mz4IZfHlC_Ai1th7jURlNs5qsHSMpiQdtGgXDqX8_XNx9GxswB","token_type":"bearer","refresh_token":null,"expires_in":86400}}

後端就是拿著code，去請求授權伺服器，拿到了token，我這邊是直接把token給了前端儲存。

後續的請求，前端都會攜帶token，後端判斷token是否有效即可（大家肯定不希望每次都去授權伺服器校驗token，所以可以第一次的時候，拿token去授權伺服器驗證是否有效，並快取結果；我這邊更暴力，因為都是組內的系統，直接弄的jwt token，且token沒加密）

根據token獲取使用者資訊

前端拿著token去呼叫應用A後端介面，獲取使用者資訊；

POST /v1/oAuth2Client/queryUserInfo HTTP/1.1
Host: 10.80.121.46:8086
Connection: keep-alive
Content-Length: 0
AccessToken: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQ3NDAsInVzZXJuYW1lIjoiYWRtaW4iLCJleHRlbmQiOm51bGwsImV4cCI6MTcwMDU3MjMwM30.HxH99Z3Mz4IZfHlC_Ai1th7jURlNs5qsHSMpiQdtGgXDqX8_XNx9G

HTTP/1.1 200 
...

{"code":"0","message":"請求成功","data":{"id":4740,"username":"admin","departmentName":null,"status":0,"statusName":"正常","roleListInfo":[]}}

使用者資訊都有了，獲取許可權資訊也是一樣的，這裡不展示了。

簡單的技術總結

我這邊自己實現，是沒辦法，開源的沒能滿足自己要求，其實還有一點，我們那個使用者名稱是可能重複的，就是說，在統一登入頁，輸入使用者名稱，可能在後臺查到多個使用者，只能加上另一個內部的隱性欄位才能不重，這也是我們必須自研的原因。我實現的比較簡單，不是一個圓的輪子，僅供大家參考（一些異常場景，由於對oauth2的認識也不是特別深，只能以後慢慢完善了）

大家如果自研授權伺服器，肯定涉及在授權伺服器域名下寫cookie，此時注意，後端介面都通過前端的nginx去轉，會減少很多跨域相關的問題，信我的沒錯，我都踩過了。

另外，有時候後端直接重定向有問題時，就可以將要重定向的地址給到前端，由前端去window.location.href跳轉也是ok的，也會減少一些跨域問題。

有問題可以留言，謝謝大家。

參考

https://www.cnblogs.com/cjsblog/p/10548022.html

https://mp.weixin.qq.com/s/AW3zkzIYR6kbQVbPlQmpMA 寫cookie遇到問題時參考本篇

https://www.springcloud.io/post/2022-04/spring-samesite/

https://www.ituring.com.cn/article/200275