本文為大家介紹了五種常用的web安全認證方式，具有一定的參考價值，希望能對大家有幫助。
1、Http Basic Auth
這是一種最古老的安全認證方式，這種方式就是簡單的存取API的時候，帶上存取的username和password，由於資訊會暴露出去，所以現在也越來越少用了，現在都用更安全保密的認證方式，可能某些舊的平台還在用。
如下圖所示，彈出一個框，讓你填寫使用者名稱密碼。這就是Tomcat自備的HTTPBasic認證。
這就是你存取應用程式的憑證了，那段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。
（免費學習影片分享：php影片教學）
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
相關建議：web伺服器安全
以上是介紹幾種常用的web安全認證方式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
