Bearer認證 HTTP提供了一套標準的身份驗證框架：伺服器可以用來針對客戶端的請求發送質詢(challenge)，客戶端根據質詢提供身份驗證憑證。質詢與應答的工作流程如下：伺服器端向客戶端返回401（Unauthorized，未授權）狀態碼，併在WWW Authenticate頭中添加如何進行驗 ...
Bearer認證
HTTP提供了一套標準的身份驗證框架：伺服器可以用來針對客戶端的請求發送質詢(challenge)，客戶端根據質詢提供身份驗證憑證。質詢與應答的工作流程如下：伺服器端向客戶端返回401（Unauthorized，未授權）狀態碼，併在WWW-Authenticate頭中添加如何進行驗證的信息，其中至少包含有一種質詢方式。然後客戶端可以在請求中添加Authorization頭進行驗證，其Value為身份驗證的憑證信息。
在HTTP標準驗證方案中，我們比較熟悉的是"Basic"和"Digest"，前者將用戶名密碼使用BASE64編碼後作為驗證憑證，後者是Basic的升級版，更加安全，因為Basic是明文傳輸密碼信息，而Digest是加密後傳輸。在前文介紹的Cookie認證屬於Form認證，並不屬於HTTP標準驗證。
本文要介紹的Bearer驗證也屬於HTTP協議標準驗證，它隨著OAuth協議而開始流行，詳細定義見： RFC 6570。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol FlowBearer驗證中的憑證稱為BEARER_TOKEN，或者是access_token，它的頒發和驗證完全由我們自己的應用程式來控制，而不依賴於系統和Web伺服器，Bearer驗證的標準請求方式如下：
Authorization: Bearer [BEARER_TOKEN] JWT(JSON WEB TOKEN)
上面介紹的Bearer認證，其核心便是BEARER_TOKEN，而最流行的Token編碼方式便是：JSON WEB TOKEN。
Json web token (JWT), 是為了在網路應用環境間傳遞聲明而執行的一種基於JSON的開放標準[RFC 7519(https://tools.ietf.org/html/rfc7519)。該token被設計為緊湊且安全的，特別適用於分散式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源伺服器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
jwt主要包含以下三個內容：
- 頭部 Header
- 載荷 Payload
- 簽名 Signature
Jwt Token包含了使用.分隔的三部分
{Header 頭部}.{Payload 負載}.{Signature 簽名}頭部 Header
Header 一般由兩個部分組成：
- alg
- typ
alg是是所使用的hash演算法，如：HMAC SHA256或RSA，typ是Token的類型，在這裡就是：JWT。
{
"alg": "HS256",
"typ": "JWT"
}然後使用Base64Url編碼成第一部分
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>載荷 Payload
這一部分是JWT主要的信息存儲部分，其中包含了許多種的聲明（claims）。
Claims的實體一般包含用戶和一些元數據，這些claims分成三種類型：
- reserved claims：預定義的 一些聲明，並不是強制的但是推薦，它們包括 iss (issuer), exp (expiration time), sub (subject),aud(audience) 等（這裡都使用三個字母的原因是保證 JWT 的緊湊）。
- public claims: 公有聲明，這個部分可以隨便定義，但是要註意和 IANA JSON Web Token 衝突。
- private claims: 私有聲明，這個部分是共用被認定信息中自定義部分。
一個簡單的Pyload可以是這樣子的：
{
"user_name": "admin",
"scope": [
"read","write","del"
],
"organization": "admin",
"exp": 1531975621,
"authorities": [
"ADMIN"
],
"jti": "23408d38-8cdc-4460-beac-24c76dc7629a",
"client_id": "webapp"
}這部分同樣使用Base64Url編碼成第二部分
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>簽名 Signature
Signature是用來驗證發送者的JWT的同時也能確保在期間不被篡改。
簽名哈希部分是對上面兩部分數據簽名，通過指定的演算法生成哈希，以確保數據不會被篡改。
首先，需要指定一個密碼（secret）。該密碼僅僅為保存在伺服器中，並且不能向用戶公開。然後，使用標頭中指定的簽名演算法（預設情況下為HMAC SHA256）根據以下公式生成簽名。
使用Base64編碼後的header和payload以及一個秘鑰，使用header中指定簽名演算法進行簽名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)結果
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQbase64UrlEncode
如前所述，JWT頭和有效載荷序列化的演算法都用到了Base64URL。該演算法和常見Base64演算法類似，稍有差別。
作為令牌的JWT可以放在URL中（例如api.example/?token=xxx）。 Base64中用的三個字元是"+"，"/"和"="，由於在URL中有特殊含義，因此Base64URL中對他們做了替換："="去掉，"+"用"-"替換，"/"用"_"替換，這就是Base64URL演算法，很簡單把。
JWT的工作過程
客戶端接收伺服器返回的JWT，將其存儲在Cookie或localStorage中。
此後，客戶端將在與伺服器交互中都會帶JWT。如果將它存儲在Cookie中，就可以自動發送，但是不會跨域，因此一般是將它放入HTTP請求的Header Authorization欄位中。
Authorization: Bearer JWT_TOKEN當跨域時，也可以將JWT被放置於POST請求的數據主體中。
使用JWT具有如下好處
- 通用：因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
- 緊湊：JWT的構成非常簡單，位元組占用很小，可以通過 GET、POST 等放在 HTTP 的 header 中，非常便於傳輸。
- 擴展：JWT是自我包涵的，包含了必要的所有信息，不需要在服務端保存會話信息, 非常易於應用的擴展。
