Web应用中基于密码的身份认证机制

  • 背景概念
    • 认证（Authentication）
    • 会话管理
  • 1 表单认证（Form-Based Authentication）
    • 1.1 介绍
    • 1.2 流程
  • 2 通用的 HTTP 认证框架（HTTP Authentication framework）
    • 2.1 介绍
    • 2.2 流程
    • 2.3 保护空间（realm）
    • 2.4 会话管理
  • 3 HTTP基本认证 （HTTP Basic Authentication）
    • 3.1 介绍
    • 3.2 流程
  • 4 HTTP摘要认证 （HTTP Digest Authentication）
    • 4.1 介绍
    • 4.2 流程
    • 4.3 客户端计算加密哈希值的规则
  • 5 HTTP相互认证（HTTP Mutual Authentication）
    • 5.1 介绍
    • 5.2 流程
  • 参考文档

背景概念

认证（Authentication）

认证是指应用软件（身份信息使用方）通过采用某种方法来确认当前请求的用户是谁。基于密码的认证过程可以细分为三步：
（1）认证服务器（身份信息提供方）从客户端获取用户账密。
（2）认证服务器将拿到的账密与数据库中保存的账密进行比较，确认正确后，生成用户身份信息。
（3）使用方从提供方处获取用户身份信息。

  • 当提供方与使用方能够共享数据库，不必跨网络和安全边界进行交互时，两个角色就合并了，完成前两步就能确认当前请求的用户是谁，所以只需考虑一个问题：【Q1】按照什么流程、格式能够安全可靠地把用户账密从客户端传递给认证服务器。
  • 当提供方与使用方独立部署，必须跨网络和安全边界进行交互时，三步都完成后使用方才能确认当前请求的用户是谁，因此除了【Q1】之外，还有一个问题需要考虑：【Q2】按照什么流程、格式能够安全可靠地把用户身份信息从提供方传递给使用方。

所有能让使用方确认当前用户是谁的方法都可以统称为认证机制，应用软件根据其部署情况、所处角色、面临的问题来具体选择。

  • 【Q1】的解决方案为：表单认证、HTTP Basic认证、HTTP Digest认证、HTTP Mutual认证。这些就是Web应用中常见的基于密码的身份认证机制。
  • 【Q2】的解决方案为：OIDC、SAML 、WS-Federation、Windows AD。这些统称为联合身份认证机制（Federated Authentication），通常用于实现SSO、第三方登录。

详解基于OIDC实现单点登录SSO、第三方登录
详解OAuth 2.0授权协议（Bearer token）

会话管理

会话管理：又称会话控制，是指应用软件通过采用某种方法来开启和结束会话，即实现登录和登出。

保护资源是需要确认用户是谁及其权限才能操作的资源。应用软件通过认证机制来确认当前请求的用户是谁。但是用户显然不愿意每操作一个资源（URI）都提供一次账密，而是希望只提供一次账密，应用软件能够在一段时间内记住自己是谁，在这段时间内操作保护资源时，应用软件不要再向自己索要账密。为此，应用软件需要实现，在用户第一次提供账密并验证正确后，记住已经验证过他的账密了（设置标志），以及他是谁（颁发凭证，其中保存了用户id或用户名）。之后，用户再要求操作保护资源时，应用软件通过标志得知无需再向用户索要账密，通过凭证解析出用户是谁，从而同意其操作保护资源。当用户告知应用软件不要再记住自己是谁时，应用软件删除标志和凭证。此后，当用户要求操作保护资源时，应用软件会找不到标志和凭证，将要求用户提供账密。

传递并验证用户账密的过程称为认证，设置标志和颁发凭证的过程称为登录，删除标志和凭证的过程称为登出，在登录到登出这段期间内的一系列请求称为会话。登录标志、登录凭证、用户id、用户名称、会话到期时间等信息属于会话状态。

通常，应用软件会在认证通过的同时设置登录标志、颁发登录凭证。因此，上述4个概念之间往往存在以下联系：

  • 认证通过 = 登录成功 = 开启会话
  • 用户主动登出 = 结束会话 = 需重新认证
  • 会话到期 = 用户被动登出 = 需重新认证

通常，在登录前、登出后、会话到期后这三个需要认证的时间段内，网络上传递的是账密；其余时间，网络上传递的是登录凭证。

