摘要：步驟接收到狀態碼的客戶端為了通過認證，需要將用戶及密碼發送給服務器。所謂雙因素認證就是指，認證過程中不僅需要密碼這一個因素，還需要申請認證者提供其他持有信息，從而作為另一個因素，與其組合使用的認證方式。

某些 Web 頁面只想讓特定的人瀏覽，或者干脆僅本人可見。為達到這個目標，必不可少的就是認證功能。下面我們一起來學習一下認證機制。

一.　何為認證

1.計算機本身無法判斷坐在顯示器前的使用者的身份。進一步說，也無法確認網絡的那頭究竟有誰。可見，為了弄清究竟是誰在訪問服務器，就得讓對方的客戶端自報家門。可是，就算正在訪問服務器的對方聲稱自己是ueno，身份是否屬實這點卻也無從談起。為確認 ueno 本人是否真的具有訪問系統的權限， 就需要核對“登錄者本人才知道的信息”、“登錄者本人才會有的信息”。

2.核對的信息通常是指以下這些:
密碼：只有本人才會知道的字符串信息。
動態令牌：僅限本人持有的設備內顯示的一次性密碼。
數字證書：僅限本人（終端）持有的信息。
生物認證：指紋和虹膜等本人的生理信息。
IC 卡等：僅限本人持有的信息。

但是，即便對方是假冒的用戶，只要能通過用戶驗證，那么計算機就會默認是出自本人的行為。因此，掌控機密信息的密碼絕不能讓他人得到，更不能輕易地就被破解出來。HTTP 使用的認證方式 HTTP/1.1 使用的認證方式如下所示。 BASIC 認證（基本認證） DIGEST 認證（摘要認證）SSL 客戶端認證 FormBase 認證（基于表單認證）此外，還有 Windows 統一認證（Keberos 認證、NTLM 認證）。

二.BASIC 認證BASIC

認證（基本認證）是從 HTTP/1.0 就定義的認證方式。即便是現在仍有一部分的網站會使用這種認證方式。是 Web 服務器與通信客戶端之間進行的認證方式。

1.BASIC 認證的認證步驟

步驟 1： 當請求的資源需要 BASIC 認證時，服務器會隨狀態碼 401 Authorization 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 資源的響應。

BASIC 認證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加信息即可對其解碼。換言之，由于明文解碼后就是用戶 ID 和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中，如果被人竊聽，被盜的可能性極高。另外，除此之外想再進行一次 BASIC 認證時，一般的瀏覽器卻無法實現認證注銷操作，這也是問題之一。BASIC 認證使用上不夠便捷靈活，且達不到多數 Web 網站期望的安全性等級，因此它并不常用。

三.　DIGEST 認證

為彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證。 DIGEST 認證同樣使用質詢 / 響應的方式 （challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

1.所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接著使用從另一方那接收到的質詢碼計算生成響應碼。最后將響應碼返回給對方進行認證的方式。

因為發送給對方的只是響應摘要及由質詢碼產生的計算結果，所以比起 BASIC 認證，密碼泄露的可能性就降低了。

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 運算后的密碼字符串，形成響應碼。響應中其他的實體請參見第 6 章的請求首部字段 Authorization。另外，有關 Request-Digest 的計算規則較復雜，有興趣的讀者不妨深入 學習一下 RFC2617。

步驟 3： 接收到包含首部字段 Authorization 請求的服務器，會確認認證信息的正確性。認證通過后則返回包含 Request-URI 資源的響應。 并且這時會在首部字段 Authentication-Info 寫入一些認證成功的相關信息。DIGEST 認證提供了高于 BASIC 認證的安全等級，但是和 HTTPS 的客戶端認證相比仍舊很弱。DIGEST 認證提供防止密碼被竊聽的保護機制，但并不存在防止用戶偽裝的保護機制。DIGEST 認證和 BASIC 認證一樣，使用上不那么便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求標準。因此它的適用范圍也 有所受限。

四.SSL 客戶端認證

從使用用戶 ID 和密碼的認證方式方面來講，只要二者的內容正確， 即可認證是本人的行為。但如果用戶 ID 和密碼被盜，就很有可能被第三者冒充。利用 SSL 客戶端認證則可以避免該情況的發生。SSL 客戶端認證是借由 HTTPS 的客戶端證書完成認證的方式。憑借客戶端證書（在 HTTPS 一章已講解）認證，服務器可確認訪問是否來自已登錄的客戶端。

SSL 客戶端認證的認證步驟為達到 SSL 客戶端認證的目的，需要事先將客戶端證書分發給客戶端，且客戶端必須安裝此證書。

