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 Flow
Bearer驗證中的憑證稱為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.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
base64UrlEncode
如前所述，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是自我包涵的，包含了必要的所有信息，不需要在服務端保存會話信息, 非常易於應用的擴展。