会话管理机制解决的是以下两个问题：

  • 客户端和服务器，谁负责保存会话状态？
  • 双方之间通过什么方式传递登录凭证？

实操中常见的会话管理机制分为4类：基于session、基于cookie、基于token、基于认证。

1 表单认证（Form-Based Authentication）

1.1 介绍

客户端通过请求体送表单的方式向服务器传递账密，通常与基于cookie或基于session的会话管理机制一起使用。注意：表单认证【不是】HTTP规定的标准认证机制。

优点：

  • 允许开发人员定制登录页面和错误页面。
  • 开发简单，易于实现。

缺点：

  • 以纯文本形式发送密码，容易被网络嗅探，必须结合HTTPS使用。
  • 未验证目标服务器的身份，容易被网络钓鱼。

1.2 流程


1、客户端请求访问受保护的资源（目标URI：GET localhost/resource）。
2、目标URI收到请求后，将检查用户是否登录（是否携带了指定cookie，校验cookie值）。如果用户未登录，则返回303，通过浏览器将客户端重定向到登录页面（GET localhost/login.html）。
3、用户在登录页面的表单中输入账密，提交表单时调用验证账密接口（POST localhost/user_pass/verify），请求体传参为用户名、加密密码、目标URI。
4、验证账密接口（POST localhost/user_pass/verify）校验收到的传参：
（1）如果账密正确，则颁发登录凭证（设置指定cookie），返回303，通过浏览器将客户端重定向到目标URI。
（2）如果账密错误，则返回303，通过浏览器将客户端重定向到错误页面。
5、目标URI收到请求后，发现用户已登录，则检查用户权限：
（1）如果有权限，则返回保护资源作为响应。
（2）如果权限不足，则重定向到无权访问页面。

2 通用的 HTTP 认证框架（HTTP Authentication framework）

2.1 介绍

标准文件：【RFC 7235】Hypertext Transfer Protocol (HTTP/1.1): Authentication

中文总结版

RFC 7235 定义了一个通用的【质询-回答】式的 HTTP 认证框架，Basic、Digest、Mutual认证都基于此框架。基于此框架的认证机制就是HTTP规定的标准认证机制。

2.2 流程

1、客户端请求访问受保护的资源（目标URI）。
2、目标URI收到请求后，检查请求头是否包含Authorization字段。如果不包含，则服务器将发起质询，即返回401 Unauthorized响应，响应头带有WWW-Authenticate字段，在该字段中指定认证机制并提供认证所需参数。
3、客户端收到401的质询响应，要求用户提供账密。按照认证机制的规则把账密编码成一个字符串，放在请求头Authorization字段中，重新请求目标URI，将账密提交给服务器。
4、目标URI再次收到请求后，发现请求头包含Authorization字段，则校验账密。
（1）如果账密正确，则返回保护资源作为响应。
（2）如果账密错误，则重复步骤2，即返回401质询响应，响应头带有WWW-Authenticate字段。

2.3 保护空间（realm）

RFC 7235 定义了一个realm参数，Basic、Digest、Mutual认证都使用了此参数。其参数值是服务器设置的用于标识保护空间的字符串，即保护空间名称。服务器可以将所有保护资源（URI）划分成多个组，对每组资源采用不同的认证机制和不同的密码，一组URI就称为一个保护空间。对客户端来说，保护空间指明了一个自动应用账密的范围，即在请求哪些URI时可以自动增加Authorization字段来发送已缓存的用户账密，它的作用类似于cookie技术中的domain、path这两个参数（用于让服务器指示客户端在什么范围内自动发送已缓存的cookie）。

例如：一组realm="a_space"的资源（URI）都不涉及敏感数据，采用Basic认证。而另一组realm="b_space"的资源（URI）涉及支付信息等敏感数据，采用Mutual认证，并要求用户单独设置密码。当客户端请求GET http://example.com/movie时，服务器返回401质询响应，其中参数realm="a_space"。客户端将{host=http://example.com, path=/movie, realm="a_space", auth-scheme="Basic"}这些键值对作为一条数据保存在本地。用户认证通过后，客户端在这条数据里加上账密。当客户端请求GET http://example.com/book时，服务器返回401质询响应，其中参数realm="a_space"。客户端发现同一保护空间（host、realm、auth-scheme相同）已经保存过用户账密了，于是直接将账密按照认证机制规则编码，自动放到Authorization字段中发给服务器，从而无需用户再次输入密码。

