導讀
Json web token (JWT), 是為了在網(wǎng)絡應用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景塞蹭。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息匹表，以便于從資源服務器獲取資源门坷，也可以增加一些額外的其它業(yè)務邏輯所必須的聲明信息，該token也可直接被用于認證袍镀，也可被加密默蚌。
我們知道，http協(xié)議本身是一種無狀態(tài)的協(xié)議苇羡，而這就意味著如果用戶向我們的應用提供了用戶名和密碼來進行用戶認證绸吸，那么下一次請求時，用戶還要再一次進行用戶認證才行设江，因為根據(jù)http協(xié)議锦茁，我們并不能知道是哪個用戶發(fā)出的請求，所以為了讓我們的應用能識別是哪個用戶發(fā)出的請求叉存，我們只能在服務器存儲一份用戶登錄的信息码俩，這份登錄信息會在響應時傳遞給瀏覽器，告訴其保存為cookie,以便下次請求時發(fā)送給我們的應用歼捏，這樣我們的應用就能識別請求來自哪個用戶了稿存。
幾種常見的傳統(tǒng)認證機制
HTTP Basic Auth
HTTP Basic Auth簡單點說明就是每次請求API時都提供用戶的username和password，簡言之瞳秽，Basic Auth是配合RESTful API 使用的最簡單的認證方式瓣履，只需提供用戶名密碼即可，但由于有把用戶名密碼暴露給第三方客戶端的風險寂诱，在生產(chǎn)環(huán)境下被使用的越來越少拂苹。因此，在開發(fā)對外開放的RESTful API時，盡量避免采用HTTP Basic Auth瓢棒。
OAuth
OAuth（開放授權）是一個開放的授權標準浴韭，允許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源（如照片，視頻脯宿，聯(lián)系人列表）念颈，而無需將用戶名和密碼提供給第三方應用。
OAuth允許用戶提供一個令牌连霉，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數(shù)據(jù)榴芳。每一個令牌授權一個特定的第三方系統(tǒng)（例如，視頻編輯網(wǎng)站)在特定的時段（例如跺撼，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）窟感。這樣，OAuth讓用戶可以授權第三方網(wǎng)站訪問他們存儲在另外服務提供者的某些特定信息歉井，而非所有內容
下面是OAuth2.0的流程：
Cookie Auth
Cookie認證機制就是為一次請求認證在服務端創(chuàng)建一個Session對象柿祈，同時在客戶端的瀏覽器端創(chuàng)建了一個Cookie對象；通過客戶端帶上來Cookie對象來與服務器端的session對象匹配來實現(xiàn)狀態(tài)管理的哩至。默認的躏嚎，當我們關閉瀏覽器的時候，cookie會被刪除菩貌。但可以通過修改Cookie 的expire time使cookie在一定時間內有效卢佣；
Token 簡介
JWT (Json Web Token)是為了在網(wǎng)絡應用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標準。
JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息箭阶，以便于從資源服務器獲取資源虚茶。比如用在用戶登錄上。
有些朋友可能會認為尾膊，我登錄只需要用緩存或者數(shù)據(jù)庫記錄下一個特征碼或者是Cookies就可以了媳危，為什么要使用JWT呢？我們知道一個數(shù)據(jù)庫或者是一個軟件冈敛，損耗時間最大的地方就是我們的 I/O(輸入輸出，通常指的就是硬盤的讀寫)鸣皂，因此我們選擇解碼一次HS256抓谴，對于現(xiàn)在的計算能力強大的計算機而言，解一次HS256比訪問一次磁盤要快得多寞缝。
基于token的鑒權機制類似于http協(xié)議也是無狀態(tài)的癌压，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味著基于token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了荆陆，這就為應用的擴展提供了便利滩届。
流程上是這樣的：
- 用戶使用用戶名密碼來請求服務器
- 服務器進行驗證用戶的信息
- 服務器通過驗證發(fā)送給用戶一個token
- 客戶端存儲token，并在每次請求時附送上這個token值
- 服務端驗證token值被啼，并返回數(shù)據(jù)
這個token必須要在每次請求時傳遞給服務端帜消，它應該保存在請求頭里棠枉， 另外，服務端要支持CORS(跨來源資源共享)策略泡挺，一般我們在服務端這么做就可以了Access-Control-Allow-Origin: *辈讶。
那么我們現(xiàn)在回到JWT的主題上。
JWT 的組成
我們先來看一段jwt
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
仔細觀察我們可以發(fā)現(xiàn)這一段字符串中含有兩個 " . ",這兩個 " . "把jwt分成了三份娄猫，我們分別成為頭部贱除、荷載信息、簽證信息媳溺。那么這三部分的分工是什么呢月幌？
Header
JWT的頭部承載了兩個信息
- 聲明類型,對于Jwt來說就是jwt
- 加密算法，通常使用SHA256,HS256
完整的頭部應該是像這樣的一個Json
{
'typ': 'JWT',
'alg': 'HS256'
}
將頭部Json進行base64加密就得到了我們的第一部分
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
Payload
第二部分是荷載信息悬蔽，Payload,你可以理解為我們的JWT是一輛大倉庫扯躺，第一部分頭部就是倉庫的名稱編號等基礎信息，而荷載信息就是倉庫的本身屯阀，包含了倉庫里面的所有貨物缅帘。這些信息又包含了三個部分：
- 標準中注冊的聲明
- 公共的聲明
- 私有的聲明
標準中注冊的聲明 (建議但不強制使用) ：
iss: jwt簽發(fā)者
sub: jwt所面向的用戶
aud: 接收jwt的一方
exp: jwt的過期時間，這個過期時間必須要大于簽發(fā)時間
nbf: 定義在什么時間之前难衰，該jwt都是不可用的.
iat: jwt的簽發(fā)時間
jti: jwt的唯一身份標識钦无，主要用來作為一次性token,從而回避重放攻擊。
公共的聲明 ：
公共的聲明可以添加任何的信息盖袭，一般添加用戶的相關信息或其他業(yè)務需要的必要息失暂。但不建議添加敏感信息，因為該部分在客戶端可解密鳄虱。
私有的聲明 ：
私有聲明是提供者和消費者所共同定義的聲明弟塞，一般不建議存放敏感信息，因為base64是對稱解密的拙已，意味著該部分信息可以歸類為明文信息决记。
事實上我們的Header和Payload都是基于base64加密的，這種密文都是可以對稱解密的倍踪，因此請不要存放敏感信息系宫。
定義一個payload:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
進行base64加密后，得到了我們的第二部分
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
Signature
Jwt的第三部分是一個簽證信息建车，這個簽證信息由三部分組成：
- header (base64后的)
- payload (base64后的)
- secret
這一部分可以理解為對前部分的一個校驗扩借，將前兩部分加密后的密文通過在Header中定義的加密方式，與服務端所傳入的密鑰進行一次加密缤至，假如前兩部分的信息被篡改的話潮罪，必然通不過最后一部分簽證的校驗。因此通過這樣保證了Jwt的安全性。
因此嫉到，保存并隱藏好我們的加密密鑰是非常重要的沃暗，假設泄露了，就意味著任何知道密鑰的人都可以輕松的對jwt進行自我簽發(fā)和驗證屯碴。
