目錄
- OAuth 授權框架
- 一、OAuth 角色
- 二、協議流程
- 三、應用注冊(Application Registration)
- 用戶 ID(Client ID) 和 用戶密碼(Client Secret)
- 四、權限授予
- 1、授權碼鏈接
- 2、用戶授權申請
- 3、應用程序接收授權碼
- 4、應用程序請求訪問令牌
- 5、應用程序接收訪問令牌
- 五、Casdoor 運行原理
- 1、應用向用戶請求授權
- 2、用戶給應用授權
- 3、API server 驗證 APP 的授權認證
- 4、API server 給 APP 頒發令牌
- 5、APP 用令牌給資源服務器驗證
- 6、APP 使用令牌訪問資源服務器資源
- 回調網址
- 代碼
- 后端代碼
- 前端代碼
OAuth 授權框架
OAuth 是一個授權框架,它使應用程序能夠在 HTTP 服務上獲得對用戶帳戶的有限訪問權限。它的工作原理是將用戶身份驗證委托給托管用戶帳戶的服務,并授權第三方應用程序訪問該用戶帳戶。OAuth 2 為 Web 和桌面應用程序以及移動設備提供授權流程。
一、OAuth 角色
-
資源擁有者(Resource Owner)
資源所有者是授權應用程序訪問其帳戶的用戶。應用程序對用戶帳戶的訪問權限僅限于授予的授權范圍(例如讀取或寫入訪問權限)。 -
客戶端(Client)
客戶端是想要訪問用戶賬戶的應用程序。在它可以這樣做之前,它必須得到用戶的授權,并且授權必須由 API 驗證。 -
資源服務器(Resource Server)
資源服務器托管受保護的用戶帳戶。 -
授權服務器(Authorization Server)
授權服務器驗證用戶的身份,然后向應用程序頒發訪問令牌。
從應用程序開發人員的角度來看,服務的 API 既可以充當資源服務器角色,也可以充當授權服務器角色。我們將把這兩個角色結合起來稱為服務或 API 角色。
二、協議流程
過程步驟:
- 應用向用戶請求訪問某服務資源的授權。
- 用戶授權應用的請求,給 [授權許可]。
- 應用提供自身的 [身份驗證] + [授權許可],請求 [訪問令牌]。
- [身份驗證] 通過且 [授權許可] 有效,頒發 [訪問令牌](即 token)。
- 應用使用 [訪問令牌] 請求資源服務器對應的資源。
- 若 [訪問令牌] 有效,允許訪問相應資源。
三、應用注冊(Application Registration)
在將 OAuth 與您的應用程序一起使用之前,您必須向該服務 API(授權服務器 + 資源服務器)注冊您的應用程序。這是通過服務網站的開發人員或 API 部分中的注冊表格完成的,您將在其中提供以下信息(可能還有關于您的應用程序的詳細信息):
- 應用名稱
- 申請網站(資源)
- 重定向 URL(Redirect URI)或回調 URL(Callback URL)
重定向 URI 是服務在用戶授權(或拒絕)您的應用程序后重定向用戶的位置,因此是您的應用程序將處理授權代碼或訪問令牌的部分。
用戶 ID(Client ID) 和 用戶密碼(Client Secret)
注冊應用程序后,該服務將以客戶端標識符和客戶端密碼的形式頒發客戶端憑據。客戶端 ID 是一個公開的字符串,服務 API 使用它來識別應用程序,還用于構建提供給用戶的授權 URL。Client Secret 用于在應用程序請求訪問用戶帳戶時向服務 API 驗證應用程序的身份,并且必須在應用程序和服務 API 之間保密。
四、權限授予
在前面概述的抽象協議流程中,前四個步驟涵蓋了獲取授權授予和訪問令牌。授權授予類型取決于應用程序請求授權所使用的方法,以及 API 支持的授權類型。OAuth 2 定義了三種主要的授權類型,每種類型在不同情況下都有用:
- 授權碼:與服務器端應用程序一起使用。
- 客戶端憑證:用于具有 API 訪問權限的應用程序。
- 設備代碼:用于缺少瀏覽器或有輸入限制的設備。
授權類型:授權碼
授權碼授予類型是最常用的,因為它針對服務器端應用程序進行了優化,其中源代碼不公開,并且可以維護 Client Secret 的機密性。這是一個基于重定向的流程,這意味著應用程序必須能夠與用戶代理(即用戶的網絡瀏覽器)交互并接收通過用戶代理路由的 API 授權代碼。
【授權碼】:用戶給 APP,用于 APP 向 API server 申請資源訪問令牌 token。
【令牌】:就是 token,API server 頒發給 APP,用于 APP 向資源服務器請求資源。
1、授權碼鏈接
首先給用戶提供授權碼鏈接:
https://cloud.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
拆解:
- 授權端點:
https://cloud.com/v1/oauth/authorize
- 應用程序的客戶端 ID:
client_id=CLIENT_ID
(服務器 API 識別應用程序【知道用戶是誰】) - 重定向 URL:
redirect_uri=CALLBACK_URL
(服務在被用戶授權后重定向 URL user-agent【API server 授權之后知道給誰發消息】) - 相應類型:
response_type=code
(指定應用程序正在請求授權碼) - 權限范圍:
scope=read
(指定應用程序訪問級別為只讀)
Casdoor 示例:
endpoint/login/oauth/authorize?client_id=xxx&response_type=code&redirect_uri=xxx&scope=read&state=xxx
client_id
:用戶 ID,可以在多個應用程序 APP 中。redirect_uri
:應用程序 APP 回調的 URL,通過這個信息,Casdoor 可以知道在授權后向哪里發送信息。state
:應用程序的名稱。
2、用戶授權申請
當用戶單擊該鏈接時,他們必須首先登錄該服務以驗證他們的身份(除非他們已經登錄)。然后服務會提示他們授權或拒絕應用程序訪問他們的帳戶。
3、應用程序接收授權碼
如果用戶單擊授權應用程序,該服務會將用戶代理重定向到在客戶端注冊期間指定的應用程序重定向 URI 以及授權代碼。重定向看起來像這樣(假設應用程序是 dropletbook.com):
https://dropletbook.com/callback?code=AUTHORIZATION_CODE
4、應用程序請求訪問令牌
應用程序通過將授權代碼連同身份驗證詳細信息(包括 client secret)傳遞到 API 令牌端點,從 API 請求訪問令牌。
示例請求:
https://cloud.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
5、應用程序接收訪問令牌
如果授權有效,API 將向應用程序發送包含訪問令牌(以及可選的刷新令牌)的響應。整個響應看起來像這樣:
{"access_token": "ACCESS_TOKEN","token_type": "bearer","expires_in": 2592000,"refresh_token": "REFRESH_TOKEN", // 用于請求新的令牌"scope": "read","uid": 100101,"info": {"name": "Mark E. Mark","email": "mark@thefunkybunch.com"}
}
現在該應用程序已獲得授權。它可以使用令牌通過服務 API 訪問用戶的帳戶,僅限于訪問范圍,直到令牌過期或被撤銷。如果發布了刷新令牌,如果原始令牌已過期,則可以使用它來請求新的訪問令牌。
五、Casdoor 運行原理
1、應用向用戶請求授權
endpoint/login/oauth/authorize?client_id=xxx&response_type=code&redirect_uri=xxx&scope=read&state=xxx
client_id
:用戶 ID,可以在多個應用程序 APP 中。redirect_uri
:應用程序 APP 回調的 URL,通過這個信息,Casdoor 可以知道在授權后向哪里發送信息。state
:應用程序的名稱。
應用程序對用戶說:
“嘿,現在我需要一些資源,我需要您的許可才能拿這些資源。您愿意跳轉到這個 URL,填寫您的用戶名和密碼嗎?”
使用正確的 URL,您的應用程序將會讓用戶向此 URL 發起請求,授權請求已完成。
2、用戶給應用授權
此步驟比較直接:用戶會被重定向到上面的 URL,看到來自 Casdoor 的登錄頁面。通過在登錄頁面輸入正確的用戶名和認證信息,Casdoor 現在能成功識別用戶,將發送 code 和 state 返回第 1 步中設置的回調 URL。
“用戶打開網址并向 Casdoor 提供憑據。Casdoor 說:‘好~ 這是我在數據庫中知道的用戶(授權應用獲取 code 和 state)。然后我將使用回調 URL 發送 code 和 state 返回應用(redirect_uri)。’”
3、API server 驗證 APP 的授權認證
在這一步,您的應用程序已經有了來自第 2 步的代碼,它將會告訴 Casdoor:
“嘿,現在用戶同意給我 code,你想檢查這個 code 并給我 access_token 嗎?”
4、API server 給 APP 頒發令牌
在這一步,Casdoor 會通知應用程序:
“這個 code 應該是合法的,你一定就是那個正確的應用程序。這是 access_token。”
5、APP 用令牌給資源服務器驗證
在這個步驟中,您的應用程序說:
“很好,剛剛獲得了最新的 access_token,我現在可以使用它從資源服務器獲得更多寶貴的東西!”
您的應用程序轉向資源服務器:
“嗨朋友,想檢查這個 access_token 嗎?我從 Casdoor 得到了訪問令牌,你想看看這是否與 Casdoor 的一致嗎?”
6、APP 使用令牌訪問資源服務器資源
資源服務器又告知您的應用程序:
“不錯~ 它似乎就像我在 Casdoor 中的那個一樣。Casdoor 說誰擁有這個 access_token 誰就可以擁有這些受保護的資源。現在,你可以自取這些資源了!”
這就是 Casdoor 如何與您的應用程序一起工作。
回調網址
SSO 登錄成功之后會傳信息的網址,會傳遞 code 和應用名稱。
拿到 code 向 SSO 的 API 請求獲得 access_token【后面就用 access_token 放到用戶的 cookie 中使用】。
代碼
后端代碼
前端代碼
by 久違