理解OAuth2.0認(rèn)證與客戶端授權(quán)碼模式詳解
一、什么是OAuth協(xié)議
OAuth 協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全又簡易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是 OAuth的授權(quán)不會使第三方觸及到用戶的帳號信息(如用戶名與密碼),即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權(quán),因此 OAuth是安全的。OAuth 是 Open Authorization 的簡寫
OAuth 本身不存在一個(gè)標(biāo)準(zhǔn)的實(shí)現(xiàn),后端開發(fā)者自己根據(jù)實(shí)際的需求和標(biāo)準(zhǔn)的規(guī)定實(shí)現(xiàn)。其步驟一般如下:
第三方要求用戶給予授權(quán)
用戶同意授權(quán)
根據(jù)上一步獲得的授權(quán),第三方向認(rèn)證服務(wù)器請求令牌(
token)認(rèn)證服務(wù)器對授權(quán)進(jìn)行認(rèn)證,確認(rèn)無誤后發(fā)放令牌
第三方使用令牌向資源服務(wù)器請求資源
資源服務(wù)器使用令牌向認(rèn)證服務(wù)器確認(rèn)令牌的正確性,確認(rèn)無誤后提供資源
二、OAuth2.0是為了解決什么問題?
任何身份認(rèn)證,本質(zhì)上都是基于對請求方的不信任所產(chǎn)生的。同時(shí),請求方是信任被請求方的,例如用戶請求服務(wù)時(shí),會信任服務(wù)方。所以,身份認(rèn)證就是為了解決身份的可信任問題。
在OAuth2.0中,簡單來說有三方:用戶(這里是指屬于服務(wù)方的用戶)、服務(wù)方(如微信、微博等)、第三方應(yīng)用
服務(wù)方不信任用戶,所以需要用戶提供密碼或其他可信憑據(jù)
服務(wù)方不信任第三方應(yīng)用,所以需要第三方提供自已交給它的憑據(jù)(如微信授權(quán)的
code,AppID等)用戶部分信任第三方應(yīng)用,所以用戶愿意把自已在服務(wù)方里的某些服務(wù)交給第三方使用,但不愿意把自已在服務(wù)方的密碼等交給第三方應(yīng)用
三、OAuth2.0成員和授權(quán)基本流程
3.1 OAuth2.0成員
Resource Owner(資源擁有者:用戶)
Client (第三方接入平臺:請求者)
Resource Server (服務(wù)器資源:數(shù)據(jù)中心)
Authorization Server (認(rèn)證服務(wù)器)
3.2 OAuth2.0基本流程

步驟詳解:
Authorization Request, 第三方請求用戶授權(quán)Authorization Grant,用戶同意授權(quán)后,會從服務(wù)方獲取一次性用戶授權(quán)憑據(jù)(如code碼)給第三方Authorization Grant,第三方會把授權(quán)憑據(jù)以及服務(wù)方給它的的身份憑據(jù)(如AppId)一起交給服務(wù)方的向認(rèn)證服務(wù)器申請訪問令牌Access Token,認(rèn)證服務(wù)器核對授權(quán)憑據(jù)等信息,確認(rèn)無誤后,向第三方發(fā)送訪問令牌Access Token等信息Access Token,通過這個(gè)Access Token向Resource Server索要數(shù)據(jù)Protected Resource,資源服務(wù)器使用令牌向認(rèn)證服務(wù)器確認(rèn)令牌的正確性,確認(rèn)無誤后提供資源
這樣服務(wù)方,一可以確定第三方得到了用戶對此次服務(wù)的授權(quán)(根據(jù)用戶授權(quán)憑據(jù)),二可以確定第三方的身份是可以信任的(根據(jù)身份憑據(jù)),所以,最終的結(jié)果就是,第三方順利地從服務(wù)方獲取到了此次所請求的服務(wù)
從上面的流程中可以看出,OAuth2.0完整地解決了用戶、服務(wù)方、第三方 在某次服務(wù)時(shí)這三者之間的信任問題
四、第三方客戶端授權(quán)碼模式詳解
4.1 授權(quán)碼模式
客戶端必須得到用戶的授權(quán)(authorization grant),才能獲得令牌(access token)。OAuth 2.0定義了四種授權(quán)方式:
授權(quán)碼模式(
authorization code)簡化模式(
implicit)密碼模式(
resource owner password credentials)客戶端模式(
client credentials)
授權(quán)碼模式(authorization code)是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過客戶端的后臺服務(wù)器與"服務(wù)提供商"的認(rèn)證服務(wù)器進(jìn)行互動。
4.2 授權(quán)碼流程圖及步驟