2.4 会话管理

RFC 7235 没有规定怎么进行会话管理，但是它明确规定了 HTTP 认证框架被设计为无状态的（statless）：对请求进行身份验证所需的所有信息都必须在请求中提供，而不依赖于服务器记住之前的请求。因此，采用此框架的Basic、Digest、Mutual认证机制也都是无状态的。

考虑到无状态这一要求，Basic、Digest、Mutual认证适合与基于认证的会话管理机制结合使用，非常符合REST架构风格。

3 HTTP基本认证 （HTTP Basic Authentication）

3.1 介绍

标准文件： 【RFC 7617】The ‘Basic’ HTTP Authentication Scheme
优点：

  • 浏览器原生支持。
  • 开发简单，易于实现。

缺点：

  • 以纯文本形式发送密码，容易被网络嗅探，必须结合HTTPS使用。
  • 未验证目标服务器的身份，容易被网络钓鱼。

3.2 流程


1、客户端请求访问受保护的资源（目标URI：GET localhost/resource）。

2、目标URI收到请求后，检查请求头是否包含Authorization字段。如果不包含，则服务器将发起质询，即返回401 Unauthorized响应，响应头带有WWW-Authenticate字段，指定认证机制为Basic并提供认证所需参数。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="example_space_name"

参数：

  • Basic：表明认证方式为HTTP基本认证。
  • realm：保护空间标识名称，告知客户端自动应用账密的范围，是 HTTP 认证框架（RFC 7235）定义的参数。

3、客户端收到401的质询响应，要求用户提供账密。客户端按照Basic的规定格式（username:password）对账密进行base64编码，放在请求头Authorization字段中，重新请求目标URI，将账密提交给服务器。

GET /resource HTTP/1.1
Host: localhost
Authorization: Basic cUZFeFZtQlE4blBZOjVjNWVkYjA2OTA2MTZjZGJkNGNmOWMwYjBlMjg3MWVkNjM2MzE2ZTliNjI1NWQzMDA2MDg3NGJm

4、目标URI再次收到请求后，根据realm="example_space_name"这一保护空间采用的认证机制来校验收到的账密。
（1）如果账密正确，则检查用户权限。如果用户有权限，则返回保护资源作为响应。如果没有权限，则返回403 Forbidden作为响应。
（2）如果账密错误，则重复步骤2，即返回401 Unauthorized响应，带有响应头WWW-Authenticate: Basic realm="example_space_name"。

注意：Basic认证可以跳过质询的步骤，即客户端在已知采用Basic认证、realm、用户账密的情况下，可以在第一次访问目标URI时就携带请求头Authorization Basic cUZFeFZtQlE4blBZOjVj...，从而一步得到保护资源。

4 HTTP摘要认证 （HTTP Digest Authentication）

4.1 介绍

标准文件：【RFC 7616】HTTP Digest Access Authentication
优点：

  • 通过散列算法来向网络嗅探器隐藏原始用户密码。
  • 浏览器原生支持。
  • 许多框架内置了实现，易于开发。

缺点：

  • 难以抵御数量巨大的离线密码字典攻击，应结合HTTPS使用。
  • 未验证目标服务器的身份，容易被网络钓鱼。

4.2 流程

与Basic认证流程大体相同，区别在于：
1、服务端发起质询（即步骤2中返回401 Unauthorized）的响应头WWW-Authenticate字段的参数不同，Digest认证需要提供更多参数：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digestrealm="example_space_name",qop="auth, auth-int",algorithm=SHA-256,nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

参数

  • Digest：表明认证方式为HTTP摘要认证。
  • realm：保护空间标识名称，告知客户端自动应用账密的范围，是 HTTP 认证框架（RFC 7235）定义的参数。
  • domain：可选参数，参数值为空格分隔的域名列表，用于告知客户端自动应用账密的跨域范围，缺省时表示不能跨域应用账密。
  • qop：列出服务端支持的加密等级，auth表示只对账密哈希， auth-int表示完整加密，即对账密和请求体内容都哈希。
  • algorithm：指定需采用哪种算法计算单向加密哈希，常见算法为SHA-256，SHA-256-sess，MD5，MD5-sess等。
  • nonce：短期有效或一次性有效的不透明字符串，哈希内容必须包含此值，用于防止重演攻击（Replay Attack）。
  • opaque：不透明字符串，客户端只需原样传回给服务器。如果认证只涉及一个服务器，opaque值可以随便设置，如果认证涉及多个服务器，opaque值可设置为需要在多个服务器之间传递的会话状态。

