OAuth2.0

Introduction

OAuth(Open Auth,開(kāi)放授權(quán) ) 就是一種授權(quán)機(jī)制。數(shù)據(jù)的所有者告訴系統(tǒng),同意授權(quán)第三方應(yīng)用進(jìn)入系統(tǒng),獲取這些數(shù)據(jù)。系統(tǒng)從而產(chǎn)生一個(gè)短期的進(jìn)入令牌(token),用來(lái)代替密碼,供第三方應(yīng)用使用。

OAuth 2.0 的標(biāo)準(zhǔn)是 RFC 6749 文件。該文件先解釋了 OAuth 是什么。

OAuth 引入了一個(gè)授權(quán)層,用來(lái)分離兩種不同的角色:客戶端和資源所有者。......資源所有者同意以后,資源服務(wù)器可以向客戶端頒發(fā)令牌。客戶端通過(guò)令牌,去請(qǐng)求數(shù)據(jù)。

也就是說(shuō),OAuth 2.0 規(guī)定了四種獲得令牌的流程。你可以選擇最適合自己的那一種,向第三方應(yīng)用頒發(fā)令牌。下面就是這四種授權(quán)方式。

  • 授權(quán)碼(authorization-code)
  • 隱藏式(implicit)
  • 密碼式(password)
  • 客戶端憑證(client credentials)

注意,不管哪一種授權(quán)方式,第三方應(yīng)用申請(qǐng)令牌之前,都必須先到系統(tǒng)備案,說(shuō)明自己的身份,然后會(huì)拿到兩個(gè)身份識(shí)別碼:客戶端 ID(client ID)和客戶端密鑰(client secret)。這是為了防止令牌被濫用,沒(méi)有備案過(guò)的第三方應(yīng)用,是不會(huì)拿到令牌的。

第一種授權(quán)方式:授權(quán)碼

授權(quán)碼(authorization code)方式,指的是第三方應(yīng)用先申請(qǐng)一個(gè)授權(quán)碼,然后再用該碼獲取令牌。

這種方式是最常用的流程,安全性也最高,它適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過(guò)前端傳送,令牌則是儲(chǔ)存在后端,而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離,可以避免令牌泄漏。

第一步,A 網(wǎng)站提供一個(gè)鏈接,用戶點(diǎn)擊后就會(huì)跳轉(zhuǎn)到 B 網(wǎng)站,授權(quán)用戶數(shù)據(jù)給 A 網(wǎng)站使用。下面就是 A 網(wǎng)站跳轉(zhuǎn) B 網(wǎng)站的一個(gè)示意鏈接。

https://b.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

上面 URL 中,response_type參數(shù)表示要求返回授權(quán)碼(code),client_id參數(shù)讓 B 知道是誰(shuí)在請(qǐng)求,redirect_uri參數(shù)是 B 接受或拒絕請(qǐng)求后的跳轉(zhuǎn)網(wǎng)址,scope參數(shù)表示要求的授權(quán)范圍(這里是只讀)。

  • response_type:必須的。值必須是"code"。
  • client_id:必須的。客戶端標(biāo)識(shí)符。
  • redirect_uri:可選的。
  • scope:可選的。請(qǐng)求訪問(wèn)的范圍。
  • state:推薦的。一個(gè)不透明的值用于維護(hù)請(qǐng)求和回調(diào)之間的狀態(tài)。授權(quán)服務(wù)器在將用戶代理重定向會(huì)客戶端的時(shí)候會(huì)帶上該參數(shù)。該參數(shù)可用于防止csrf攻擊(跨站請(qǐng)求偽造攻擊),建議第三方帶上該參數(shù),可設(shè)置為簡(jiǎn)單的隨機(jī)數(shù)加session進(jìn)行校驗(yàn)

第二步,用戶跳轉(zhuǎn)后,B 網(wǎng)站會(huì)要求用戶登錄,然后詢問(wèn)是否同意給予 A 網(wǎng)站授權(quán)。用戶表示同意,這時(shí) B 網(wǎng)站就會(huì)跳回redirect_uri參數(shù)指定的網(wǎng)址。跳轉(zhuǎn)時(shí),會(huì)傳回一個(gè)授權(quán)碼,就像下面這樣。

https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中,code參數(shù)就是授權(quán)碼。

