HTTP 身份認證小結

序章

身份認證、身份驗證、英文的 Authentication 是一個概念。

即對 系統使用者 進行身份確認：1）是否是系統用戶？2）具備哪些系統資源的使用權？

這裏的 系統使用者 可以是 人，也可以是 設備。

 

使用場景（1）：

使用者 提供身份憑證，系統直接進行驗證。

比如，表單認證。

使用場景（2）：

使用者 訪問授權服務器，授權服務器提供 ACCESS TOKEN，使用者再通過 ACCESS TOKEN 去訪問資源服務器。

比如，第三方授權認證。

 

HTTP 身份認證 是指 基於HTTP協議 實現的認證。

 

HTTP 認證類型彙總

RFC的認證方式

參考文檔#1 介紹了下面的幾種，

1. Basic
2. Bearer
3. Digest
4. HOBA
5. Mutual
6. Negotiate / NTLM
7. VAPID
8. SCRAM

 

注，以上皆有 RFC文檔，見 參考文檔1 原文。

注，前面三個在工作中有接觸過。

 

RFC文檔 是什麼？

RFC documents contain technical specifications and organizational notes for the Internet.

RFCs produced by the IETF cover many aspects of computer networking. They describe the Internet's technical foundations, such as addressing, routing, and transport technologies.

https://www.ietf.org/standards/rfcs/

 

其它認證方式

1. HTTP SSL Client 認證
2. Cookie-Session 認證（表單認證）
3. OAuth 2.0
4. Token 認證
5. JWT 認證

 

更多安全認證

1. LDAP 認證
2. Kerberos
3. OpenID
4. SAML
5. 第三方授權
6. 生物特徵認證
   1. 語音識別（少）
   2. 指紋識別（常見）
   3. 人臉識別（常見）
7. 零信任（zero-trust）

 

涉及的RFC文檔

https://www.rfc-editor.org/rfc/rfcXXXX

替換 XXXX 爲 文檔編號 即可 訪問。

 

不同的認證技術有不同的使用場景，下面簡單介紹一些。

 

認證：Basic 

比較早的一種認證方式，在 RFC#2617、#7617 中有提到。

特點是，使用 Base64 編碼 賬號及密碼，安全強度低；擴展性、易用性也較差。

2023年發佈的系統已經極少使用。

 

用到 響應頭 WWW-Authenticate，請求頭 Authorization，其中的，type=Basic。

在 參考資料#1 中還提到了 代理認證 方式，其使用 響應頭 Proxy-Authenticate、請求頭 Proxy-Authorization。

 

認證：Digest

也是早期的一種認證方式，在 RFC#2617（Draft Standard） 介紹了，September 2015 在 RFC#7616（Proposed Standard） 中有進一步介紹。

從 HTTP/1.1 開始支持。

特別是，比上面的 Basic 認證 安全強度更高。使用 MD5（不建議使用了） 或 SHA-256 算法。

參考資料#2 中有 詳細的介紹。

 

用到 響應頭 WWW-Authenticate，請求頭 Authorization，其中的，type=Digest。

 

認證：Cookie-Session、表單、HTTPS

最常見的一種認證方式，用戶輸入通過 表單輸入身份憑據，再傳輸給後端進行校驗。

在沒有 HTTPS 保護的情況下，這種方式的安全性不會比 上面的 Digest 認證 更高——前後端對身份憑據自行進行加密處理。

因此，使用 HTTPS 來進行傳輸，安全性大大加強了。

在 參考資料#2 中提到，這叫做 雙因素認證（Two-factor authentication）——表單+HTTPS。

 

認證（不，只是授權框架）：OAuth 2.0

相關RFC文檔：

RFC#6749（October 2012）: The OAuth 2.0 Authorization Framework

RFC#6750（October 2012）: The OAuth 2.0 Authorization Framework: Bearer Token Usage

更多

這種 認證框架 中，存在4種角色：

1. 資源擁有者（RO，簡單理解爲 賬戶）
2. 客戶端（C）
3. 授權服務器（AS）
4. 資源服務器（RS）

認證流程 簡介如下：

1. 賬戶 給 客戶端 授權（grant）
2. 客戶端 使用授權去 授權服務器 獲取 access token
3. 客戶端 再使用 access token 去 資源服務器 獲取資源

