HTTP提供了一套標准的身份驗證框架：服務器可以用來針對客戶端的請求發送質詢(challenge)，客戶端根據質詢提供身份驗證憑證。質詢與應答的工作流程如下：服務器端向客戶端返回401（Unauthorized，未授權）狀態碼，並在WWW-Authenticate頭中添加如何進行驗證的信息，其中至少包含有一種質詢方式。然后客戶端可以在請求中添加Authorization頭進行驗證，其Value為身份驗證的憑證信息。
在HTTP標准驗證方案中，我們比較熟悉的是"Basic"和"Digest"，前者將用戶名密碼使用BASE64編碼后作為驗證憑證，后者是Basic的升級版，更加安全，因為Basic是明文傳輸密碼信息，而Digest是加密后傳輸。在前文介紹的Cookie認證屬於Form認證，並不屬於HTTP標准驗證。
Bearer驗證：
Bearer驗證也屬於HTTP協議標准驗證，它隨着OAuth協議而流行
Bearer驗證中的憑證稱為BEARER_TOKEN，或者是access_token，它的頒發和驗證完全由我們自己的應用程序來控制，而不依賴於系統和Web服務器，Bearer驗證的標准請求方式如下：
Authorization: Bearer [BEARER_TOKEN]
Bearer認證的核心便是BEARER_TOKEN，而最流行的Token編碼方式便是：JSON WEB TOKEN。
Json web token (JWT), 特別適用於分布式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
Basic基礎認證：
客戶端請求需要帶Authorization請求頭，值為“Basic xxx”，xxx為“用戶名:密碼”進行Base64編碼后生成的值。 若客戶端是瀏覽器，則瀏覽器會提供一個輸入用戶名和密碼的對話框，用戶輸入用戶名和密碼后，瀏覽器會保存用戶名和密碼，用於構造Authorization值。當關閉瀏覽器后，用戶名和密碼將不再保存。
用戶名/密碼經過Base64加碼后，這個Base64碼值可以輕易被解碼並獲得用戶名/密碼，所以此認證方式並不安全。為了傳輸安全，需要配合SSL使用。
Digest摘要認證：
Digest認證步驟如下：
第一步：客戶端訪問Http資源服務器。由於需要Digest認證，服務器返回了兩個重要字段nonce（隨機數）和realm。
第二步： 客戶端構造Authorization請求頭，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是第一步返回的值。nouce只能被服務端使用一次。uri(digest-uri)即Request-URI的值，但考慮到經代理轉發后Request-URI的值可能被修改、因此實現會復制一份副本保存在uri內。response也可叫做Request-digest，存放經過MD5運算后的密碼字符串，形成響應碼。
第三步：服務器驗證包含Authorization值的請求，若驗證通過則可訪問資源。
Digest認證可以防止密碼泄露和請求重放，但沒辦法防假冒。所以安全級別較低。
Digest和Basic認證一樣，每次都會發送Authorization請求頭，也就相當於重新構造此值。所以兩者易用性都較差。
SSL Client認證：
SSL認證安全級別較高，但需要承擔證書費用。SSL認證過程中涉及到一些重要的概念，數字證書機構的公鑰、證書的私鑰和公鑰、非對稱算法（配合證書的私鑰和公鑰使用）、對稱密鑰、對稱算法（配合對稱密鑰使用）。
大致的認證步驟如下：
第一步：客戶端請求服務資源，服務器要求客戶端出示數字證書。
第二步：客戶端發送數字證書
第三步：服務器通過數字證書機構的公鑰驗證數字證書的合法性，驗證通過后取出證書的公鑰。
第四步：服務端隨機生成一個隨機數即為對稱密鑰，並使用非對稱算法和證書公鑰加密。這個加密后的字符串，只有發送的客戶端能解。
第五步：客服端使用非對稱解密算法和證書私鑰獲取服務端發送的對稱密鑰。后續客戶端和服務端的請求直接基於對稱算法和對稱密鑰。由於只有客戶端和服務端有對稱密鑰，所以后續發送的請求較安全。
SSL可以防泄漏、假冒、重放，所以在Web系統中得到了廣泛的應用。
SSL客戶端認證在實際中用得不多，因為一來需要在客戶端中安裝證書（升級麻煩）、二來需要承擔證書費用。
HTTP 表單認證：
基於表單的認證方式並不存在於HTTP規范。所以實現方式也呈現多樣化。表單認證一般都會配合cookie+sessiond的使用，現在絕大多數的Web站點都是使用此認證方式。用戶在登錄頁中填寫用戶名和密碼，服務端認證通過后會將sessionId返回給瀏覽器端，瀏覽器會保存sessionId到瀏覽器的Cookie中。因為Http是無狀態的，所以瀏覽器使用Cookie來保存sessionId。下次客戶端發送的請求中會包含sessionId值，服務端發現sessionId存在並認證過則會提供資源訪問。
openID Connect：用於第三方登錄認證