Bearer Token (RFC 6750) 用于OAuth 2.0授權(quán)訪問資源，任何Bearer持有者都可以無差別地用它來訪問相關(guān)的資源，而無需證明持有加密key。一個Bearer代表授權(quán)范圍、有效期，以及其他授權(quán)事項；一個Bearer在存儲和傳輸過程中應(yīng)當(dāng)防止泄露，需實現(xiàn)Transport Layer Security (TLS)；一個Bearer有效期通常很短，最好不超過1小時。

?一. 資源請求

　　Bearer實現(xiàn)資源請求有三種方式：Authorization Header、Form-Encoded Body Parameter、URI?Query Parameter，這三種方式優(yōu)先級依次遞減

• Authorization Header：該頭部定義與Basic方案類似

  GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM

• Form-Encoded Body Parameter：?下面是用法實例

  POST /resource HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencodedaccess_token=mF_9.B5f-4.1JqM

  使用該方法發(fā)送Bearer須滿足如下條件：

  1.頭部必須包含"Content-Type: application/x-www-form-urlencoded" 2.entity-body必須遵循application/x-www-form-urlencoded編碼(RFC 6749) 3.如果entity-body除了access_token之外，還包含其他參數(shù)，須以"&"分隔開 4.entity-body只包含ASCII字符 5.要使用request-body已經(jīng)定義的請求方法，不能使用GET

  如果客戶端無法使用Authorization請求頭，才應(yīng)該使用該方法發(fā)送Bearer

• URI?Query Parameter：

  GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1 Host: server.example.com
  Cache-Control: no-store

  服務(wù)端應(yīng)在響應(yīng)中使用?Cache-Control:?private

?

二. WWW-Authenticate頭

　　在客戶端未發(fā)送有效Bearer的情況下，即錯誤發(fā)生時，資源服務(wù)器須發(fā)送WWW-Authenticate頭，下為示例：

HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"

　　下面將就WWW-Authenticate字段的用法進(jìn)行詳細(xì)描述(下列這些屬性/指令不應(yīng)重復(fù)使用)：

• Bearer：Beare作為一種認(rèn)證類型(基于OAuth 2.0)，使用"Bearer"關(guān)鍵詞進(jìn)行定義

• realm：與Basic、Digest一樣，Bearer也使用相同含義的域定義reaml

• scope：授權(quán)范圍，可選的，大小寫敏感的，空格分隔的列表(%x21 / %x23-5B / %x5D-7E)，可以是授權(quán)服務(wù)器定義的任何值，不應(yīng)展示給終端用戶。OAuth 2.0還規(guī)定客戶端發(fā)送scope請求參數(shù)以指定授權(quán)訪問范圍，而在實際授權(quán)范圍與客戶端請求授權(quán)范圍不一致時，授權(quán)服務(wù)器可發(fā)送scope響應(yīng)參數(shù)以告知客戶端下發(fā)的token實際的授權(quán)范圍。下為兩個scope用法實例：

  scope="openid profile email" scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

• error：描述訪問請求被拒絕的原因，字符%x20-21 / %x23-5B / %x5D-7E之內(nèi)

• error_description：向開發(fā)者提供一個可讀的解釋，字符%x20-21 / %x23-5B / %x5D-7E之內(nèi)

• error_uri：absolute URI，標(biāo)識人工可讀解釋錯誤的頁面，字符%x21 / %x23-5B / %x5D-7E之內(nèi)

　　當(dāng)錯誤發(fā)生時，資源服務(wù)器將發(fā)送的HTTP Status Code(通常是400, 401, 403, 或405)及Error Code如下：

• invalid_request：請求丟失參數(shù)，或包含無效參數(shù)、值，參數(shù)重復(fù)，多種方法發(fā)送access token，畸形等。資源服務(wù)器將發(fā)送HTTP 400 (Bad Request)

• invalid_token：access token過期、廢除、畸形，或存在其他無效理由的情況。資源服務(wù)器將發(fā)送HTTP 401 (Unauthorized)，而客戶端則需要申請一個新的access token，然后才能重新發(fā)送該資源請求

