作者:阮一峰
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
OAuth是一個關于授權(authorization)的開放網路標準,在全世界得到廣泛應用,目前的版本是2.0版,
本文對OAuth 2.0的設計思路和運行流程,做一個簡明通俗的解釋,主要參考材料為RFC 6749,


一、應用場景
為了理解OAuth的適用場合,讓我舉一個假設的例子,
有一個"云沖印"的網站,可以將用戶儲存在Google的照片,沖印出來,用戶為了使用該服務,必須讓"云沖印"讀取自己儲存在Google上的照片,

問題是只有得到用戶的授權,Google才會同意"云沖印"讀取這些照片,那么,"云沖印"怎樣獲得用戶的授權呢?
傳統方法是,用戶將自己的Google用戶名和密碼,告訴"云沖印",后者就可以讀取用戶的照片了,這樣的做法有以下幾個嚴重的缺點,
(1)"云沖印"為了后續的服務,會保存用戶的密碼,這樣很不安全,
(2)Google不得不部署密碼登錄,而我們知道,單純的密碼登錄并不安全,
(3)"云沖印"擁有了獲取用戶儲存在Google所有資料的權力,用戶沒法限制"云沖印"獲得授權的范圍和有效期,
(4)用戶只有修改密碼,才能識訓賦予"云沖印"的權力,但是這樣做,會使得其他所有獲得用戶授權的第三方應用程式全部失效,
(5)只要有一個第三方應用程式被破解,就會導致用戶密碼泄漏,以及所有被密碼保護的資料泄漏,
OAuth就是為了解決上面這些問題而誕生的,

二、名詞定義
在詳細講解OAuth 2.0之前,需要了解幾個專用名詞,它們對讀懂后面的講解,尤其是幾張圖,至關重要,
(1) Third-party application:第三方應用程式,本文中又稱"客戶端"(client),即上一節例子中的"云沖印",
(2)HTTP service:HTTP服務提供商,本文中簡稱"服務提供商",即上一節例子中的Google,
(3)Resource Owner:資源所有者,本文中又稱"用戶"(user),
(4)User Agent:用戶代理,本文中就是指瀏覽器,
(5)Authorization server:認證服務器,即服務提供商專門用來處理認證的服務器,
(6)Resource server:資源服務器,即服務提供商存放用戶生成的資源的服務器,它與認證服務器,可以是同一臺服務器,也可以是不同的服務器,
知道了上面這些名詞,就不難理解,OAuth的作用就是讓"客戶端"安全可控地獲取"用戶"的授權,與"服務商提供商"進行互動,

三、OAuth的思路
OAuth在"客戶端"與"服務提供商"之間,設定了一個授權層(authorization layer),"客戶端"不能直接登錄"服務提供商",只能登錄授權層,以此將用戶與客戶端區分開來,"客戶端"登錄授權層所用的令牌(token),與用戶的密碼不同,用戶可以在登錄的時候,指定授權層令牌的權限范圍和有效期,
"客戶端"登錄授權層以后,"服務提供商"根據令牌的權限范圍和有效期,向"客戶端"開放用戶儲存的資料,

四、運行流程
OAuth 2.0的運行流程如下圖,摘自RFC 6749,

(A)用戶打開客戶端以后,客戶端要求用戶給予授權,
(B)用戶同意給予客戶端授權,
(C)客戶端使用上一步獲得的授權,向認證服務器申請令牌,
(D)認證服務器對客戶端進行認證以后,確認無誤,同意發放令牌,
(E)客戶端使用令牌,向資源服務器申請獲取資源,
(F)資源服務器確認令牌無誤,同意向客戶端開放資源,
不難看出來,上面六個步驟之中,B是關鍵,即用戶怎樣才能給于客戶端授權,有了這個授權以后,客戶端就可以獲取令牌,進而憑令牌獲取資源,
下面一一講解客戶端獲取授權的四種模式,

五、客戶端的授權模式
客戶端必須得到用戶的授權(authorization grant),才能獲得令牌(access token),OAuth 2.0定義了四種授權方式,
授權碼模式(authorization code)
簡化模式(implicit)
密碼模式(resource owner password credentials)
客戶端模式(client credentials)

