看看有哪些 Web 认证技术.

BASIC 认证

BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。

BASIC 认证会将“用户名:密码”经过 Base64 加密后放入请求头部的 Authorization 字段用于服务端校验，因为采用的是 Base64 加密，密码被盗用的风险极高，另外一般的浏览器也无法实现认证注销操作。

若在网站中使用 BASIC 认证，最好加上 SSL 认证（即开启 HTTPS），否则无法保障密码传输的安全。

DIGEST 认证

为弥补 BASIC 认证存在的弱点，HTTP/1.1 起就有了 DIGEST 认证。DIGEST 认证会将用户密码经过 MD5 加密后传输给服务端，降低了密码被盗用的风险，但是仍然没有解决用户伪装的问题。

步骤2中 response 也可叫做 Request-Digest，存放经过 MD5 运算后的密码字符串，形成响应码。

无论是 BASIC 认证还是 DIGEST 认证，他们都达不到多数 Web 网站对高度安全等级的追求标准。

SSL 客户端认证

SSL客户端认证是借由 HTTPS 的客户端证书完成认证的方式，凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。认证过程可以参见这篇文章。

大多数情况下，SSL 客户端认证是与其他认证方式组合使用的，很明显，SSL 客户端认证只能证明请求是来自于安全的客户端，并没法证明请求是来自于安全的用户。

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 也可直接被用于认证，也可被加密。

表单认证

基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务器上的 Web 应用程序发送登录信息（Credential），登录信息的验证结果认证。

表单认证不具备共同标准规范，在每个 Web 网站上都会有各不相同的实现方式，一般会使用 Cookie + Session 的方式管理会话。

表单认证因为需要自主实现，如果全面考虑过安全性能问题，就能够具备高度的安全等级。但在表单认证的实现中存在问题的 Web 网站也是屡见不鲜。

OAuth2 + OpenID

OAuth 与 OpenID 可以归类为第三方认证方式，即对该用户的认证通过非本服务进行认证。

OAuth 是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。目前，OAuth 的最新版本为 2.0。

OAuth 强调授权（authorization），举个例子带大家了解 OAuth 授权过程。大家都用过微信授权吧？首先，客户端会请求用户是否允许微信授权，用户允许后，微信端会返回 code 信息；然后，服务端使用 code 信息授权登录微信平台，登录成功后会返回用户认证信息 access_token；最后，服务端再拿着 access_token 信息获取到用户相关的资源。大致过程如下所示。

那 OpenID 又是什么呢？OpenID 强调认证（authentication），试想一下，客户端请求微信授权的时候，如果用户未登录微信或者没有微信账户呢？是不是就要跳到微信登录页面？而这就是 OpenID 做的事，OpenID 仅仅做一个用户认证的功能，不能拿到用户的任何信息，用户的信息都安全的存储在 OpenID 服务器上（你可以自己建立一个 OpenID 服务网站，也可以选择一个可信任的 OpenID 服务网站来完成注册）。

OpenID 往往在不同服务之间单点登录的时候较为常用。

JMCui