• insufficient_scope：客戶端提供的access token的享有的權(quán)限太低。資源服務(wù)器將發(fā)送HTTP 403 (Forbidden)，同時WWW-Authenticate頭包含scope屬性，以指明需要的權(quán)限范圍

　　如果客戶端發(fā)送的資源請求缺乏任何認(rèn)證信息(如缺少access token，或者使用?RFC 6750?所規(guī)定的三種資源請求方式之外的任何method)，資源服務(wù)器不應(yīng)該在響應(yīng)中包含錯誤碼或者其他錯誤信息，如下即可：

HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example"

??

三. Bearer?Token Response

　　下為示例：

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache{"access_token":"mF_9.B5f-4.1JqM","token_type":"Bearer","expires_in":3600,"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" }

四. 安全威脅

• Token 偽造/修改(Token manufacture/modification)：攻擊者偽造或修改已有的token，導(dǎo)致資源服務(wù)器授權(quán)通過非法訪問的客戶端。因此需要對token使用數(shù)字簽名或消息認(rèn)證碼來token的完整性

• Token 泄露(Token disclosure)：Token本身可能包含認(rèn)證、有效期等敏感信息。因此實現(xiàn)TLS并驗證證書是必選項，加密token可用于防止客戶端觀察token的內(nèi)容，加密token還可防止token在前端服務(wù)器和后端服務(wù)器(如果他們沒有啟用TLS)之間發(fā)生泄露

• Token 改寄(Token redirect)：攻擊者用一個訪問A資源服務(wù)器的token去請求B資源服務(wù)器的資源。因此通常token中可以包含代表資源服務(wù)器的標(biāo)識來防止這種情況的發(fā)生

• Token 重放(Token replay)：攻擊者企圖使用曾經(jīng)使用過的token來請求資源。因此token需包含有效期(比如少于1小時)

?　　另外cookie不能包含token，關(guān)于cookie的安全弱點，RFC 6265?中有如下描述：

　　A server that uses cookies to authenticate users can suffer securityvulnerabilities because some user agents let remote parties issueHTTP requests from the user agent (e.g., via HTTP redirects or HTMLforms). When issuing those requests, user agents attach cookies evenif the remote party does not know the contents of the cookies,potentially letting the remote party exercise authority at an unwaryserver.

可見即使服務(wù)端實現(xiàn)了TLS，攻擊者依舊可以利用cookie來獲取機(jī)密信息，如果cookie中包含機(jī)密信息的話；對此，不得已可將機(jī)密信息包含于URLs(前提是已實現(xiàn)了TLS)，但盡量使用更安全的辦法，因為瀏覽器歷史記錄、服務(wù)器日志等可能泄露URLs機(jī)密信息。

五.?Transport Layer Security (TLS)

　　TLS (SSL / TLS)源于NetScape設(shè)計的SSL(Secure Sockets Layer，1994 / SSL 1.0、1995 / SSL 2.0、1996 / SSL 3.0)；1999年，IETF接替NetScape，發(fā)布了SSL的升級版TLS 1.0，最新為TLS 1.3(draft)，TLS 用于在兩個通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。目前，應(yīng)用最廣泛的是TLS 1.0，接下來是SSL 3.0，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持。TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。獲取更多信息可參考?TLS 1.2 /?RFC 5246?。

　　TLS是一種位于傳輸層(TCP)和應(yīng)用層之間的協(xié)議層，由記錄協(xié)議(Record Layer)和握手協(xié)議(Handshake Layer)兩層構(gòu)成：

?　　

?

六.?application/x-www-form-urlencoded Media Type

　　首先這種編碼類型未考慮非US-ASCII字符的情況，因此待發(fā)送的內(nèi)容(包括名稱、值)可先經(jīng)UTF-8編碼，然后再按字節(jié)序列進(jìn)行轉(zhuǎn)義；接收這種數(shù)據(jù)類型則需進(jìn)行逆向處理。通常各種web編程語言已經(jīng)提供原生URL編碼/URL解碼組件，使用起來也極為方便，因此這里不做詳細(xì)介紹。

原文地址：http://www.cnblogs.com/XiongMaoMengNan/p/6785155.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的OAuth 2.0: Bearer Token Usage的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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