HTTP協議規范中有兩種認證方式，一種是Basic認證，另外一種是Digest認證，這兩種方式都屬于無狀態認證方式，所謂無狀態即服務端都不會在會話中記錄相關信息，客戶端每次訪問都需要將用戶名和密碼放置報文一同發送給服務端，但這并不表示你在瀏覽器中每次訪問都要自己輸入用戶名和密碼，可能是你第一次輸入賬號后瀏覽器就保留在內存中供后面的交互使用。
BASIC基本認證
概述 ? ? ? ?
? ? ? ? 當一個客戶端向HTTP服務器進行數據請求時，如果客戶端未被認證，則HTTP服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證，以決定用戶是否合法。客戶端在接收到HTTP服務器的身份認證要求后，會提示用戶輸入用戶名及密碼，然后將用戶名及密碼以BASE64加密，加密后的密文將附加于請求信息中， 如當用戶名為chackca，密碼為：123456時，客戶端將用戶名和密碼用“：”合并，并將合并后的字符串用BASE64加密為密文，并于每次請求數據時，將密文附加于請求頭（Request Header）中。HTTP服務器在每次收到請求包后，根據協議取得客戶端附加的用戶信息（BASE64加密的用戶名和密碼），解開請求包，對用戶名及密碼進行驗證，如果用戶名及密碼正確，則根據客戶端請求，返回客戶端所需要的數據;否則，返回錯誤代碼或重新要求客戶端提供用戶名及密碼。
?
BASIC認證的過程
基本認證步驟：
? ? ? ? 1、客戶端訪問一個受http基本認證保護的資源。
? ? ? ?2、服務器返回401狀態，要求客戶端提供用戶名和密碼進行認證。（驗證失敗的時候，響應頭會加上WWW-Authenticate: Basic realm="請求域"。）
? ? ? ? ? ? ? ? 401 Unauthorized
? ? ? ? ? ? ? ? WWW-Authenticate： Basic realm="WallyWorld"
? ? ? 3、客戶端將輸入的用戶名密碼用Base64進行編碼后，采用非加密的明文方式傳送給服務器。Authorization: Basic xxxxxxxxxx.
? ? ? ? 4、服務器將Authorization頭中的用戶名密碼解碼并取出，進行驗證，如果認證成功，則返回相應的資源。如果認證失敗，則仍返回401狀態，要求重新進行認證。
?
? ? ? ? 服務端返回的認證報文中包含了realm=”myTomcat”，realm的值用于定義保護的區域，在服務端可以通過realm將不同的資源分成不同的域，域的名稱即為realm的值，每個域可能會有自己的權限鑒別方案。
Basic認證的一些特點
? ? ? ? 1、Http是無狀態的，同一個客戶端對同一個realm內資源的每一個訪問會被要求進行認證。
? ? ? ? 2、客戶端通常會緩存用戶名和密碼，并和authentication realm一起保存，所以，一般不需要你重新輸入用戶名和密碼。
? ? ? ? 3、以非加密的明文方式傳輸，雖然轉換成了不易被人直接識別的字符串，但是無法防止用戶名密碼被惡意盜用。雖然用肉眼看不出來，但用程序很容易解密。
優點：
? ? ? ? 基本認證的一個優點是基本上所有流行的網頁瀏覽器都支持基本認證。基本認證很少在可公開訪問的互聯網網站上使用，有時候會在小的私有系統中使用（如路由器網頁管理接口）。后來的機制HTTP摘要認證是為替代基本認證而開發的，允許密鑰以相對安全的方式在不安全的通道上傳輸。
缺點：
雖然基本認證非常容易實現，但該方案建立在以下的假設的基礎上，即：客戶端和服務器主機之間的連接是安全可信的。特別是，如果沒有使用SSL/TLS這樣的傳輸層安全的協議，那么以明文傳輸的密鑰和口令很容易被攔截。該方案也同樣沒有對服務器返回的信息提供保護。
現存的瀏覽器保存認證信息直到標簽頁或瀏覽器被關閉，或者用戶清除歷史記錄。HTTP沒有為服務器提供一種方法指示客戶端丟棄這些被緩存的密鑰。這意味著服務器端在用戶不關閉瀏覽器的情況下，并沒有一種有效的方法來讓用戶登出。
?
什么是Realm
Tomcat提供Realm支持。
Tomcat使用Realm使某些特定的用戶組具有訪問某些特定的Web應用的權限，而沒有權限的用戶不能訪問這個應用。
Tomcat提供了三種不同Realm對訪問某個Web應用程序的用戶進行相應的驗證。
? ? ? ? 1、JDBCRealm，這個Realm將用戶信息存在數據庫里，通過JDBC從數據庫中獲得用戶信息并進行驗證。
? ? ? ? 2、JNDIRealm，將用戶信息存在基于LDAP等目錄服務的服務器里，通過JNDI技術從LDAP服務器中獲取用戶信息并進行驗證。
? ? ? ? 3、MemoryRealm，將用戶信息存在一個xml文件中，對用戶進行驗證時，將會從相應的xml文件中提取用戶信息。manager(Tomcat提供的一個web應用程序)應用在進行驗證時即使用此種Realm。Realm類似于Unix里面的group。在Unix中，一個group對應著系統的一定資源，某個group不能訪問不屬于它的資源。Tomcat用Realm來對不同的應用(類似系統資源)賦給不同的用戶(類似group)。沒有權限的用戶則不能訪問這個應用。
?
?
DIGEST摘要認證
https://www.cnblogs.com/huey/p/5490759.html
? ? ? ? 基本認證便捷靈活，但極不安全。用戶名和密碼都是以明文形式傳送的，也沒有采取任何措施防止對報文的篡改。安全使用基本認證的唯一方式就是將其與 SSL 配合使用。
? ? ? ? 摘要認證是另一種 HTTP 認證協議，它與基本認證兼容，但卻更為安全。摘要認證試圖修復基本認證協議的嚴重缺陷。具體來說，摘要認證進行了如下改動：
永遠不會以明文方式在網絡上發送密碼。
可以防止惡意用戶捕獲并重放認證的握手過程。
可以有選擇地防止對報文內容的篡改。
防范其他幾種常見的攻擊方式。
? ? ? ? 摘要認證并不是最安全的協議。摘要認證并不能滿足安全 HTTP 事務的很多需求。對這些需求來說，使用 TLS 和 HTTPS 協議更為合適一些。但摘要認證比它要取代的基本認證強大很多。
?
? ? ? ? a) 客戶端請求了某個受保護文檔。
? ? ? ? b) 在客戶端能夠證明其知道密碼從而確認其身份之前，服務器拒絕提供文檔。服務器向客戶端發起質詢，詢問用戶名和摘要形式的密碼。
? ? ? ? c) 客戶端傳遞了密碼的摘要（用戶輸入實際的密碼，客戶端再將這個密碼轉化為摘要后再發送），證明它是知道密碼的。服務器知道所有用戶的密碼，因此可以將客戶提供的摘要與服務器自己計算得到的摘要進行比較，以驗證用戶是否知道密碼。另一方在不知道密碼的情況下，很難偽造出正確的摘要。
? ? ? ? d) 服務器將客戶端提供的摘要與服務器內部計算出的摘要進行對比。如果匹配，就說明客戶端知道密碼（或者很幸運地猜中了！）。可以設置摘要函數，使其產生很多數字，讓人不可能幸運地猜中摘要。服務器進行了匹配驗證之后，會將文檔提供給客戶端——整個過程都沒有在網絡上發送密碼。
?
重放攻擊
? ? ? ? 使用摘要就無需以明文形式發送密碼了。可以只發送密碼的摘要，而且可以確信，沒有哪個惡意用戶能輕易地從摘要中解碼出原始密碼。
? ? ? ? 但是，僅僅隱藏密碼并不能避免危險，因為即便不知道密碼，別有用心的人也可以截獲摘要，并一遍遍地重放給服務器。摘要和密碼一樣好用。
? ? ? ? 為防止此類重放攻擊的發生，服務器可以向客戶端發送了一個稱為隨機數 (nonce) 的特殊令牌，這個數會經常發生變化（可能是每毫秒，或者是每次認證都變化）。客戶端在計算摘要之前要先將這個隨機數令牌附加到密碼上去。
? ? ? ? 在密碼中加入隨機數就會使摘要隨著隨機數的每一次變化而變化。記錄下的密碼摘要只對特定的隨機數有效，而沒有密碼的話，攻擊者就無法計算出正確的摘要，這樣就可以防止重放攻擊的發生。
? ? ? ? 摘要認證要求使用隨機數，因為這個小小的重放弱點會使未隨機化的摘要認證變得和基本認證一樣脆弱。隨機數是在 WWW-Authenticate 質詢中從服務器傳送給客戶端。
?
摘要認證的握手機制（簡化的摘要認證三步握手機制）
?
? ? ? ? (1) 服務器計算出一個隨機數。
? ? ? ? (2) 服務器將這個隨機數放在 WWW-Authenticate 質詢報文中，與服務器所支持的算法列表一同發往客戶端。
? ? ? ? (3) 客戶端選擇一個算法，計算出密碼和其他數據的摘要。
? ? ? ? (4) 客戶端將摘要放在一條 Authorization 報文中發回服務器。如果客戶端要對服務器進行認證，可以發送客戶端隨機數。
? ? ? ? (5) 服務器接收摘要、選中的算法以及支撐數據，計算出與客戶端相同的摘要。然后服務器將本地生成的摘要與網絡傳送過來的摘要進行比較，驗證是否匹配。如果客戶端反過來用客戶端隨機數對服務器進行質詢，就會創建客戶端摘要。服務器可以預先將下一個隨機數計算出來，提前將其傳遞給客戶端，這樣下一次客戶端就可以預先發送正確的摘要了。
?
?
?
Cookie Auth
? ? ? ? Cookie認證機制：用戶輸入用戶名和密碼發起請求，服務器認證后給每個Session分配一個唯一的JSESSIONID，并通過Cookie發送給客戶端。
? ? ? ? 當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。默認的，當我們關閉瀏覽器的時候，客戶端cookie會被刪除，可以通過修改cookie 的expire time使cookie在一定時間內有效。但是服務器端的session不會被銷毀，除非通過invalidate或超時。
?
Token Auth（JWT）
?
?
Token Auth優點：
減輕服務器壓力：通過token可以將用戶的基本信息(非隱私的，比如UserId，過期時間，生成的隨機key等)全部加密簽名后放入token中，從而服務器端不需要保存用戶登錄信息，大大減輕服務器壓力。用戶認證完全靠token識別，通過簽名來保證token沒有被修改過（只有服務器才知道秘鑰，比如常見的非對稱加密算法），是服務器下發的token。
支持跨域訪問：因為服務器并沒有保存登錄狀態，完全靠簽名的token識別，那么另一個網站只要有對應的私鑰，就可以對token驗證，前提是傳輸的用戶認證信息通過HTTP頭傳輸；
更適用CDN: 可以通過內容分發網絡請求你服務端的所有資料（如：javascript，HTML,圖片等），因為不需要同步服務器上的登錄狀態信息；
性能更好: 因為從token中可以獲得userId，不用查詢登錄狀態表；
原文：https://blog.csdn.net/qq_35642036/article/details/82788588?