它的步驟如下:
用戶訪問客戶端,后者將前者導(dǎo)向認(rèn)證服務(wù)器
用戶選擇是否給予客戶端授權(quán)
假設(shè)用戶給予授權(quán),認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的重定向
URI,同時(shí)附上一個(gè)授權(quán)碼客戶端收到授權(quán)碼,附上早先的重定向
URI,向認(rèn)證服務(wù)器申請令牌。這一步是在客戶端的后臺的服務(wù)器上完成的,對用戶不可見認(rèn)證服務(wù)器核對了授權(quán)碼和重定向
URI,確認(rèn)無誤后,向客戶端發(fā)送訪問令牌(access token)和更新令牌(refresh token)等
4.3 步驟詳情及所需參數(shù)
4.3.1 步驟1: 客戶端申請認(rèn)證的URI
包含以下參數(shù):
response_type:表示授權(quán)類型,必選項(xiàng),此處的值固定為"code"
client_id:表示客戶端的ID,必選項(xiàng)。(
如微信授權(quán)登錄,此ID是APPID)redirect_uri:表示重定向URI,可選項(xiàng)
scope:表示申請的權(quán)限范圍,可選項(xiàng) state:表示客戶端的當(dāng)前狀態(tài),可以指定任意值,認(rèn)證服務(wù)器會原封不動地返回這個(gè)值
示例:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
HTTP/1.1 Host: server.example.com
對比網(wǎng)站應(yīng)用微信登錄:請求CODE
https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect4.3.2 步驟3:認(rèn)證服務(wù)器回應(yīng)客戶端的URI
包含以下參數(shù):
code:表示授權(quán)碼,必選項(xiàng)。該碼的有效期應(yīng)該很短,通常設(shè)為10分鐘,客戶端
只能使用該碼一次,否則會被授權(quán)服務(wù)器拒絕。該碼與客戶端ID和重定向URI,是一一對應(yīng)關(guān)系。state:如果客戶端的請求中包含這個(gè)參數(shù),認(rèn)證服務(wù)器的回應(yīng)也必須一模一樣包含這個(gè)參數(shù)。
示例:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz4.3.3 步驟4:客戶端向認(rèn)證服務(wù)器申請令牌的HTTP請求
包含以下參數(shù):
grant_type:表示使用的授權(quán)模式,必選項(xiàng),此處的值固定為"authorization_code"。
code:表示上一步獲得的授權(quán)碼,必選項(xiàng)。
redirect_uri:表示重定向URI,必選項(xiàng),且必須與A步驟中的該參數(shù)值保持一致。
client_id:表示客戶端ID,必選項(xiàng)。
示例:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb對比網(wǎng)站應(yīng)用微信登錄:通過code獲取access_token
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code4.3.4 步驟5:認(rèn)證服務(wù)器發(fā)送的HTTP回復(fù)
包含以下參數(shù):
access_token:表示訪問令牌,必選項(xiàng)。
token_type:表示令牌類型,該值大小寫不敏感,必選項(xiàng),可以是bearer類型或mac類型。
expires_in:表示過期時(shí)間,單位為秒。如果省略該參數(shù),必須其他方式設(shè)置過期時(shí)間。
refresh_token:表示更新令牌,用來獲取下一次的訪問令牌,可選項(xiàng)。
scope:表示權(quán)限范圍,如果與客戶端申請的范圍一致,此項(xiàng)可省略。
示例:
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"
} 從上面代碼可以看到,相關(guān)參數(shù)使用JSON格式發(fā)送(Content-Type: application/json)。此外,HTTP頭信息中明確指定不得緩存。
對比網(wǎng)站應(yīng)用微信登錄:返回樣例
{
"access_token":"ACCESS_TOKEN",
"expires_in":7200,
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID",
"scope":"SCOPE",
"unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}4.4 更新令牌
如果用戶訪問的時(shí)候,客戶端的訪問令牌access_token已經(jīng)過期,則需要使用更新令牌refresh_token申請一個(gè)新的訪問令牌。
客戶端發(fā)出更新令牌的HTTP請求,包含以下參數(shù):
granttype:表示使用的授權(quán)模式,此處的值固定為"refreshtoken",必選項(xiàng)。
refresh_token:表示早前收到的更新令牌,必選項(xiàng)。
scope:表示申請的授權(quán)范圍,不可以超出上一次申請的范圍,如果省略該參數(shù),則表示與上一次一致。
示例:
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
微信刷新Token:
https://api.weixin.qq.com/sns/oauth2/refresh_token?appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN(完)
參考文檔一:理解OAuth 2.0
參考文檔二:Oauth2.0原理
OAuth 授權(quán)的工作原理是怎樣的?足夠安全嗎?

喜歡,在看
