五種常用的Web安全認證方式
這是一種最古老的安全認證方式，這種方式就是簡單的訪問API的時候，帶上訪問的username和password，由於信息會暴露出去，所以現在也越來越少用了，現在都用更加安全保密的認證方式，可能某些老的平臺還在用。
如下圖所示，彈出一個框，讓你填寫用戶名密碼。這就是Tomcat自帶的HTTPBasic認證。
當用戶名密碼輸入錯誤後，會返回401 Unauthorized 表明認證失敗，無法訪問應用。
當認證成功後，你再看看詳細的request headers，會發現多了一個請求頭：
Authorization: Basic xxxXXXxxx
這就是你訪問應用的憑據了，那段xxxXXX字符串是我寫的表示這是一段密文，這是一段什麼密文呢，就是講用戶名和密碼進行一個Base64加密後得到的密文。所以你現在是不是也有同感了---這tm也太容易盜取了，所以現在新的應用幾乎不怎麼用這種方式了，雖然簡單，但是安全級別太低了。
2. OAuth2
本人之前的博客介紹過OAuth2 以及使用Azure AD實現OAuth2認證方式，在這裏呢，還是把那篇博客部分內容摳出來，方便大家總結查看。
https://blog.csdn.net/aHardDreamer/article/details/88650939
OAuth 即：Open Authrization(開放授權)， 它是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密資源，而無需將用戶名和密碼提供給第三方。比如我們熟知的通過qq/微信/微博等登錄第三方平臺。OAuth 1.0版本發佈後有許多安全漏洞，所以在OAuth2.0裏面完全廢止了OAuth1.0，它關注客戶端開發者的簡易性，要麼通過組織在資源擁有者和HTTP服務商之間的被批准的交互動作代表用戶，要麼允許第三方應用代表用戶獲得訪問的權限。讀起來有點繞口，其實原理也非常簡單，請看下面講解。
一、首先我們要了解在OAuth2 認證和授權的過程中有這三個角色：
1. 服務提供方：顧名思義，提供受保護的服務和資源的，用戶在這裏面存了很多東西。
2. 用戶： 存了東西（照片，資料等）在服務提供方的人。
3. 客戶端：服務調用方，它要訪問服務提供方的資源，需要在服務提供方進行註冊，不然服務提供方不鳥它呀。
二、OAuth2 認證和授權的過程：
1）用戶想操作存放在服務提供方的資源；
2）用戶登錄客戶端，客戶端向服務提供方請求一個臨時token;
3）服務提供方驗證客戶端的身份後，給它一個臨時token;
4）客戶端獲得臨時token之後，將用戶引導至服務提供方的授權頁面，並請求用戶授權。（在這個過程中會將臨時token和客戶端的回調鏈接/接口 發送給服務提供方 ---很明顯服務提供方到時會回來call這個接口在用戶認證並授權之後）
5）用戶輸入用戶名密碼登錄，登錄成功之後，可以授權客戶端訪問服務提供方的資源；
6）授權成功後，服務提供方將用戶引導至客戶端的網頁（call第4步裏面的回調鏈接/接口）；
7）客戶端根據臨時token從服務提供方那裏獲取正式的access token；
8）服務提供方根據臨時token以及用戶的授權情況授予客戶端access token;
9）客戶端使用access token訪問用戶存放在服務提供方的受保護的資源。
三、拿access token的方法（Grant Type）有下面四種，每一種都有適用的應用場景：
1. Authorization Code （授權碼模式）
結合普通服務器端應用使用。
1）用戶訪問客戶端，後者將前者導向認證服務器，假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個授權碼。
2)客戶端收到授權碼，附上早先的"重定向URI"，向認證服務器申請令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向頁面鏈接。請求成功返回code授權碼，一般有效時間是10分鐘。
3）認證服務器覈對了授權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向頁面鏈接。請求成功返回access Token和refresh Token。
2. Implicit（簡化模式）
結合移動應用或 Web App 使用。
Access Token直接從授權服務器返回(只有前端渠道)
不支持refresh tokens
假定資源所有者和公開客戶應用在同一個設備上
最容易受安全攻擊
3. Resource Owner Password Credentials
適用於受信任客戶端應用，例如同個組織的內部或外部應用。
使用用戶名密碼登錄的應用，例如桌面App
使用用戶名/密碼作爲授權方式從授權服務器上獲取access token
一般不支持refresh token
假定資源擁有者和公開客戶在相同設備上
4. Client Credentials
適用於客戶端調用主服務API型應用（比如百度API Store，不同項目之間的微服務互相調用）
只有後端渠道，使用客戶憑證獲取一個access token
因爲客戶憑證可以使用對稱或者非對稱加密，該方式支持共享密碼或者證書
3. Cookie-Session Auth
Cookie-Session 認證機制在我們初學J2EE的時候接觸的比較多，就是爲一次請求認證在服務端創建一個Session對象，同時在客戶端的瀏覽器端創建了一個Cookie對象；通過客戶端帶上來Cookie對象來與服務器端的session對象匹配來實現狀態管理的。默認的，當我們關閉瀏覽器的時候，cookie會被刪除。但可以通過修改cookie 的expire time使cookie在一定時間內有效；
但是這種基於cookie-session的認證使應用本身很難得到擴展，隨着不同客戶端用戶的增加，獨立的服務器已無法承載更多的用戶，而這時候基於session認證應用的問題就會暴露出來。
基於session認證所顯露的問題：
1）Session 增多會增加服務器開銷
每個用戶經過我們的應用認證之後，我們的應用都要在服務端做一次記錄，以方便用戶下次請求的鑑別，通常而言session都是保存在內存中，而隨着認證用戶的增多，服務端的開銷會明顯增大。
2）分佈式或多服務器環境中適應性不好
用戶認證之後，服務端做認證記錄，如果認證的記錄被保存在內存中的話，這意味着用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源，這樣在分佈式的應用上，相應的限制了負載均衡器的能力。這也意味着限制了應用的擴展能力。不過，現在某些服務器可以通過設置粘性Session，來做到每臺服務器之間的Session共享。
3）容易遭到CSRF攻擊
因爲是基於cookie來進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求僞造的攻擊
4. Token Auth
基於token的鑑權機制類似於http協議也是無狀態的，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味着基於token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了，這就爲應用的擴展提供了便利。
流程：
用戶使用用戶名密碼來請求服務器
服務器進行驗證用戶的信息
服務器通過驗證發送給用戶一個token
客戶端存儲token，並在每次請求時附送上這個token值
服務端驗證token值，並返回數據
這個token必須要在每次請求時傳遞給服務端，它應該保存在請求頭裏， 另外，服務端要支持CORS(跨來源資源共享)策略，一般我們在服務端這麼做就可以了Access-Control-Allow-Origin。
5. JWT 認證機制（Json Web Token）
JWT作爲一個開放的標準（RFC 7519），定義了一種簡潔的，自包含的方法用於通信雙方之間以Json對象的形式安全的傳遞信息。因爲數字簽名的存在，這些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私祕鑰對進行簽名。
簡潔性
可以通過URL，POST參數或者在HTTP header發送，因爲數據量小，傳輸速度也很快
自包含性
負載中包含了所有用戶所需要的信息，避免了多次查詢數據庫
下列場景中使用JSON Web Token是很有用的：
Authorization (授權) : 這是使用JWT的最常見場景。一旦用戶登錄，後續每個請求都將包含JWT，允許用戶訪問該令牌允許的路由、服務和資源。單點登錄是現在廣泛使用的JWT的一個特性，因爲它的開銷很小，並且可以輕鬆地跨域使用。
Information Exchange (信息交換) : 對於安全的在各方之間傳輸信息而言，JSON Web Tokens無疑是一種很好的方式。因爲JWTs可以被簽名，例如，用公鑰/私鑰對，你可以確定發送人就是它們所說的那個人。另外，由於簽名是使用頭和有效負載計算的，您還可以驗證內容沒有被篡改。
JWT的結構：
通過這張圖，很清晰看出JWT的結構分爲三部分，他們之間用“.”連接：
Header：
header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）。
例如：
然後，用Base64對這個JSON編碼就得到JWT的第一部分
Payload:
JWT的第二部分是payload，它包含聲明（要求）。聲明是關於實體(通常是用戶)和其他數據的聲明。聲明有三種類型: registered, public 和 private。
Registered claims : 這裏有一組預定義的聲明，它們不是強制的，但是推薦。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
Public claims : 可以隨意定義。
Private claims : 用於在同意使用它們的各方之間共享信息，並且不是註冊的或公開的聲明。
下面是一個例子：
對payload進行Base64編碼就得到JWT的第二部分
注意，不要在JWT的payload或header中放置敏感信息，除非它們是加密的。
Signature:
爲了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個祕鑰，簽名算法是header中指定的那個，然對它們簽名即可。
例如：
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
簽名是用於驗證消息在傳遞過程中有沒有被更改，並且，對於使用私鑰簽名的token，它還可以驗證JWT的發送方是否爲它所稱的發送方。
碰到JWT token可以去JWT官網解密看看，下面這是官網解密出來的數據，可以很清楚的看到它的三部分內容：
更多關於JWT的內容，可以前往這個博客：
https://www.cnblogs.com/cjsblog/p/9277677.html
參考：
https://www.jianshu.com/p/f8c43dcd8b69
https://blog.csdn.net/alan_liuyue/article/details/88183267
https://www.cnblogs.com/cjsblog/p/9277677.html