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 发布于博客园