六、授權碼模式
授權碼模式(authorization code)是功能最完整、流程最嚴密的授權模式,它的特點就是通過客戶端的后臺服務器,與"服務提供商"的認證服務器進行互動,

(A)用戶訪問客戶端,后者將前者導向認證服務器,
(B)用戶選擇是否給予客戶端授權,
(C)假設用戶給予授權,認證服務器將用戶導向客戶端事先指定的"重定向URI"(redirection URI),同時附上一個授權碼,
(D)客戶端收到授權碼,附上早先的"重定向URI",向認證服務器申請令牌,這一步是在客戶端的后臺的服務器上完成的,對用戶不可見,
(E)認證服務器核對了授權碼和重定向URI,確認無誤后,向客戶端發送訪問令牌(access token)和更新令牌(refresh token),
下面是上面這些步驟所需要的引數,
A步驟中,客戶端申請認證的URI,包含以下引數:
response_type:表示授權型別,必選項,此處的值固定為"code"
client_id:表示客戶端的ID,必選項
redirect_uri:表示重定向URI,可選項
scope:表示申請的權限范圍,可選項
state:表示客戶端的當前狀態,可以指定任意值,認證服務器會原封不動地回傳這個值,
下面是一個例子
GET /authorize?response\_type=code&client\_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.example.com
C步驟中,服務器回應客戶端的URI,包含以下引數:
code:表示授權碼,必選項,該碼的有效期應該很短,通常設為10分鐘,客戶端只能使用該碼一次,否則會被授權服務器拒絕,該碼與客戶端ID和重定向URI,是一一對應關系,
state:如果客戶端的請求中包含這個引數,認證服務器的回應也必須一模一樣包含這個引數,
下面是個例子
HTTP/1.1 302 FoundLocation: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
D步驟中,客戶端向認證服務器申請令牌的HTTP請求,包含以下引數:
grant_type:表示使用的授權模式,必選項,此處的值固定為"authorization_code",
code:表示上一步獲得的授權碼,必選項,
redirect_uri:表示重定向URI,必選項,且必須與A步驟中的該引數值保持一致,
client_id:表示客戶端ID,必選項,
下面是個例子
POST /token HTTP/1.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
E步驟中,認證服務器發送的HTTP回復,包含以下引數:
access_token:表示訪問令牌,必選項,
token_type:表示令牌型別,該值大小寫不敏感,必選項,可以是bearer型別或mac型別,
expires_in:表示過期時間,單位為秒,如果省略該引數,必須其他方式設定過期時間,
refresh_token:表示更新令牌,用來獲取下一次的訪問令牌,可選項,
scope:表示權限范圍,如果與客戶端申請的范圍一致,此項可省略,
下面是個列子
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
從上面代碼可以看到,相關引數使用JSON格式發送(Content-Type: application/json),此外,HTTP頭資訊中明確指定不得快取,

七、簡化模式
簡化模式(implicit grant type)不通過第三方應用程式的服務器,直接在瀏覽器中向認證服務器申請令牌,跳過了"授權碼"這個步驟,因此得名,所有步驟在瀏覽器中完成,令牌對訪問者是可見的,且客戶端不需要認證,

它的步驟如下
(A)客戶端將用戶導向認證服務器,
(B)用戶決定是否給于客戶端授權,
(C)假設用戶給予授權,認證服務器將用戶導向客戶端指定的"重定向URI",并在URI的Hash部分包含了訪問令牌,
(D)瀏覽器向資源服務器發出請求,其中不包括上一步收到的Hash值,
(E)資源服務器回傳一個網頁,其中包含的代碼可以獲取Hash值中的令牌,
(F)瀏覽器執行上一步獲得的腳本,提取出令牌,
(G)瀏覽器將令牌發給客戶端,