2、客户端收到401的质询响应，要求用户提供账密。客户端根据Digest的规则对账密进行编码，放在请求头Authorization字段中，重新请求目标URI：

GET /resource HTTP/1.1
Host: localhost
Authorization: Digest realm="example_space_name",algorithm=SHA-256,nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS",qop=auth,username="jane",uri="/resource",nc=00000001,cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",response="753927fa0e85d155564e2e272a28d1802ca10daf4496794697cf8db5856cb6c1",

参数：

  • realm、algorithm、nonce 、opaque原样回传即可。
  • qop：说明客户端选择的加密等级。
  • username：用户输入的账号。
  • uri：目标URI，包含在哈希内容中。由于HTTP允许代理，所以客户端需通过此参数说明计算哈希时包含的目标URI具体是什么。
  • nc：nonce的计数。 说明客户端使用此 nonce 值发送的请求数量（包括当前请求），采用十六进制计数。 例如，在第一次使用此 nonce 值发送请求时，nc=00000001。 服务器会维护自己的计数副本来检测重演攻击（同一个 nc 值被看到两次）。
  • cnonce：客户端提供的短期有效或一次性有效的不透明字符串，用于避免选择明文攻击（chosen plaintext attacks），并提供一些消息完整性保护。
  • response：客户端计算出的加密哈希值。

4.3 客户端计算加密哈希值的规则

规则：response = H(A1):nonce:nc:cnonce:qop:H(A2)

  • 如果服务器指定的算法不带-sess后缀，例如algorithm=SHA-256，则：A1 = username:realm:passwd
例如：A1 = jane:example_space_name:123456
  • 如果服务器指定的算法带‘-sess’后缀，例如algorithm=SHA-256-sess，则：A1 = H(username:realm:passwd):nonce:cnonce
  • 如果客户端选择的加密等级为qop=auth，则：A2 = Method:request-uri
例如：A2 = GET:/resource
  • 如果客户端选择的加密等级为qop=auth-int，则：A2 = Method:request-uri:H(entity-body)
    其中，Method为本请求的HTTP方法（GET），request-uri为参数uri的值，H(entity-body)请求体内容的哈希。

注意：Digest认证无法跳过质询的步骤，客户端必须先从401质询响应中获得nonce值才能计算哈希。

5 HTTP相互认证（HTTP Mutual Authentication）

5.1 介绍

标准文件：【RFC 8120】Mutual Authentication Protocol for HTTP
优点：

  • 在通信中根本不交换密码信息，避免了任何密码在网络传输中泄露的可能性，离线密码字典攻击无效。
  • 能够检测通信对方是否为伪造服务器，避免被网络钓鱼。

缺点：

  • 浏览器尚未原生支持
  • 框架尚未内置，只能开发人员自己实现。

5.2 流程


1、客户端请求访问受保护的资源（目标URI：GET localhost/resource）。

2、目标URL收到请求后，检查请求头是否包含Authorization字段，如果不包含，则服务器将发起质询，返回401-INIT消息（即参数reason=initial的401 Unauthorized响应），响应头带有WWW-Authenticate字段，指定认证机制为Mutual并提供认证所需参数。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Mutualrealm="example_space_name",version=1,algorithm=SHA-256,validation=http://localhost:8000,auth-scope=localhost,reason=initial

