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

某些 Web 頁(yè)面只想讓特定的人瀏覽，或者干脆僅本人可見。為達(dá)到這個(gè)目標(biāo)，必不可少的就是認(rèn)證功能。下面我們一起來學(xué)習(xí)一下認(rèn)證機(jī)制。

一.　何為認(rèn)證

1.計(jì)算機(jī)本身無法判斷坐在顯示器前的使用者的身份。進(jìn)一步說，也無法確認(rèn)網(wǎng)絡(luò)的那頭究竟有誰。可見，為了弄清究竟是誰在訪問服務(wù)器，就得讓對(duì)方的客戶端自報(bào)家門。可是，就算正在訪問服務(wù)器的對(duì)方聲稱自己是ueno，身份是否屬實(shí)這點(diǎn)卻也無從談起。為確認(rèn) ueno 本人是否真的具有訪問系統(tǒng)的權(quán)限， 就需要核對(duì)“登錄者本人才知道的信息”、“登錄者本人才會(huì)有的信息”。

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

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

二.BASIC 認(rèn)證BASIC

認(rèn)證（基本認(rèn)證）是從 HTTP/1.0 就定義的認(rèn)證方式。即便是現(xiàn)在仍有一部分的網(wǎng)站會(huì)使用這種認(rèn)證方式。是 Web 服務(wù)器與通信客戶端之間進(jìn)行的認(rèn)證方式。

1.BASIC 認(rèn)證的認(rèn)證步驟

步驟 1： 當(dāng)請(qǐng)求的資源需要 BASIC 認(rèn)證時(shí)，服務(wù)器會(huì)隨狀態(tài)碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應(yīng)。 該字段內(nèi)包含認(rèn)證的方式（BASIC） 及 Request-URI 安全域字符串 （realm）。
步驟 2： 接收到狀態(tài)碼 401 的客戶端為了通過 BASIC 認(rèn)證，需要將用戶 ID 及密碼發(fā)送給服務(wù)器。發(fā)送的字符串內(nèi)容是由用戶 ID 和密碼構(gòu)成，兩者中間以冒號(hào)（:）連接后，再經(jīng)過 Base64 編碼處理。

假設(shè)用戶 ID 為 guest，密碼是 guest，連接起來就會(huì)形成 guest:guest 這樣的字符串。然后經(jīng)過 Base64 編碼，最后的結(jié)果即是 Z3Vlc3Q6Z3Vlc3Q=。把這串字符串寫入首部字段 Authorization 后，發(fā)送請(qǐng)求。
當(dāng)用戶代理為瀏覽器時(shí)，用戶僅需輸入用戶 ID 和密碼即可，之后，瀏覽器會(huì)自動(dòng)完成到 Base64 編碼的轉(zhuǎn)換工作。

步驟 3： 接收到包含首部字段 Authorization 請(qǐng)求的服務(wù)器，會(huì)對(duì)認(rèn)證信息的正確性進(jìn)行驗(yàn)證。如驗(yàn)證通過，則返回一條包含 Request-URI 資源的響應(yīng)。

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

三.　DIGEST 認(rèn)證

為彌補(bǔ) BASIC 認(rèn)證存在的弱點(diǎn)，從 HTTP/1.1 起就有了 DIGEST 認(rèn)證。 DIGEST 認(rèn)證同樣使用質(zhì)詢 / 響應(yīng)的方式 （challenge/response），但不會(huì)像 BASIC 認(rèn)證那樣直接發(fā)送明文密碼。

1.所謂質(zhì)詢響應(yīng)方式是指，一開始一方會(huì)先發(fā)送認(rèn)證要求給另一方，接著使用從另一方那接收到的質(zhì)詢碼計(jì)算生成響應(yīng)碼。最后將響應(yīng)碼返回給對(duì)方進(jìn)行認(rèn)證的方式。

因?yàn)榘l(fā)送給對(duì)方的只是響應(yīng)摘要及由質(zhì)詢碼產(chǎn)生的計(jì)算結(jié)果，所以比起 BASIC 認(rèn)證，密碼泄露的可能性就降低了。

DIGEST 認(rèn)證的認(rèn)證步驟:

步驟 1： 請(qǐng)求需認(rèn)證的資源時(shí)，服務(wù)器會(huì)隨著狀態(tài)碼 401 Authorization Required，返 回帶 WWW-Authenticate 首部字段的響應(yīng)。該字段內(nèi)包含質(zhì)問響應(yīng)方式認(rèn)證所需的臨時(shí)質(zhì)詢碼（隨機(jī)數(shù)，nonce）。首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個(gè)字段的信息。客戶端就是依靠向服務(wù)器回送這兩個(gè)值進(jìn)行認(rèn)證的。nonce 是一種每次隨返回的 401 響應(yīng)生成的任意隨機(jī)字符串。該字符串通常推薦由 Base64 編碼的十六進(jìn)制數(shù)的組成形式，但實(shí)際內(nèi)容 賴服務(wù)器的具體實(shí)現(xiàn)。

步驟 2： 接收到 401 狀態(tài)碼的客戶端，返回的響應(yīng)中包含 DIGEST 認(rèn)證必須的首部字段 Authorization 信息。 首部字段 Authorization 內(nèi)必須包含 username、realm、nonce、uri 和 response 的字段信息。其中，realm 和 nonce 就是之前從服務(wù)器接收到 的響應(yīng)中的字段。username 是 realm 限定范圍內(nèi)可進(jìn)行認(rèn)證的用戶名。 uri（digest-uri）即 Request-URI 的值，但考慮到經(jīng)代理轉(zhuǎn)發(fā)后 Request-URI 的值可能被修改，因此事先會(huì)復(fù)制一份副本保存在 uri 內(nèi)。response 也可叫做 Request-Digest，存放經(jīng)過 MD5 運(yùn)算后的密碼字符串，形成響應(yīng)碼。響應(yīng)中其他的實(shí)體請(qǐng)參見第 6 章的請(qǐng)求首部字段 Authorization。另外，有關(guān) Request-Digest 的計(jì)算規(guī)則較復(fù)雜，有興趣的讀者不妨深入 學(xué)習(xí)一下 RFC2617。

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

