背景

為什么需要OAuth授權(quán)呢?

最典型的應(yīng)用場景就是第三方登錄了, 我們開發(fā)了一個(gè)網(wǎng)站希望用戶可以QQ登錄, 但是怎么能拿到用戶的 QQ 信息呢? 用戶將 賬號密碼告訴我們當(dāng)然可以, 但是這樣有如下隱患:

• 我們拿到了用戶的密碼, 這樣很不安全. 而且任意一個(gè)應(yīng)用被黑, 所有相關(guān)站點(diǎn)均受影響
• QQ 需要支持密碼登錄, 但是單純密碼登錄并不安全. 因此進(jìn)而影響 QQ 的安全問題
• 我們拿到密碼之后, 就相當(dāng)于擁有了用戶的所有信息, 這樣無法進(jìn)行權(quán)限限制
  • 可能只是希望授權(quán)用戶名和頭像, 但是連著好友列表一起交代出去了
• 用戶一旦修改密碼, 所有之前授權(quán)過的應(yīng)用全部失效

基于以上原因, 就需要有這樣一套機(jī)制:

• 不基于密碼的授權(quán)
• 授權(quán)存在時(shí)間限制, 并且隨時(shí)可以收回權(quán)限
• 收回單個(gè)應(yīng)用的權(quán)限, 不會對其他已授權(quán)的應(yīng)用造成任何影響
• 可以僅授予個(gè)別權(quán)限, 而不是所有

沒錯(cuò), OAuth就是為了解決這個(gè)問題而提出來的.

介紹

OAuth是什么呢? 在RFC 文檔中是這樣介紹的.

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections.

寫的比較官方哈, 簡單說, 就是授權(quán)他人以擁有臨時(shí)訪問資源的權(quán)限.

那么, OAuth1.0是如何實(shí)現(xiàn)這樣的機(jī)制呢?

實(shí)現(xiàn)

在介紹其實(shí)現(xiàn)之前, 需要先來了解OAuth中的幾個(gè)概念.

• 角色
  • Consumer 消費(fèi)者, 既需要訪問資源的應(yīng)用
  • ServiceProvider 服務(wù)提供者, 既提供資源的服務(wù)器
  • User 用戶

依舊使用我們上面的例子, 我們的博客網(wǎng)站需要接入 QQ 登錄. 在這里, 博客網(wǎng)站就是其中的Consumer, 而 QQ 服務(wù)器就是ServiceProvider了. 為了方便立即, 下面均稱為 博客網(wǎng)站 QQ服務(wù)器. 我們獲取授權(quán)的流程大致如下圖:

對其中的各個(gè)流程進(jìn)行介紹

流程

在請求之前, 博客網(wǎng)站需要到 QQ 服務(wù)器 進(jìn)行注冊, 并獲得如下標(biāo)識:

• consumer_key: 網(wǎng)站標(biāo)識符
• consumer_secret: 網(wǎng)站使用的私鑰

1. 獲取 request_token

網(wǎng)站向QQ 服務(wù)器申請一個(gè)臨時(shí)憑據(jù), 用來在本次授權(quán)過程中進(jìn)行校驗(yàn).

攜帶參數(shù)

• oauth_consumer_key
• oauth_signature_method: 簽名使用的生成方法
• oauth_signature: 本次請求的簽名, 使用consumer_secret生成
• oauth_timestamp 時(shí)間戳, 用于對本次請求進(jìn)行校驗(yàn)
• oauth_callback 回調(diào)鏈接, 用于在用戶授權(quán)之后回調(diào)通知消費(fèi)者
• oauth_nonce 隨機(jī)字符串
  • 此參數(shù)用來防止重放攻擊, 即別人拿到請求鏈接再次請求
  • 因此, 服務(wù)提供者會對其進(jìn)行驗(yàn)證是否處理過

返回?cái)?shù)據(jù)

• request_token: 此 token 僅用作后面授權(quán)中校驗(yàn)使用, 以及對本次授權(quán)進(jìn)行標(biāo)識
• request_secret: 用于本次授權(quán)的后續(xù)請求進(jìn)行加密, 使用在第5步

2. 重定向到服務(wù)器授權(quán)頁面

將頁面重定向到 QQ 服務(wù)器 的授權(quán)頁面.