下面是上面這些步驟所需要的引數,
A步驟中,客戶端發出的HTTP請求,包含以下引數:
response_type:表示授權型別,此處的值固定為"token",必選項,
client_id:表示客戶端的ID,必選項,
redirect_uri:表示重定向的URI,可選項,
scope:表示權限范圍,可選項,
state:表示客戶端的當前狀態,可以指定任意值,認證服務器會原封不動地回傳這個值,
下面是個列子:
GET /authorize?response\_type=token&client\_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
C步驟中,認證服務器回應客戶端的URI,包含以下引數:
access_token:表示訪問令牌,必選項,
token_type:表示令牌型別,該值大小寫不敏感,必選項,
expires_in:表示過期時間,單位為秒,如果省略該引數,必須其他方式設定過期時間,
scope:表示權限范圍,如果與客戶端申請的范圍一致,此項可省略,
state:如果客戶端的請求中包含這個引數,認證服務器的回應也必須一模一樣包含這個引數,
下面是個例子:
HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
在上面的例子中,認證服務器用HTTP頭資訊的Location欄,指定瀏覽器重定向的網址,注意,在這個網址的Hash部分包含了令牌,
根據上面的D步驟,下一步瀏覽器會訪問Location指定的網址,但是Hash部分不會發送,接下來的E步驟,服務提供商的資源服務器發送過來的代碼,會提取出Hash中的令牌,

八、密碼模式
密碼模式(Resource Owner Password Credentials Grant)中,用戶向客戶端提供自己的用戶名和密碼,客戶端使用這些資訊,向"服務商提供商"索要授權,
在這種模式中,用戶必須把自己的密碼給客戶端,但是客戶端不得儲存密碼,這通常用在用戶對客戶端高度信任的情況下,比如客戶端是作業系統的一部分,或者由一個著名公司出品,而認證服務器只有在其他授權模式無法執行的情況下,才能考慮使用這種模式,

它的步驟如下:
(A)用戶向客戶端提供用戶名和密碼,
(B)客戶端將用戶名和密碼發給認證服務器,向后者請求令牌,
(C)認證服務器確認無誤后,向客戶端提供訪問令牌,
B步驟中,客戶端發出的HTTP請求,包含以下引數:
grant_type:表示授權型別,此處的值固定為"password",必選項,
username:表示用戶名,必選項,
password:表示用戶的密碼,必選項,
scope:表示權限范圍,可選項,
下面是一個列子:
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w
C步驟中,認證服務器向客戶端發送訪問令牌,下面是一個例子:
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
上面代碼中,各個引數的含義參見《授權碼模式》一節,
整個程序中,客戶端不得保存用戶的密碼,

九、客戶端模式
客戶端模式(Client Credentials Grant)指客戶端以自己的名義,而不是以用戶的名義,向"服務提供商"進行認證,嚴格地說,客戶端模式并不屬于OAuth框架所要解決的問題,在這種模式中,用戶直接向客戶端注冊,客戶端以自己的名義要求"服務提供商"提供服務,其實不存在授權問題,

它的步驟如下:
(A)客戶端向認證服務器進行身份認證,并要求一個訪問令牌,
(B)認證服務器確認無誤后,向客戶端提供訪問令牌,
A步驟中,客戶端發出的HTTP請求,包含以下引數:
granttype:表示授權型別,此處的值固定為"clientcredentials",必選項,
scope:表示權限范圍,可選項,
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant\_type=client\_credentials
認證服務器必須以某種方式,驗證客戶端身份,
B步驟中,認證服務器向客戶端發送訪問令牌,下面是一個例子,
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" }
上面代碼中,各個引數的含義參見《授權碼模式》一節,

十、更新令牌
如果用戶訪問的時候,客戶端的"訪問令牌"已經過期,則需要使用"更新令牌"申請一個新的訪問令牌,
客戶端發出更新令牌的HTTP請求,包含以下引數:
granttype:表示使用的授權模式,此處的值固定為"refreshtoken",必選項,
refresh_token:表示早前收到的更新令牌,必選項,
scope:表示申請的授權范圍,不可以超出上一次申請的范圍,如果省略該引數,則表示與上一次一致,
下面是一個例子:
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant\_type=refresh\_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
推薦去我的博客閱讀更多:
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯,別忘了點贊+轉發哦!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/162007.html
標籤:Java
下一篇:Js--DOM詳解
