一、概述
某些Web頁面隻想讓特定的人浏覽，或者幹脆僅本人可見。未達到這個目标，必不可少的就是認證功能。
二、何為認證
（1）登入者本人才會有的資訊
密碼：隻有本人才會知道的字元串資訊。
動态令牌：僅限本人持有的裝置内顯示的一次性密碼。
數字證書：僅限本人（終端）持有的資訊。
生物認證：指紋和虹膜等本人的生理資訊。
IC 卡等：僅限本人持有的資訊
（2）但是，即使對方是假冒的使用者，隻要能通過使用者驗證，那麼計算機就會預設是出自本人的行為。是以，掌控機密資訊的密碼絕對不能讓其他人得到，更不能輕易得就被破解出來。
（3）HTTP使用的認證方式
HTTP/1.1使用的認證方式如下所示
- BASIC 認證（基本認證）
- DIGEST 認證（摘要認證）
- SSL 用戶端認證
- FormBase 認證（基于表單認證）
此外，還有 Windows 統一認證（Keberos 認證、NTLM 認證）
三、BASIC認證
（1）BASIC認證（基本認證）是從HTTP/1.0就定義的認證方式。是Web伺服器于通信用戶端之間進行的認證方式。
（2）BASIC認證的認證步驟
步驟 1： 當請求的資源需要 BASIC 認證時，伺服器會随狀态碼 401Authorization Required，傳回帶 WWW-Authenticate 首部字段的響應。 該字段内包含認證的方式（BASIC） 及 Request-URI 安全域字元串（realm）。
步驟 2： 接收到狀态碼 401 的用戶端為了通過 BASIC 認證，需要将使用者 ID 及密碼發送給伺服器。發送的字元串内容是由使用者 ID 和密碼構成，兩者中間以冒号（:）連接配接後，再經過 Base64 編碼處理。
假設使用者 ID 為 guest，密碼是 guest，連接配接起來就會形成 guest:guest 這樣的字元串。然後經過 Base64 編碼，最後的結果即是Z3Vlc3Q6Z3Vlc3Q=。把這串字元串寫入首部字段 Authorization 後，發送請求。
當使用者代理為浏覽器時，使用者僅需輸入使用者 ID 和密碼即可，之後，浏覽器會自動完成到 Base64 編碼的轉換工作。
步驟 3： 接收到包含首部字段 Authorization 請求的伺服器，會對認證資訊的正确性進行驗證。如驗證通過，則傳回一條包含 Request-URI資源的響應。
（3）BASIC 認證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加資訊即可對其解碼。換言之，由于明文解碼後就是使用者 ID 和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中，如果被人竊聽，被盜的可能性極高。
（4）另外，除此之外想再進行一次 BASIC 認證時，一般的浏覽器卻無法實作認證登出操作，這也是問題之一。
（5）BASIC 認證使用上不夠便捷靈活，且達不到多數 Web 網站期望的安全性等級，是以它并不常用。
四、DIGEST認證
（1）為彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證。 DIGEST 認證同樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。
（2）所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接着使用從另一方那接收到的質詢碼計算生成響應碼。最後将響應碼傳回給對方進行認證的方式。
（3）因為發送給對方的隻是響應摘要及由質詢碼産生的計算結果，是以比起 BASIC 認證，密碼洩露的可能性就降低了。
（4）DIGEST 認證的認證步驟
步驟 1： 請求需認證的資源時，伺服器會随着狀态碼 401 Authorization Required，返 回帶 WWW-Authenticate 首部字段的響應。 該字段内包含質問響應方式認證所需的臨時質詢碼（随機數， nonce）。
首部字段 WWW-Authenticate 内必須包含 realm 和 nonce 這兩個字段的資訊。用戶端就是依靠向伺服器回送這兩個值進行認證的。
nonce 是一種每次随傳回的 401 響應生成的任意随機字元串。該字元串通常推薦由 Base64 編碼的十六進制數的組成形式，但實際内容依賴伺服器的具體實作。
步驟 2： 接收到 401 狀态碼的用戶端，傳回的響應中包含 DIGEST 認證必須的首部字段 Authorization 資訊。
首部字段 Authorization 内必須包含 username、realm、nonce、uri 和 response 的字段資訊。其中，realm 和 nonce 就是之前從伺服器接收到的響應中的字段。
username 是 realm 限定範圍内可進行認證的使用者名。
uri（digest-uri）即 Request-URI 的值，但考慮到經代理轉發後 Request-URI 的值可能被修改，是以事先會複制一份副本儲存在 uri内。
response 也可叫做 Request-Digest，存放經過 MD5 運算後的密碼字元串，形成響應碼。
步驟 3： 接收到包含首部字段 Authorization 請求的伺服器，會确認認證資訊的正确性。認證通過後則傳回包含 Request-URI 資源的響應。并且這時會在首部字段 Authentication-Info 寫入一些認證成功的相關資訊。
（5）DIGEST 認證提供了高于 BASIC 認證的安全等級，但是和 HTTPS 的用戶端認證相比仍舊很弱。DIGEST 認證提供防止密碼被竊聽的保護機制，但并不存在防止使用者僞裝的保護機制。
（6）DIGEST 認證和 BASIC 認證一樣，使用上不那麼便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求标準。是以它的适用範圍也有所受限。
五、SSL用戶端認證
（1）從使用使用者 ID 和密碼的認證方式方面來講，隻要二者的内容正确， 即可認證是本人的行為。但如果使用者 ID 和密碼被盜，就很有可能被第三者冒充。利用 SSL用戶端認證則可以避免該情況的發生。
（2）SSL用戶端認證是借由 HTTPS 的用戶端證書完成認證的方式。憑借用戶端證書認證，伺服器可确認通路是否來自已登入的用戶端。
（3）SSL 用戶端認證的認證步驟
為達到 SSL用戶端認證的目的，需要事先将用戶端證書分發給用戶端，且用戶端必須安裝此證書。
步驟 1： 接收到需要認證資源的請求，伺服器會發送 Certificate Request 封包，要求用戶端提供用戶端證書。
步驟 2： 使用者選擇将發送的用戶端證書後，用戶端會把用戶端證書資訊以 Client Certificate 封包方式發送給伺服器。
步驟 3： 伺服器驗證用戶端證書驗證通過後方可領驗證書内用戶端的公開密鑰，然後開始 HTTPS 加密通信。
（4）SSL 用戶端認證采用雙因素認證
1）在多數情況下，SSL用戶端認證不會僅依靠證書完成認證，一般會和基于表單認證（稍後講解）組合形成一種雙因素認證（Two-factor authentication）來使用。
2）所謂雙因素認證就是指，認證過程中不僅需要密碼這一個因素，還需要申請認證者提供其他持有資訊，進而作為另一個因素，與其組合使用的認證方式。
3）換言之，第一個認證因素的 SSL用戶端證書用來認證用戶端計算機， 另一個認證因素的密碼則用來确定這是使用者本人的行為。
4）通過雙因素認證後，就可以确認是使用者本人正在使用比對正确的計算機通路伺服器。
（5）SSL 用戶端認證必要的費用
1）使用 SSL用戶端認證需要用到用戶端證書。而用戶端證書需要支付一定費用才能使用。
2）這裡提到的費用是指，從認證機構購買用戶端證書的費用，以及伺服器營運者為保證自己搭建的認證機構安全營運所産生的費用。
3）每個認證機構頒發用戶端證書的費用不盡相同，平攤到一張證書上，一年費用約幾萬至十幾萬日元。伺服器營運者也可以自己搭建認證機構，但要維持安全運作就會産生相應的費用。
六、基于表單認證
（1）基于表單的認證方法并不是在 HTTP 協定中定義的。用戶端會向服務 器上的 Web 應用程式發送登入資訊（Credential），按登入資訊的驗證結果認證。
（2）根據 Web 應用程式的實際安裝，提供的使用者界面及認證方式也各不相同。
（3）多數情況下，輸入已事先登入的使用者 ID（通常是任意字元串或郵件位址）和密碼等登入資訊後，發送給Web 應用程式，基于認證結果來決定認證是否成功。
七、認證多半為基于表單認證
（1）由于使用上的便利性及安全性問題，HTTP 協定标準提供的 BASIC 認證和 DIGEST 認證幾乎不怎麼使用。
（2）另外，SSL用戶端認證雖然具有高度的安全等級，但因為導入及維持費用等問題，還尚未普及。
（3）比如 SSH 和 FTP 協定，伺服器與用戶端之間的認證是合乎标準規範的，并且滿足了最基本的功能需求上的安全使用級别，是以這些協定的認證可以拿來直接使用.
（4）但是對于 Web 網站的認證功能，能夠滿足其安全使用級别的标準規範并不存在，是以隻好使用由 Web 應用程式各自實作基于表單的認證方式。
（5）不具備共同标準規範的表單認證，在每個 Web 網站上都會有各不相同的實作方式。如果是全面考慮過安全性能而實作的表單認證，那麼就能夠具備高度的安全等級。但在表單認證的實作中存在問題的 Web網站也是屢見不鮮。
八、Session管理及Cookie應用
（1）基于表單認證的标準規範尚未有定論，一般會使用 Cookie 來管理 Session（會話）。
（2）基于表單認證本身是通過伺服器端的 Web 應用，将用戶端發送過來的使用者 ID 和密碼與之前登入過的資訊做比對來進行認證的。
（3）但鑒于 HTTP 是無狀态協定，之前已認證成功的使用者狀态無法通過協定層面儲存下來。即，無法實作狀态管理，是以即使當該使用者下一次繼續通路，也無法區分他與其他的使用者。于是我們會使用 Cookie 來管理 Session，以彌補 HTTP 協定中不存在的狀态管理功能。
步驟 1： 用戶端把使用者 ID 和密碼等登入資訊放入封包的實體部分， 通常是以 POST 方法把請求發送給伺服器。而這時，會使用 HTTPS通信來進行 HTML表單畫面的顯示和使用者輸入資料的發送。
步驟 2： 伺服器會發放用以識别使用者的 Session ID。通過驗證從用戶端發送過來的登入資訊進行身份認證，然後把使用者的認證狀态與Session ID 綁定後記錄在伺服器端。向用戶端傳回響應時，會在首部字段 Set-Cookie 内寫入 Session ID（如 PHPSESSID=028a8c…）。你可以把 Session ID 想象成一種用以區分不同使用者的等位号。
然而，如果 Session ID 被第三方盜走，對方就可以僞裝成你的身份進行惡意操作了。是以必須防止 Session ID 被盜，或被猜出。為了做到這點，Session ID 應使用難以推測的字元串，且伺服器端也需要進行有效期的管理，保證其安全性
另外，為減輕跨站腳本攻擊（XSS）造成的損失，建議事先在 Cookie内加上 httponly 屬性。
步驟 3： 用戶端接收到從伺服器端發來的 Session ID 後，會将其作為Cookie 儲存在本地。下次向伺服器發送請求時，浏覽器會自動發送Cookie，是以 Session ID 也随之發送到伺服器。伺服器端可通過驗證接收到的 Session ID 識别使用者和其認證狀态。
（4）另外，不僅基于表單認證的登入資訊及認證過程都無标準化的方法， 伺服器端應如何儲存使用者送出的密碼等登入資訊等也沒有标準化.
（5）通常，一種安全的儲存方法是，先利用給密碼加鹽（salt）1 的方式增加額外資訊，再使用散列（hash）函數計算出散列值後儲存。但是我們也經常看到直接儲存明文密碼的做法，而這樣的做法具有導緻密碼洩露的風險。
（6）salt 其實就是由伺服器随機生成的一個字元串，但是要保證長度足夠長，并且是真正随機生成的。然後把它和密碼字元串相連接配接（前後都可以）生成散列值。當兩個使用者使用了同一個密碼時，由于随機生成的 salt 值不同，對應的散列值也将是不同的。這樣一來，很大程度上減少了密碼特征，攻擊者也就很難利用自己手中的密碼特征庫進行破解。