第三步,A 網(wǎng)站拿到授權(quán)碼以后,就可以在后端,向 B 網(wǎng)站請(qǐng)求令牌。

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參數(shù)和client_secret參數(shù)用來(lái)讓 B 確認(rèn) A 的身份(client_secret參數(shù)是保密的,因此只能在后端發(fā)請(qǐng)求),grant_type參數(shù)的值是AUTHORIZATION_CODE,表示采用的授權(quán)方式是授權(quán)碼,code參數(shù)是上一步拿到的授權(quán)碼,redirect_uri參數(shù)是令牌頒發(fā)后的回調(diào)網(wǎng)址。

第四步,B 網(wǎng)站收到請(qǐng)求以后,就會(huì)頒發(fā)令牌。具體做法是向redirect_uri指定的網(wǎng)址,發(fā)送一段 JSON 數(shù)據(jù)。

{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}

上面 JSON 數(shù)據(jù)中,access_token字段就是令牌,A 網(wǎng)站在后端拿到了。

第二種方式:隱藏式

有些 Web 應(yīng)用是純前端應(yīng)用,沒(méi)有后端。這時(shí)就不能用上面的方式了,必須將令牌儲(chǔ)存在前端。RFC 6749 就規(guī)定了第二種方式,允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個(gè)中間步驟,所以稱為(授權(quán)碼)"隱藏式"(implicit)。

第一步,A 網(wǎng)站提供一個(gè)鏈接,要求用戶跳轉(zhuǎn)到 B 網(wǎng)站,授權(quán)用戶數(shù)據(jù)給 A 網(wǎng)站使用。

https://b.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

上面 URL 中,response_type參數(shù)為token,表示要求直接返回令牌。

第二步,用戶跳轉(zhuǎn)到 B 網(wǎng)站,登錄后同意給予 A 網(wǎng)站授權(quán)。這時(shí),B 網(wǎng)站就會(huì)跳回redirect_uri參數(shù)指定的跳轉(zhuǎn)網(wǎng)址,并且把令牌作為 URL 參數(shù),傳給 A 網(wǎng)站。

https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中,token參數(shù)就是令牌,A 網(wǎng)站因此直接在前端拿到令牌。

注意,令牌的位置是 URL 錨點(diǎn)(fragment),而不是查詢字符串(querystring),這是因?yàn)?OAuth 2.0 允許跳轉(zhuǎn)網(wǎng)址是 HTTP 協(xié)議,因此存在"中間人攻擊"的風(fēng)險(xiǎn),而瀏覽器跳轉(zhuǎn)時(shí),錨點(diǎn)不會(huì)發(fā)到服務(wù)器,就減少了泄漏令牌的風(fēng)險(xiǎn)。

這種方式把令牌直接傳給前端,是很不安全的。因此,只能用于一些安全要求不高的場(chǎng)景,并且令牌的有效期必須非常短,通常就是會(huì)話期間(session)有效,瀏覽器關(guān)掉,令牌就失效了。

第三種方式:密碼式

如果你高度信任某個(gè)應(yīng)用,RFC 6749 也允許用戶把用戶名和密碼,直接告訴該應(yīng)用。該應(yīng)用就使用你的密碼,申請(qǐng)令牌,這種方式稱為"密碼式"(password)。

第一步,A 網(wǎng)站要求用戶提供 B 網(wǎng)站的用戶名和密碼。拿到以后,A 就直接向 B 請(qǐng)求令牌。

https://oauth.b.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

上面 URL 中,grant_type參數(shù)是授權(quán)方式,這里的password表示"密碼式",username和password是 B 的用戶名和密碼。

第二步,B 網(wǎng)站驗(yàn)證身份通過(guò)后,直接給出令牌。注意,這時(shí)不需要跳轉(zhuǎn),而是把令牌放在 JSON 數(shù)據(jù)里面,作為 HTTP 回應(yīng),A 因此拿到令牌。

這種方式需要用戶給出自己的用戶名/密碼,顯然風(fēng)險(xiǎn)很大,因此只適用于其他授權(quán)方式都無(wú)法采用的情況,而且必須是用戶高度信任的應(yīng)用。

第四種方式:憑證式

最后一種方式是憑證式(client credentials),適用于沒(méi)有前端的命令行應(yīng)用,即在命令行下請(qǐng)求令牌。

第一步,A 應(yīng)用在命令行向 B 發(fā)出請(qǐng)求。

https://oauth.b.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

上面 URL 中,grant_type參數(shù)等于client_credentials表示采用憑證式,client_idclient_secret用來(lái)讓 B 確認(rèn) A 的身份。