参数

  • Mutual：表明认证方式为HTTP相互认证。
  • realm：保护空间标识名称，告知客户端自动应用账密的范围，是 HTTP 认证框架（RFC 7235）定义的参数。
  • version：表明服务器采用的相互认证协议的版本，用于避免未来版本不兼容的问题，目前只有一个版本，其值固定为1。
  • algorithm：指定采用哪种算法计算kc1、ks1、vkc、vks，协议目前支持4种算法：iso-kam3-dl-2048-sha256、iso-kam3-dl-4096-sha512、iso-kam3-ec-p256-sha256、iso-kam3-ec-p521-sha512，算法详情定义在RFC 8121。
  • validation：表明与服务器绑定的底层协议验证机制，客户端可以利用此机制来初步检查通信对方，以防止恶意服务器通过转发客户端凭据而向真实服务器冒充用户。当服务器底层是HTTP时，只能采用 host 验证机制，即参数值的格式为<scheme>://<host>:<port>，表明通过判断这三部分是否与真实服务器一致来检查通信对方。当服务器底层是HTTPS时，可以选择 tls-server-end-point 验证机制，即参数值为服务器TLS公钥证书散列值的八位字符串；或者选择 tls-unique 验证机制，即参数值为通道绑定材料。
  • auth-scope：告知客户端自动应用会话秘钥的跨域范围。Single-server type：参数值的格式为<scheme>://<host>:<port>，例如：http://localhost:8000，表明scheme、host、port三个部分都相同时才自动应用会话秘钥，即不能跨域应用。Single-host type（缺省默认），参数值的格式为<host>，例如：localhost，表明只要host部分相同就可以跨域应用会话秘钥。Wildcard-domain type，参数值的格式为 *.example.com，表明只要一级域名相同就可以跨域应用会话秘钥。
  • reason：描述返回401的原因，initial表示请求中头没有包含Authorization字段。

3、客户端可以利用参数validation提供的方法来初步检查通信对方：
（1）如果检查不通过，说明通信对方是恶意服务器，则停止通信，并提示用户。这样一来，恶意服务器将无法拿到客户端凭据，从而无法能向真实服务器冒充用户。
（2）如果检查通过，则要求用户输入账密，然后发送一条密钥交换消息（req-KEX-C1）来启动身份验证。即在请求头Authorization字段中通过Mutual关键词传递user、kc1（客户端的密钥交换值）等参数，重新请求目标URL：

GET /resource HTTP/1.1
Host: localhost
Authorization: Mutualrealm="example_space_name",version=1,algorithm=SHA-256,validation=host,auth-scope=localhost,user="jane",kc1="4e2e272a28d1802ca10daf4496794697cf"

参数：

  • version：表明客户端采用的相互认证协议的版本，其值固定为1。
  • algorithm、validation、auth-scope、realm：服务器传参值。
  • user：用户名。
  • kc1：客户端采用指定算法计算的密钥交换值。

4、服务器收到req-KEX-C1消息，在其用户数据库中查找用户在realm="example_space_name"这一保护空间设置的账密，用于计算服务器的密钥交换值（ks1）。然后，服务器创建一个会话标识符（sid），用于标识紧随其后的消息集。最后，返回401-KEX-S1消息，即返回401 Unauthorized，在响应头WWW-Authenticate字段中通过Mutual关键词传递sid、ks1等参数。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Mutualrealm="example_space_name",version=1,algorithm=SHA-256,validation=host,auth-scope=localhost,reason=initialsid="4563806698",ks1="daf4496794697cf8db5856cb6c1",nc-max=400,nc-window=128,time=60

参数：

  • algorithm、validation、auth-scope、realm：客户端传参值。
  • sid：服务器生成的会话标识符，是一个随机整数。sid应该具有至少80 bits的唯一性，或最大并发会话数量估计值的平方，以较大者为准。
  • ks1：服务器采用指定算法计算的密钥交换值。
  • nc-max：服务器能接受的nc（后续由客户端提供的参数）的最大值。
  • nc-window：服务器能接受的nc（后续由客户端提供的参数）最大差值窗口。协议建议设为128或更大。
  • time：建议客户端在此时间内重用本响应的sid（单位为秒）。协议建议至少设为60（秒）。注意，服务器并不需要保证本响应的sid所标识的会话在此时间内一定是可用的。
  • path：可选参数，该值是一个用空格分隔的uri列表。用于告知客户端，如果认证通过，客户端可以对哪些路径自动应用本次认证生成的会话秘钥。

5、客户端、服务器各自使用密钥交换消息中的交换值计算会话秘钥。只有当双方使用相同的用户密码进行计算时，会话秘钥值才会相同。以后双方在每个请求\响应中都携带此会话秘钥，用于代替账密在网络中传递。

6、客户端发送req-VFY-C请求，即在请求头Authorization字段中通过Mutual关键词传递sid、vkc（客户端计算的会话秘钥值）等参数，重新请求目标URI。