步驟 1： 接收到需要認證資源的請求，服務器會發送 Certificate Request 報文，要求客戶端提供客戶端證書。
步驟 2： 用戶選擇將發送的客戶端證書后，客戶端會把客戶端證書信息以 Client Certificate 報文方式發送給服務器。

圖：選擇客戶端證書示例（三菱東京 UFJ 銀行）

步驟 3： 服務器驗證客戶端證書驗證通過后方可領取證書內客戶端的公開密鑰，然后開始 HTTPS 加密通信。

SSL 客戶端認證采用雙因素認證在多數情況下，SSL客戶端認證不會僅依靠證書完成認證，一般會和基于表單認證（稍后講解）組合形成一種雙因素認證（Two-factor authentication）來使用。所謂雙因素認證就是指，認證過程中不僅需要密碼這一個因素，還需要申請認證者提供其他持有信息，從而作為另一個因素，與其組合使用的認證方式。換言之，第一個認證因素的 SSL 客戶端證書用來認證客戶端計算機，另一個認證因素的密碼則用來確定這是用戶本人的行為。通過雙因素認證后，就可以確認是用戶本人正在使用匹配正確的計算機訪問服務器。

SSL 客戶端認證必要的費用使用 SSL 客戶端認證需要用到客戶端證書。而客戶端證書需要支付一 定費用才能使用。這里提到的費用是指，從認證機構購買客戶端證書的費用，以及服務 器運營者為保證自己搭建的認證機構安全運營所產生的費用。每個認證機構頒發客戶端證書的費用不盡相同，平攤到一張證書上，一年費用約幾萬至十幾萬日元。服務器運營者也可以自己搭建認證機構，但要維持安全運行就會產生相應的費用。

五.基于表單認證

基于表單的認證方法并不是在 HTTP 協議中定義的。客戶端會向服務器上的 Web 應用程序發送登錄信息（Credential），按登錄信息的驗證結果認證。根據 Web 應用程序的實際安裝，提供的用戶界面及認證方式也各不相同。

圖：基于表單認證示例（Google）
多數情況下，輸入已事先登錄的用戶 ID（通常是任意字符串或郵件 地址）和密碼等登錄信息后，發送給 Web 應用程序，基于認證結果 來決定認證是否成功。

認證多半為基于表單認證

由于使用上的便利性及安全性問題，HTTP 協議標準提供的 BASIC 認證和 DIGEST 認證幾乎不怎么使用。另外，SSL 客戶端認證雖然具有高度的安全等級，但因為導入及維持費用等問題，還尚未普及。比如 SSH 和 FTP 協議，服務器與客戶端之間的認證是合乎標準規范的，并且滿足了最基本的功能需求上的安全使用級別，因此這些協議的認證可以拿來直接使用。但是對于 Web 網站的認證功能，能夠滿足其安全使用級別的標準規范并不存在，所以只好使用由 Web 應用程序各自實現基于表單的認證方式。不具備共同標準規范的表單認證，在每個 Web 網站上都會有各不相同的實現方式。如果是全面考慮過安全性能而實現的表單認證，那么 就能夠具備高度的安全等級。但在表單認證的實現中存在問題的 Web 網站也是屢見不鮮。

Session 管理及 Cookie 應用基于表單認證的標準規范尚未有定論，一般會使用 Cookie 來管理 Session（會話）。基于表單認證本身是通過服務器端的 Web 應用，將客戶端發送過來 的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認證的。但鑒于 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 識別用戶和其認證狀態。

除了以上介紹的應用實例，還有應用其他不同方法的案例。另外，不僅基于表單認證的登錄信息及認證過程都無標準化的方法,服務器端應如何保存用戶提交的密碼等登錄信息等也沒有標準化。通常，一種安全的保存方法是，先利用給密碼加鹽（salt）1 的方式增加額外信息，再使用散列（hash）函數計算出散列值后保存。但是我們也經常看到直接保存明文密碼的做法，而這樣的做法具有導致密碼 泄露的風險。
(salt 其實就是由服務器隨機生成的一個字符串，但是要保證長度足夠長，并且是真正隨機生成的。然后把它和密碼字符串相連接（前后都可以）生成散列值。當兩個用戶使用了同一個密碼時，由于隨機生成的 salt 值不同，對應的散列值也將是不同的。這樣一來，很大程度上減少了密碼特征，攻擊者也就很難利用自己手中的密碼特征庫進行破解。)
以下是往日學習總結，有需要的盆友可以去看看噢~~
TCP/IP基礎總結性學習（1） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（2） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（3） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（4） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（5） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（6） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（7） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
前端面試實習題目總結： - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...