RFC 6749
OAuth 2.0 的標準是 RFC 6749 文件。該文件先解釋了 OAuth 是什麼。
OAuth 引入了一個授權層,用來分離兩種不同的角色:客戶端和資源所有者。......資源所有者同意以後,資源服務器可以向客戶端頒發令牌。客戶端通過令牌,去請求數據。
這段話的意思就是,OAuth 的核心就是向第三方應用頒發令牌。然後,RFC 6749 接着寫道:
(由於互聯網有多種場景,)本標準定義了獲得令牌的四種授權方式(authorization grant )。
也就是說,OAuth 2.0 規定了四種獲得令牌的流程。你可以選擇最適合自己的那一種,向第三方應用頒發令牌。下面就是這四種授權方式。
- 授權碼(authorization-code)
- 隱藏式(implicit)
- 密碼式(password):
- 客戶端憑證(client credentials)
注意,不管哪一種授權方式,第三方應用申請令牌之前,都必須先到系統備案,說明自己的身份,然後會拿到兩個身份識別碼:客戶端 ID(client ID)和客戶端密鑰(client secret)。這是爲了防止令牌被濫用,沒有備案過的第三方應用,是不會拿到令牌的。
第一種授權方式:授權碼
授權碼(authorization code)方式,指的是第三方應用先申請一個授權碼,然後再用該碼獲取令牌。
這種方式是最常用的流程,安全性也最高,它適用於那些有後端的 Web 應用。授權碼通過前端傳送,令牌則是儲存在後端,而且所有與資源服務器的通信都在後端完成。這樣的前後端分離,可以避免令牌泄漏。
第一步,A 網站提供一個鏈接,用戶點擊後就會跳轉到 B 網站,授權用戶數據給 A 網站使用。下面就是 A 網站跳轉 B 網站的一個示意鏈接。
https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中,response_type
參數表示要求返回授權碼(code
),client_id
參數讓 B 知道是誰在請求,redirect_uri
參數是 B 接受或拒絕請求後的跳轉網址,scope
參數表示要求的授權範圍(這裏是只讀)。
第二步,用戶跳轉後,B 網站會要求用戶登錄,然後詢問是否同意給予 A 網站授權。用戶表示同意,這時 B 網站就會跳回redirect_uri
參數指定的網址。跳轉時,會傳回一個授權碼,就像下面這樣。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中,code
參數就是授權碼。
第三步,A 網站拿到授權碼以後,就可以在後端,向 B 網站請求令牌。
https://b.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL
上面 URL 中,client_id
參數和client_secret
參數用來讓 B 確認 A 的身份(client_secret
參數是保密的,因此只能在後端發請求),grant_type
參數的值是AUTHORIZATION_CODE
,表示採用的授權方式是授權碼,code
參數是上一步拿到的授權碼,redirect_uri
參數是令牌頒發後的回調網址。
第四步,B 網站收到請求以後,就會頒發令牌。具體做法是向redirect_uri
指定的網址,發送一段 JSON 數據。
{ "access_token":"ACCESS_TOKEN", "token_type":"bearer", "expires_in":2592000, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":100101, "info":{...} }
上面 JSON 數據中,access_token
字段就是令牌,A 網站在後端拿到了。
第二種方式:隱藏式
有些 Web 應用是純前端應用,沒有後端。這時就不能用上面的方式了,必須將令牌儲存在前端。RFC 6749 就規定了第二種方式,允許直接向前端頒發令牌。這種方式沒有授權碼這個中間步驟,所以稱爲(授權碼)"隱藏式"(implicit)。
第一步,A 網站提供一個鏈接,要求用戶跳轉到 B 網站,授權用戶數據給 A 網站使用。
https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中,response_type
參數爲token
,表示要求直接返回令牌。
第二步,用戶跳轉到 B 網站,登錄後同意給予 A 網站授權。這時,B 網站就會跳回redirect_uri
參數指定的跳轉網址,並且把令牌作爲 URL 參數,傳給 A 網站。
https://a.com/callback#token=ACCESS_TOKEN
上面 URL 中,token
參數就是令牌,A 網站因此直接在前端拿到令牌。
注意,令牌的位置是 URL 錨點(fragment),而不是查詢字符串(querystring),這是因爲 OAuth 2.0 允許跳轉網址是 HTTP 協議,因此存在"中間人攻擊"的風險,而瀏覽器跳轉時,錨點不會發到服務器,就減少了泄漏令牌的風險。
這種方式把令牌直接傳給前端,是很不安全的。因此,只能用於一些安全要求不高的場景,並且令牌的有效期必須非常短,通常就是會話期間(session)有效,瀏覽器關掉,令牌就失效了。
第三種方式:密碼式
如果你高度信任某個應用,RFC 6749 也允許用戶把用戶名和密碼,直接告訴該應用。該應用就使用你的密碼,申請令牌,這種方式稱爲"密碼式"(password)。
第一步,A 網站要求用戶提供 B 網站的用戶名和密碼。拿到以後,A 就直接向 B 請求令牌。
https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
上面 URL 中,grant_type
參數是授權方式,這裏的password
表示"密碼式",username
和password
是 B 的用戶名和密碼。
第二步,B 網站驗證身份通過後,直接給出令牌。注意,這時不需要跳轉,而是把令牌放在 JSON 數據裏面,作爲 HTTP 迴應,A 因此拿到令牌。
這種方式需要用戶給出自己的用戶名/密碼,顯然風險很大,因此只適用於其他授權方式都無法採用的情況,而且必須是用戶高度信任的應用。
第四種方式:憑證式
最後一種方式是憑證式(client credentials),適用於沒有前端的命令行應用,即在命令行下請求令牌。
第一步,A 應用在命令行向 B 發出請求。
https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
上面 URL 中,grant_type
參數等於client_credentials
表示採用憑證式,client_id
和client_secret
用來讓 B 確認 A 的身份。
第二步,B 網站驗證通過以後,直接返回令牌。
這種方式給出的令牌,是針對第三方應用的,而不是針對用戶的,即有可能多個用戶共享同一個令牌。
令牌的使用
A 網站拿到令牌以後,就可以向 B 網站的 API 請求數據了。
此時,每個發到 API 的請求,都必須帶有令牌。具體做法是在請求的頭信息,加上一個Authorization
字段,令牌就放在這個字段裏面。
curl -H "Authorization: Bearer ACCESS_TOKEN" \ "https://api.b.com"
上面命令中,ACCESS_TOKEN
就是拿到的令牌。
更新令牌
令牌的有效期到了,如果讓用戶重新走一遍上面的流程,再申請一個新的令牌,很可能體驗不好,而且也沒有必要。OAuth 2.0 允許用戶自動更新令牌。
具體方法是,B 網站頒發令牌的時候,一次性頒發兩個令牌,一個用於獲取數據,另一個用於獲取新的令牌(refresh token 字段)。令牌到期前,用戶使用 refresh token 發一個請求,去更新令牌。
https://b.com/oauth/token? grant_type=refresh_token& client_id=CLIENT_ID& client_secret=CLIENT_SECRET& refresh_token=REFRESH_TOKEN
上面 URL 中,grant_type
參數爲refresh_token
表示要求更新令牌,client_id
參數和client_secret
參數用於確認身份,refresh_token
參數就是用於更新令牌的令牌。
B 網站驗證通過以後,就會頒發新的令牌。