攜帶參數(shù)

• request_token: 用來向 QQ 服務(wù)器標(biāo)識本次授權(quán)

3. 用戶在 QQ 服務(wù)器完成授權(quán)操作

用戶在 QQ 服務(wù)器的授權(quán)頁面進(jìn)行登錄并授權(quán)

4. 回調(diào)函數(shù)通知授權(quán)成功

用戶授權(quán)成功后, QQ 服務(wù)器將鏈接重定向到 第一步指定的 回調(diào)鏈接. 并在回調(diào)鏈接上附帶結(jié)果:

• request_token: 用來對本次授權(quán)進(jìn)行標(biāo)識. 畢竟博客網(wǎng)站收到回調(diào)時(shí), 需要知道是哪個(gè)用戶授權(quán)成功了.
• verifier: 在下一步獲取 access_token 中檢驗(yàn)使用. 具體作用在下一步說明.

5. 授權(quán)成功后獲取 access_token + access_secret

此時(shí)用戶已經(jīng)同意了權(quán)限的授予, 博客網(wǎng)站可以到 QQ 服務(wù)器獲取用戶的授權(quán)碼了.

返回?cái)?shù)據(jù)

• access_token
• access_token_secret

用戶后續(xù)就使用這兩個(gè)授權(quán)信息到 QQ 服務(wù)器請求資源.

access_token_secret作用

這里有個(gè)小疑問, 既然有了access_token, 又為什么需要access_token_secret呢?

因?yàn)樵L問數(shù)據(jù)使用HTTP協(xié)議, 對數(shù)據(jù)的傳輸過程沒有安全保障. 在后續(xù)訪問資源時(shí), 若僅使用consumer_secret對請求進(jìn)行簽名, 若consumer_secret泄露了, 那么攻擊者只要獲得用戶的access_token就擁有了其權(quán)限. 而access_token又需要在訪問是攜帶在參數(shù)中對權(quán)限進(jìn)行標(biāo)識. 故而十分危險(xiǎn).

在生成簽名時(shí), 額外加上access_token_secret進(jìn)行簽名, 而access_token_secret不會在后續(xù)訪問中傳遞, 每個(gè)用戶又都是不同的, 因此即使consumer_secret泄露了, 攻擊者也無法獲得所有用戶的權(quán)限.

攜帶參數(shù)

• consumer_key
• request_token
• signature_method
• timestamp
• nonce
• verifier
• signature

verifier作用

那么, 這里的oauth_verifier有必要么? 其實(shí)它是為了防止 session固話攻擊, 感興趣的可以搜索"OAuth Session Fixation Attack"查看具體內(nèi)容. 這里簡單介紹一下.

假設(shè), 有一個(gè)攻擊者監(jiān)控了你的網(wǎng)絡(luò)請求, 因?yàn)槭褂昧薍TTP協(xié)議, 明文信息也沒什么秘密. 那么攻擊者就可以在第一步時(shí)獲得本次授權(quán)的request_token. 同時(shí)攻擊者又通過暴力破解或其他方法, 獲得了consumer_secret.

此時(shí), 若沒有verifier參數(shù), 本次請求的所有參數(shù)攻擊者均可以構(gòu)造. 若攻擊者頻繁訪問本次請求, 又恰好在用戶授權(quán)完成和網(wǎng)站回調(diào)的間隙發(fā)起了合法訪問, 就會成功獲得用戶的access_token.

通過添加隨機(jī)的verifier可以使得本次請求不可預(yù)測.

問題

對于OAuth1.0實(shí)現(xiàn)的一些問題:

• 使用了HTTP協(xié)議, 安全性較低
• 使用HTTP協(xié)議, 沒有對服務(wù)提供者的真實(shí)性進(jìn)行校驗(yàn)
• 對非web應(yīng)用(如安卓)支持很不友好. (也有通過 PIN 碼實(shí)現(xiàn)的, 這里不展開介紹了)
• 簽名過程復(fù)雜. 需要同時(shí)使用consumer_secret+access_token_secret進(jìn)行簽名. (也是因?yàn)槭褂肏TTP協(xié)議)

這些問題在OAuth2.0得到了解決, 詳情查看下一篇文章: OAuth2.0介紹

總結(jié)

以上是生活随笔為你收集整理的OAuth1.0介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。