第二步,B 網(wǎng)站驗(yàn)證通過(guò)以后,直接返回令牌。

這種方式給出的令牌,是針對(duì)第三方應(yīng)用的,而不是針對(duì)用戶的,即有可能多個(gè)用戶共享同一個(gè)令牌。

令牌的使用

A 網(wǎng)站拿到令牌以后,就可以向 B 網(wǎng)站的 API 請(qǐng)求數(shù)據(jù)了。

此時(shí),每個(gè)發(fā)到 API 的請(qǐng)求,都必須帶有令牌。具體做法是在請(qǐng)求的頭信息,加上一個(gè)Authorization字段,令牌就放在這個(gè)字段里面。

curl -H "Authorization: Bearer ACCESS_TOKEN" "https://api.b.com"

上面命令中,ACCESS_TOKEN就是拿到的令牌。

更新令牌

令牌的有效期到了,如果讓用戶重新走一遍上面的流程,再申請(qǐng)一個(gè)新的令牌,很可能體驗(yàn)不好,而且也沒(méi)有必要。OAuth 2.0 允許用戶自動(dòng)更新令牌。

具體方法是,B 網(wǎng)站頒發(fā)令牌的時(shí)候,一次性頒發(fā)兩個(gè)令牌,一個(gè)用于獲取數(shù)據(jù),另一個(gè)用于獲取新的令牌(refresh token 字段)。令牌到期前,用戶使用 refresh token 發(fā)一個(gè)請(qǐng)求,去更新令牌。

https://b.com/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

上面 URL 中,grant_type參數(shù)為refresh_token表示要求更新令牌,client_id參數(shù)和client_secret參數(shù)用于確認(rèn)身份,refresh_token參數(shù)就是用于更新令牌的令牌。

B 網(wǎng)站驗(yàn)證通過(guò)以后,就會(huì)頒發(fā)新的令牌。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,936評(píng)論 6 535
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,744評(píng)論 3 421
  • 文/潘曉璐 我一進(jìn)店門(mén),熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人,你說(shuō)我怎么就攤上這事。” “怎么了?”我有些...
    開(kāi)封第一講書(shū)人閱讀 176,879評(píng)論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我,道長(zhǎng),這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 63,181評(píng)論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,935評(píng)論 6 410
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 55,325評(píng)論 1 324
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,384評(píng)論 3 443
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起,我...
    開(kāi)封第一講書(shū)人閱讀 42,534評(píng)論 0 289
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,084評(píng)論 1 335
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,892評(píng)論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,067評(píng)論 1 371
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,623評(píng)論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,322評(píng)論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 34,735評(píng)論 0 27
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 35,990評(píng)論 1 289
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,800評(píng)論 3 395
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,084評(píng)論 2 375

推薦閱讀更多精彩內(nèi)容

  • 本文以一種簡(jiǎn)化的格式描述OAuth 2.0 ,以幫助開(kāi)發(fā)人員和服務(wù)提供者實(shí)現(xiàn)該協(xié)議。 The OAuth 2 sp...
    JacoChan閱讀 4,194評(píng)論 1 11
  • OAuth2.0 是關(guān)于授權(quán)的開(kāi)放網(wǎng)絡(luò)標(biāo)準(zhǔn),它允許用戶已第三方應(yīng)用獲取該用戶在某一網(wǎng)站的私密資源,而無(wú)需提供用戶名...
    baiyi閱讀 10,280評(píng)論 4 25
  • Spring OAuth2.0 提供者實(shí)現(xiàn)原理: Spring OAuth2.0提供者實(shí)際上分為: 授權(quán)服務(wù) Au...
    EnchIGo閱讀 1,238評(píng)論 0 5
  • OAuth2.0協(xié)議 定義 OAuth: OAuth(開(kāi)放授權(quán))是一個(gè)開(kāi)放標(biāo)準(zhǔn),允許用戶授權(quán)第三方移動(dòng)應(yīng)用訪問(wèn)他們...
    HoooChan閱讀 5,408評(píng)論 1 3
  • 什么是三方授權(quán)? 第三方授權(quán)就是,委托第三方來(lái)對(duì)既定的用戶進(jìn)行鑒定,鑒定成功之后,下發(fā)信任憑證,信任憑證和用戶掛鉤...
    一只小哈閱讀 32,651評(píng)論 2 21