賬戶 給客戶端授權的方式有 4種：

1. 授權碼模式（authorization code）
   1. 最完整、流程最嚴密
   2. 可以更新 access token
2. 簡化模式（implicit）
3. 密碼模式（resource owner password credentials）
   1. 向客戶端提供自己的用戶名和密碼：但是客戶端不得儲存密碼
   2. 對客戶端高度信任
   3. 可以更新 access token
4. 客戶端模式（client credentials）
   1. 客戶端以自己的名義進行認證

參考資料#4 有更詳細介紹。

 

獲取 ACCESS TOKEN 後傳遞給 RS 的方式：添加 Authentication 請求頭，Bearer 類型

Authorization: Bearer ACCESS_TOKEN

 

參考資料#5 對 OAuth 2.0 及 ACCESS TOKEN 有更仔細的介紹：

1. OAuth 2.0 只是一個 授權框架（Authorization Framework）——Authorization not Authentication。
2. 需要聯合 身份認證機制（Basic、Digest、表單等） 來實現。
3. 由於 OAuth 2.0 來做認證存在一些問題，於是，OIDC（OpenID Connect）誕生了。
4. OIDC：一套把用戶身份信息從 AS 傳遞給 C 的標準流程、方式。
5. 基於OIDC可以實現 SSO（單點登錄）、第三方登錄。
6. 3種把 ACCESS TOKEN 傳遞給 RS 的方式：Authentication 請求頭、表單請求頭、URI。
7. OAuth 2.0 沒有規定 ACCESS TOKEN 的內容——由 實現者 自定義。
8.  ACCESS TOKEN 類型：讀庫令牌（隨機字符串+數據存儲），自包含令牌（JWT等）。
9. 資源服務器校驗  ACCESS TOKEN 的方式：小型、大型 Web 應用或不同。
10. 客戶端C 撤銷  ACCESS TOKEN。
11. 授權服務器 AS 讓 已簽發的  ACCESS TOKEN 失效：處理 自包含令牌 時存在問題，需要設計。

 

參考資料#5 推薦了 下面 博主的若干文章，可以繼續細讀：

當前標籤：OAuth2

https://www.cnblogs.com/linianhui/tag/OAuth2/

 

OAuth 2.0 網站：

https://oauth.net/2/

 

認證（基於 OAuth 2.0）：OIDC

參考資料#6 摘要：

基於OAuth的用戶認證的標準：OpenId Connect

OpenID Connect是2014年初發布的開放標準，定義了一種基於OAuth2的可互操作的方式來來提供用戶身份認證。

OpenId Connect是直接建立在OAuth2之上的。

 

參考資料#7 摘要：

在OAuth2.0 協議基礎上增加了身份驗證層 （identity layer）。

作爲OAuth2.0的擴展，實現了Authentication（認證） 的流程。

根據用戶的 id_token 來驗證用戶，並 獲取用戶的基本信息。

id_token通常是JWT（Json Web Token），JWT有三部分組成，header，body，signature。

在OAuth2.0 的基礎上額外增加了 UserInfo 的 Endpoint。

id_token 作爲 訪問 UserInfo Endpoint的憑證 來獲取用戶的基本信息（profile，email，phone），並驗證用戶。

OpenID Connect流程主要涉及如下幾個步驟（見 參考資料#7 原文）。

 

特別說明，

OpenID Connect 不是 OpenID，但它從 SAML 和 OpenID 1.0/2.0 中做了大量借鑑。

 

OIDC 官網：

https://openid.net

Page: What is OpenID Connect

https://openid.net/developers/how-connect-works/

 

認證（不，只是 Token）：JWT

JWT（Json Web Token），JWT有三部分組成，header，body，signature，只是一個包含某種意義數據的JSON串，易於驗證、難於僞造。

最大好處是，讓 認證服務 和 校驗服務（資源服務器） 完全分開。

相關 RFC文檔：

RFC 7519（May 2015）：JSON Web Token (JWT)

RFC 7523：JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

 

RFC 7519 摘要：

Abstract

   JSON Web Token (JWT) is a compact, URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JSON object that is used as the payload of a JSON
   Web Signature (JWS) structure or as the plaintext of a JSON Web
   Encryption (JWE) structure, enabling the claims to be digitally
   signed or integrity protected with a Message Authentication Code
   (MAC) and/or encrypted.

