一、OAuth2認證
OAuth2是一個關於授權的開放標准，核心思路是通過各類認證手段（具體什么手段OAuth2不關心）認證用戶身份，並頒發token（令牌），
使得第三方應用可以使用該token（令牌）在限定時間、限定范圍訪問指定資源。
OAuth2相關概念：
資源所有者（resources owner）：擁有被訪問資源的用戶
客戶端/第三方應用（client）：第三方應用，獲取資源服務器提供的資源
授權服務器（authorization server）：認證服務器，提供授權許可code、令牌token等
資源服務器（resource server）：資源服務器，擁有被訪問資源的服務器，需要通過token來確定是否有權限訪問
OAuth2幾種模式：
獲取令牌的方式主要有四種，分別是授權碼模式、隱式授權碼模式（簡單模式）、密碼模式和客戶端模式。
1）授權碼模式（authorization code）
這種模式是最安全的OAuth2的授權模式。設計了auth code，通過這個code再獲取token，最后通過token獲取資源。支持refresh token。
應用場景：
各大應用內的qq，微信，微博登錄等。比如某應用內的qq登錄，過程如下：
a.用戶點擊qq登錄，會先跳轉到qq登錄頁面，這時請求已經跳轉到qq服務器了，然后用戶輸入賬號或者掃碼登錄，這時所有請求都在qq服務器完成。
b.用戶正確登錄后，qq服務器返回用戶的code給第三方應用，然后第三方應用再使用code去授權服務器請求獲取token。（這一步用戶不可見）
c.第三方應用獲取到token后，再使用token獲取用戶的qq名稱，頭像等信息。
優缺點：
優點：用戶可以控制自身的一些權限是否給第三方，第三方只能獲取到用戶臨時產生的一個訪問的code，安全性。
缺點：認證過程繁瑣。
2）隱式授權碼模式/簡單模式（implicit）
和授權碼模式類似，只不過少了獲取code的步驟，是直接獲取令牌token的，適用於公開的瀏覽器單頁應用，令牌直接從授權服務器返回，不支持刷新令牌，且沒有code安全保證，令牌容易因為被攔截竊聽而泄露。
不支持refresh token
3）密碼模式（resource owner password credentials）
這種模式是最不推薦的，因為client可能存了用戶密碼
這種模式主要用來做遺留項目升級為oauth2的適配方案
當然如果client是自家的應用，也是可以
支持refresh token
4）客戶端模式（client credentials）
這種模式直接根據client的id和密鑰即可獲取token，無需用戶參與
這種模式比較合適消費api的后端服務，比如拉取一組用戶信息等
不支持refresh token，主要是沒有必要
二、JWT機制
JWT概念：
JWT全稱為Json Web Token，隨着微服務架構的流行而越來越火，號稱新一代的認證技術。
OAuth2中使用token驗證用戶登錄合法性，但token最大的問題是不攜帶用戶信息，資源服務器無法在本地進行驗證，每次對於資源的訪問，資源服務器都需要向認證服務器發起請求，一是驗證token的有效性，二是獲取token對應的用戶信息。如果有大量的此類請求，無疑處理效率是很低，且認證服務器會變成一個中心節點，這在分布式架構下很影響性能。
JWT就是在這樣的背景下誕生的，從本質上來說，jwt和OAuth2沒有可比性。普通的oauth2頒發的就是一串隨機hash字符串，本身無意義，而jwt使用一種特殊格式的token，token是有特定含義的，分為三部分：
-頭部Header
-載荷Payload
-簽名Signature
這三部分均用base64進行編碼，並使用.進行分隔。一個典型的jwt格式的token類似xxxxx.yyyyy.zzzzz。
jwt其實並不是什么高深莫測的技術，相反非常簡單。認證服務器通過對稱或非對稱的加密方式利用payload生成signature，並在header中申明簽名方式，僅此而已。通過這種本質上極其傳統的方式，jwt可以實現分布式的token驗證功能，即資源服務器通過事先維護好的對稱或者非對稱密鑰（非對稱的話就是認證服務器提供的公鑰），直接在本地驗證token，這種去中心化的驗證機制非常適合分布式架構。jwt相對於傳統的token來說，解決以下兩個痛點：
1、通過驗證簽名，對於token的驗證可以直接在資源服務器本地完成，不需要連接認證服務器；
2、在payload中可以包含用戶相關信息，這樣就輕松實現了token和用戶信息的綁定；
如果認證服務器頒發的是jwt格式的token，那么資源服務器就可以直接自己驗證token的有效性並綁定用戶，這無疑大大提升了處理效率且減少了單點隱患。
適用場景：
一次性的身份認證、api的鑒權等，這些場景能充分發揮jwt無狀態以及分布式驗證的優勢。
不適用的場景：
不要試圖用jwt去代替session。這種模式下其實傳統的session+cookie機制工作的更好，jwt因為其無狀態和分布式，事實上只要在有效期內，是無法作廢的，用戶的簽退更多是一個客戶端的簽退，服務端token仍然有效，你只要使用這個token，仍然可以登陸系統。另外一個問題是續簽問題，使用token，無疑令續簽變得十分麻煩，當然你也可以通過redis去記錄token狀態，並在用戶訪問后更新這個狀態，但這就是硬生生把jwt的無狀態搞成有狀態了，而這些在傳統的session+cookie機制中都是不需要去考慮的。