GET /resource HTTP/1.1
Host: localhost
Authorization: Mutualrealm="example_space_name",version=1,algorithm=SHA-256,validation=host,auth-scope=localhost,user="jane",vkc="wE4q74E6zIJEtWaHKaf5wv/H5Q"

参数：

  • algorithm、validation、auth-scope、realm：服务器传参值。
  • sid：服务器传参值。如果客户端此前从服务器接收过sid值，可以在相同realm的所有sid值中选择一个重用。
  • nc：sid请求的编号值，用于让服务器检测重演攻击。客户端对使用此 sid 值发送的每个请求都设置一个唯一编号，一般为从0开始的递增整数。由于可能存在后发的请求（nc=300）比先发的请求（nc=280）早到达服务器的情况，服务器通过参数nc-window指定一个能接受的最大差值窗口（nc-window=128）。当nc=300的请求先达到时，服务器能接受的最小nc值为300-128=172，从而当nc=280的请求后到达时，服务器将正常响应。但是如果此时服务器收到了nc=150的请求，将视为可疑的攻击请求。当服务器对同一个sid检测到重复的nc值、或超出nc-window窗口范围的nc值时，将丢弃此sid标识的会话并返回401-STALE消息（参数reason=stale-session的401响应，stale-session表示请求中提供的sid要么服务器不认识，要么已过期），即告知户端需重新认证（从步骤3开始重来一遍）。
  • vkc：客户端采用指定算法计算的会话秘钥值。

7、服务器收到req-VFY-C请求，比较vkc是否与自己计算的会话秘钥值（vks）相同。
（1）如果相同，表明对客户端身份和用户身份认证通过，则返回200-VFY-S消息，即返回保护资源作为响应，并在响应头的Authentication-Info字段中通过Mutual关键词传递vks等参数。

HTTP/1.1 200 OK
Authentication-Info: Mutualversion=1,sid="4563806698",vks1="wE4q74E6zIJEtWaHKaf5wv/H5Q"# response body

参数：

  • sid：客户端传参值。
  • vks1：服务器采用指定算法计算的会话秘钥值。

（2）如果不同，表明用户可能输错了密码，或客户端可能是冒牌的，或用户可能是冒牌的，则服务器返回401-INIT消息，与步骤2中的响应基本相同，区别是参数reason=auth-failed：表示身份验证失败。

8、客户端收到200-VFY-S消息，比较服务器返回的vks是否与自己的vkc相同。
（1）如果相同，表明对服务器身份认证通过，则可以使用其返回的保护资源。
（2）如果不同，表明服务器是冒牌的，或面临中间人攻击，则不使用其返回的响应，并提示用户。

注意：
（1）客户端在已知采用Mutual认证和用户账密的情况下，可以跳过步骤1、2，直接发送req-KEX-C1消息。
（2）在客户端和服务器已经共享了一个与有效sid关联的会话密钥的情况下，可以跳过步骤3、4，直接使用现有的sid和相应的会话密钥发送req-VFY-C消息。
（3）如果sid标识的会话过期了，客户端和服务器应该自动重新建立另一个会话而不通知用户。
更新过期会话的流程如下：

参考文档

  1. 【RFC 7235】Hypertext Transfer Protocol (HTTP/1.1): Authentication
  2. 【RFC 7617】The ‘Basic’ HTTP Authentication Scheme
  3. 【RFC 7616】HTTP Digest Access Authentication
  4. 【RFC 8120】Mutual Authentication Protocol for HTTP
  5. 【RFC 8121】Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
  6. HTTP 身份验证框架
  7. (HTTP) Authentication Scheme Registry
  8. Java EE 6 : Specifying an Authentication Mechanism
  9. Web应用中4类登录会话管理机制（基于session、基于cookie、基于token、基于认证）
  10. 基于OIDC实现单点登录SSO、第三方登录
  11. OAuth 2.0授权协议（Bearer token）