翻譯：

JSON Web令牌（JWT）是一種緊湊的、url安全的方式，代表雙方之間轉移的索賠（representing claims）。

JWT中的聲明被編碼爲JSON對象，該對象用作JSON Web簽名（JWS）結構的有效負載或JSON Web加密（JWE）結構的明文，使聲明是數字的使用郵件身份驗證碼（MAC）和/或加密保護的簽名或完整性。

 

通過前面的介紹可以知曉，JWT 會用來作爲 OIDC 認證標準的 id_token 使用。

其實，JWT 是一個 單獨的標準，如果需要，也可以用在其它場景。

JWT 還可以用來解決 跨域身份驗證 問題，即，實現 單點登錄（SSO）。

 

小結

HTTPS 是 必須的。

在 HTTPS 的基礎上來實現各種 身份認證、授權。

Basic、Digest 是不推薦使用的。

一般使用 表單認證。

表單驗證的 身份憑據 可能包括：賬號名+密碼，郵箱+驗證碼，手機號+驗證碼 等。

身份認證的客戶端類型：Web瀏覽器、原生APP、微信小程序、其它。

只有 Web瀏覽器 一種客戶端類型時，可以不使用 OAuth 2.0 + OIDC + JWT。

獲取用戶的方式：

1）傳統的註冊、登錄（傳統的），2）第三方開放平臺的APP（比如，微信）掃碼註冊、授權、登錄（現代的）。

第2種方式的用戶體驗更好，也更容易獲取客戶，當然，前提是網站或應用提供了有價值的東西。

 

對於基於生物特徵的身份認證，還需要客戶端的 人工智能模型 支持，獲取特徵數據，然後，調用 自己或第三方API 進行驗證。

注意，需要遵守 相關生物特徵使用的法律，比如，GB/T 40660-2021信息安全技術：生物特徵識別信息保護基本要求。

 

對於其它身份認證（LDAP、SAML、CAS、Kerberos、零信任等），本文不再繼續探究了。

 

---END---

 

本文只是作者可觸及的 身份認證的小結，對於像 Web 3.0 的身份認證，本作者 是完全沒有概念的。

對於文中摘要的內容，如有侵權，請告知。

對於文中圖片，完全自創，特免費授權給全體地球人使用。

 

本文鏈接：

https://www.cnblogs.com/luo630/p/17648357.html

 

參考資料

1、HTTP 身份驗證

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Authentication

2、HTTP的三種身份認證：基本(Basic)認證、摘要(Digest)認證、基於表單(Form-Based)的SSL客戶端認證
huoxiaoqiang • 2021年12月7日 01:32 
https://www.huoxiaoqiang.com/experience/httpe/6451.html

3、HTTPS、SSL、TLS三者之間的聯繫和區別
天府雲創
於 2018-08-17 17:52:54 發佈
原文鏈接：https://blog.csdn.net/enweitech/article/details/81781405

4、理解OAuth 2.0
作者： 阮一峯
日期： 2014年5月12日
https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

--

作者的更多文章：

OAuth 2.0 的一個簡單解釋

https://www.ruanyifeng.com/blog/2019/04/oauth_design.html

OAuth 2.0 的四種方式

https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

5、詳解OAuth 2.0授權協議（Bearer token）
JaneJ2013
於 2020-04-20 15:13:51 發佈
原文鏈接：https://blog.csdn.net/u012324798/article/details/105612706

6、[認證 & 授權] 3. 基於OAuth2的認證（譯）
https://www.cnblogs.com/linianhui/p/authentication-based-on-oauth2.html
posted @ 2017-04-09 16:59 
作者：Timetombs

重點：OAuth2.0 不是認證協議。

7、OAuth2.0 詳解
作者：Dreamgoing
https://zhuanlan.zhihu.com/p/89020647

8、OpenID Connect 簡介
https://zhuanlan.zhihu.com/p/95064385

9、OAuth2 四種授權使用場景，圖文結合不能再清晰了
程序員黑哥
https://zhuanlan.zhihu.com/p/375154660

10、

 

ben 發佈於博客園

ben 發佈於博客園