四.SSL 客戶端認(rèn)證

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

SSL 客戶端認(rèn)證的認(rèn)證步驟為達(dá)到 SSL 客戶端認(rèn)證的目的，需要事先將客戶端證書分發(fā)給客戶端，且客戶端必須安裝此證書。

步驟 1： 接收到需要認(rèn)證資源的請(qǐng)求，服務(wù)器會(huì)發(fā)送 Certificate Request 報(bào)文，要求客戶端提供客戶端證書。
步驟 2： 用戶選擇將發(fā)送的客戶端證書后，客戶端會(huì)把客戶端證書信息以 Client Certificate 報(bào)文方式發(fā)送給服務(wù)器。

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

步驟 3： 服務(wù)器驗(yàn)證客戶端證書驗(yàn)證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，然后開始 HTTPS 加密通信。

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

SSL 客戶端認(rèn)證必要的費(fèi)用使用 SSL 客戶端認(rèn)證需要用到客戶端證書。而客戶端證書需要支付一 定費(fèi)用才能使用。這里提到的費(fèi)用是指，從認(rèn)證機(jī)構(gòu)購(gòu)買客戶端證書的費(fèi)用，以及服務(wù) 器運(yùn)營(yíng)者為保證自己搭建的認(rèn)證機(jī)構(gòu)安全運(yùn)營(yíng)所產(chǎn)生的費(fèi)用。每個(gè)認(rèn)證機(jī)構(gòu)頒發(fā)客戶端證書的費(fèi)用不盡相同，平攤到一張證書上，一年費(fèi)用約幾萬至十幾萬日元。服務(wù)器運(yùn)營(yíng)者也可以自己搭建認(rèn)證機(jī)構(gòu)，但要維持安全運(yùn)行就會(huì)產(chǎn)生相應(yīng)的費(fèi)用。

五.基于表單認(rèn)證

基于表單的認(rèn)證方法并不是在 HTTP 協(xié)議中定義的。客戶端會(huì)向服務(wù)器上的 Web 應(yīng)用程序發(fā)送登錄信息（Credential），按登錄信息的驗(yàn)證結(jié)果認(rèn)證。根據(jù) Web 應(yīng)用程序的實(shí)際安裝，提供的用戶界面及認(rèn)證方式也各不相同。

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

認(rèn)證多半為基于表單認(rèn)證

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

Session 管理及 Cookie 應(yīng)用基于表單認(rèn)證的標(biāo)準(zhǔn)規(guī)范尚未有定論，一般會(huì)使用 Cookie 來管理 Session（會(huì)話）。基于表單認(rèn)證本身是通過服務(wù)器端的 Web 應(yīng)用，將客戶端發(fā)送過來 的用戶 ID 和密碼與之前登錄過的信息做匹配來進(jìn)行認(rèn)證的。但鑒于 HTTP 是無狀態(tài)協(xié)議，之前已認(rèn)證成功的用戶狀態(tài)無法通過協(xié)議層面保存下來。即，無法實(shí)現(xiàn)狀態(tài)管理，因此即使當(dāng)該用戶下一次繼續(xù)訪問，也無法區(qū)分他與其他的用戶。于是我們會(huì)使用 Cookie 來 管理 Session，以彌補(bǔ) HTTP 協(xié)議中不存在的狀態(tài)管理功能。

步驟 1： 客戶端把用戶 ID 和密碼等登錄信息放入報(bào)文的實(shí)體部分， 通常是以 POST 方法把請(qǐng)求發(fā)送給服務(wù)器。而這時(shí)，會(huì)使用 HTTPS 通信來進(jìn)行 HTML 表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送。
步驟 2： 服務(wù)器會(huì)發(fā)放用以識(shí)別用戶的 Session ID。通過驗(yàn)證從客戶端發(fā)送過來的登錄信息進(jìn)行身份認(rèn)證，然后把用戶的認(rèn)證狀態(tài)與 Session ID 綁定后記錄在服務(wù)器端。 向客戶端返回響應(yīng)時(shí)，會(huì)在首部字段 Set-Cookie 內(nèi)寫入 Session ID（如 PHPSESSID=028a8c…）。你可以把 Session ID 想象成一種用以區(qū)分不同用戶的等位號(hào)。然而，如果 Session ID 被第三方盜走，對(duì)方就可以偽裝成你的身份進(jìn)行惡意操作了。因此必須防止 Session ID 被盜，或被猜出。為了做到 這點(diǎn)，Session ID 應(yīng)使用難以推測(cè)的字符串，且服務(wù)器端也需要進(jìn)行 有效期的管理，保證其安全性。另外，為減輕跨站腳本攻擊（XSS）造成的損失，建議事先在 Cookie 內(nèi)加上 httponly 屬性。
步驟 3： 客戶端接收到從服務(wù)器端發(fā)來的 Session ID 后，會(huì)將其作為 Cookie 保存在本地。下次向服務(wù)器發(fā)送請(qǐng)求時(shí)，瀏覽器會(huì)自動(dòng)發(fā)送 Cookie，所以 Session ID 也隨之發(fā)送到服務(wù)器。服務(wù)器端可通過驗(yàn)證接收到的 Session ID 識(shí)別用戶和其認(rèn)證狀態(tài)。

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