Web应用中基于密码的身份认证机制（表单认证、HTTP认证： Basic、Digest、Mutual）相关推荐

  1. 基于Token的WEB后台登录认证机制（并讲解其他认证机制以及cookie和session机制）

    几种常用的认证机制 HTTP Basic Auth HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password,简言之,Basic Auth是配合RES ...

  2. Web设计中的中国传统色彩速查表

    转自:http://css9.net/chinese-traditional-color-in-web-desig/  觉得很全,分享一下,以下为作者iiduce所言"诗词中有:" ...

  3. 群智感知应用中基于区块链的激励机制

    主要内容: 解决问题概括: 群智感知应用利用无处不在的移动用户的智能终端采集大规模感知数据,感知任务的高效执行 依赖于高技能用户的参与,这些用户应被给予相应的报酬来弥补其在执行感知任务中的资源消耗．现 ...

  4. 基于jQuery会员中心安全修改表单代码

    基于jQuery会员中心安全修改表单代码.这是一款登录密码,交易密码,手机号码,实名认证,电子邮箱,安全设置表单,会员表单等设置代码.效果图如下: 在线预览    源码下载 实现的代码. html代码 ...

  5. 密码与确认密码自动验证html,html表单验证确认密码

    编写HTML注册表单,,javascript表单验证 编写HTML注册表单,,需要字段:用户名,密码,确认密码,邮件,确认邮件,性汗....阁下语气可以舒缓一些吗? 我们抽出自己的时间来帮助别人,不是 ...

  6. 一款基于jquery ui的动画提交表单

    今天要给大家分享一款基于jquery ui的动画提交表单.这款提交表单的的效果是以动画的形式依次列表所需填写的信息.效果非常不错,效果图如下: 在线预览   源码下载 实现的代码. html代码: & ...

  7. 基于springboot+vue的开源自定义表单问卷系统

    一.项目简介 基于springboot+vue的开源自定义表单问卷系统 二.实现功能 支持表单拖拽 支持各种控件操作(基础组件.进阶组件等) 基础组件包含文本.多行文本.图片.图形.日历控件 支持拖拽 ...

  8. Flask中基于Token的身份认证

    目录 下面是基于Token的身份认证的具体实现步骤 下面是一个基于Token的身份认证的示例代码 客户端请求示例 Flask提供了多种身份认证方式,其中基于Token的身份认证是其中一种常用方式.基于 ...

  9. html5表单密码验证及提示,HTML5表单及其验证(示例代码)

    1.输入型控件 Input type 用途 说明 email 电子邮件地址文本框 url 网页URL文本框 number 数值的输入域 属性 值 描述 max number 规定允许的最大值 min ...

最新文章

  1. 如果当前没有拿得出手的简历，也别慌，努力的话最多两年情况就能改变
  2. Python input()
  3. 120xa正反转参数_RFID的软件SOPAS参数设置
  4. 在git的Bash下进行复制粘贴
  5. java程序设计自考_java程序设计自考试题
  6. 开滦二中2021高考成绩查询,2021年唐山查询中考成绩
  7. Python使用OpenCV二值化
  8. 去除新安装火狐浏览器黑色背景
  9. 【wangeditor富文本编辑器v4版自定义功能】格式刷
  10. Learning Transferable Features with Deep Adaptation Networks
  11. 成功解决 zsh: command not found
  12. python微信发红包看照片_微信发原图会泄露位置信息？用Python教你通过图片获取用户信息！...
  13. CrystalDiskInfo硬盘检测工具 标准版及萌妹版
  14. 研发管理心得，从技术小白做到CTO(研发总监)的辛酸之路
  15. 研究生学习初入门之导师大致方向
  16. python实现电话号码映射
  17. 压缩包文件设置了加密怎么解密
  18. 使用FEST-Swing测试GUI
  19. web自动化--python+selenium自动化
  20. android ios 垃圾回收,iOS 面试题（16）：解释垃圾回收的原理

热门文章

  1. 用Python批量下载视频
  2. swing重写右上角叉号
  3. 一、自定义一个竖直Layout
  4. 变量之间的相关性研究
  5. 根据域名展示对应备案号内容的共用站点默认页面index.html
  6. 一次性刻录光盘内容(刻录完成后不能再编辑光盘中内容)
  7. 【2022最新】mac版本Chrome谷歌浏览器导入burpsuite证书
  8. 春秋战国时期灭了三个国家的陈国女人
  9. 计算机游戏英文文献,JAVA游戏英文文献翻译
  10. 外卖小程序源码+后台_外卖cps外卖优惠券 赚钱小程序源码