1. 定義

基于表單的認(rèn)證方法并不是在HTTP協(xié)議中定義的。客戶端會向服務(wù)器上的Web應(yīng)用程序發(fā)送登錄信息（ Credential )，按登錄信息的驗證結(jié)果認(rèn)證。

根據(jù)Web應(yīng)用程序的實際安裝,提供的用戶界面及認(rèn)證方式也各不相同。
eg. 基于表單認(rèn)證示例（Google )

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

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

由于使用上的便利性及安全性問題，HTTP協(xié)議標(biāo)準(zhǔn)提供的BASIC認(rèn)證和 DIGEST認(rèn)證幾乎不怎么使用。另外，SSL客戶端認(rèn)證雖然具有高度的安全等級，由于導(dǎo)入及費用問題，還尚未普及。

對于Web 網(wǎng)站的認(rèn)證功能，能夠滿足其安全使用級別的標(biāo)準(zhǔn)規(guī)范并不存在，所以只好使用由Web應(yīng)用程序各自實現(xiàn)基于表單的認(rèn)證方式。不具備共同標(biāo)準(zhǔn)規(guī)范的表單認(rèn)證，在每個Web 網(wǎng)站上都會有各不相同的實現(xiàn)方式。

3. Session管理及Cookie狀態(tài)管理

基于表單認(rèn)證本身是通過服務(wù)器端的Web應(yīng)用，將客戶端發(fā)送過來的用戶ID和密碼與之前登錄過的信息做匹配來進行認(rèn)證的。
鑒于HTTP是無狀態(tài)協(xié)議，之前已認(rèn)證成功的用戶狀態(tài)無法通過協(xié)議層面保存下來。即，無法實現(xiàn)狀態(tài)管理，因此即使當(dāng)該用戶下一次繼續(xù)訪問，也無法區(qū)分他與其他的用戶。于是我們會使用Cookie來管理Session來彌補狀態(tài)管理功能。

step1. 客戶端把用戶ID和密碼等登錄信息放入報文的實體部分

通常是以 POST方法把請求發(fā)送給服務(wù)器。而這時，會使用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送。

step2. 服務(wù)器會發(fā)放用以識別用戶的Session ID。

通過驗證從客戶端發(fā)送過來的登錄信息進行身份認(rèn)證，然后把用戶的認(rèn)證狀態(tài)與Session ID綁定后記錄在服務(wù)器端。向客戶端返回響應(yīng)時,會在首部字段Set-Cookie P寫入Session ID (如 PHPSESSID=028a8c…)。

• 把Session ID想象成一種用以區(qū)分的等位號。
• 如果 Session ID被第三方盜走，對方就可以偽裝你的身份進行惡意操作了。
• 必須防止 Session ID被盜。為了做到這點，Session ID應(yīng)使用難以推測的字符串，且服務(wù)器端也需要進行有效期的管理，保證其安全性。

另外，為減輕跨站腳本攻擊（ XSS)造成的損失，建議事先在Cookie內(nèi)加上 httponly 屬性。

step3:客戶端接收到從服務(wù)器端發(fā)來的 Session lID后，會將其作為Cookie保存在本地。下次向服務(wù)器發(fā)送請水的，瀏覽器會自動發(fā)送Cookie，所以 Session ID也隨之發(fā)送到服務(wù)器。服務(wù)器端可通過驗證接收到的 Session ID識別用戶和其認(rèn)證狀態(tài)。

• 不僅基于表單認(rèn)證的登錄信息及其認(rèn)證過程都無標(biāo)準(zhǔn)化的方法，服務(wù)器端應(yīng)如何保存用戶提交的密碼等登錄信息也沒有標(biāo)準(zhǔn)化。
• 通常情況下，一種安全的保存方法是：先利用密碼加鹽（Salt）的方式增加額外信息，再使用散列（Hash）函數(shù)計算出散列值后保存。

總結(jié)

以上是生活随笔為你收集整理的(chap8 确认访问用户身份的认证) 基于表单认证的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。