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

?一. 資源請求

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

• 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

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

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

  如果客戶端無法使用Authorization請求頭，才應該使用該方法發送Bearer

• URI?Query Parameter：

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

  服務端應在響應中使用?Cache-Control:?private

?

二. WWW-Authenticate頭

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

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

　　下面將就WWW-Authenticate字段的用法進行詳細描述(下列這些屬性/指令不應重復使用)：

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

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

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

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

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

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

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

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

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

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

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

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

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，導致資源服務器授權通過非法訪問的客戶端。因此需要對token使用數字簽名或消息認證碼來token的完整性

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

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

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

?　　另外cookie不能包含token，關于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.

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

五.?Transport Layer Security (TLS)

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

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

?　　

?

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

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

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

---

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。