5.2 Web常见5种认证方式

由于Web的开放性，越来越多的企业将服务架设到网络上，对于Web的认证最常见的有以下5种认证方式：HTTP Basic Auth、OAuth2、Cookie-Session Auth、Token Auth和JWT。

5.2.1 HTTP Basic Auth

HTTP Basic Auth是一种最古老的安全认证方式，这种方式就是在用户访问网站/API时，需要使用访问的用户名和密码，由于此种方式容易泄露信息，所以现在使用得越来越少了。若想使用此种方式至少采用双因素认证，除了用户名与密码，还需要使用一个类似动态的手机验证码才能验证通过。

5.2.2 OAuth2

开放授权（Open Authorization，OAuth）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源，而无需将用户名和密码提供给第三方。比如，通过QQ、微信和微博等登录第三方平台。OAuth1.0版本发布后有许多安全漏洞，所以在OAuth2.0（以下简写为OAuth2）中完全废止了OAuth1.0，OAuth2关注客户端开发的简易性，要么通过组织在资源拥有者和HTTP服务商之间被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。

OAuth2认证和授权的过程中有这3个角色。

● 服务提供方：提供受保护的服务和资源，用户在此存有数据。

● 用户：在服务提供方存储数据（照片、资料等）的人。

● 客户端：服务调用方，它要访问服务提供方的资源，需要在服务提供方进行注册。

OAuth2认证和授权的过程如下。

1）用户想操作存放在服务提供方的资源。

2）用户登录客户端，客户端向服务提供方请求一个临时Token（令牌）。

3）服务提供方验证客户端的身份后，给它一个临时Token。

4）客户端获得临时Token后，将用户引导至服务提供方的授权页面，并请求用户授权。（在这个过程中会将临时Token和客户端的回调链接/接口发送给服务提供方，服务提供方在用户认证并授权后会回来调用这个接口）。

5）用户输入用户名和密码登录，登录成功后，可以授权客户端访问服务提供方的资源。

6）授权成功后，服务提供方将用户引导至客户端的网页（调用第4步中的回调链接/接口）。

7）客户端根据临时Token从服务提供方获取正式的Access Token（访问令牌）。

8）服务提供方根据临时Token及用户的授权情况授予客户端Access Token。

9）客户端使用Access Token访问用户存放在服务提供方的受保护的资源。

5.2.3 Cookie-Session Auth

Cookie-Session认证机制就是为一次请求认证在服务器端创建一个Session对象，同时在客户端的浏览器端创建一个Cookie对象，通过客户端的Cookie对象与服务器端的Session对象匹配来实现状态管理。默认的，当用户关闭浏览器时，Cookie会被删除。但可以通过修改Cookie的过期时间使Cookie在一定时间内有效。

基于Session认证所显露的问题如下。

1）Session增多会增加服务器开销。每个用户经过系统的应用认证后，系统的应用都要在服务器端做一次记录，以方便用户下次请求的鉴别，通常Session都保存在内存中，随着认证用户的增多，服务器端的开销会明显增大。

2）分布式或多服务器环境中适应性不好。用户认证后，服务器端做认证记录，如果认证的记录被保存在内存中，这意味着用户下次请求必须在同一台服务器上，这样才能获取授权的资源。在分布式的应用上，这种方式相应地限制了负载均衡器的能力，即限制了应用的扩展能力。不过，现在某些服务器可以通过设置粘性Session来做到每台服务器之间的Session共享。

3）容易遭到跨站请求仿造攻击。基于Cookie来进行用户识别，如果Cookie被截获，用户就会很容易受到跨站请求伪造的攻击。

5.2.4 Token Auth

基于Token的鉴权机制类似于HTTP协议，是无状态的，它不需要在服务器端保留用户的认证信息或会话信息。这就意味着基于Token认证机制的应用不需要去考虑用户在哪一台服务器登录，这就为应用的扩展提供了便利。

基于Token的认证流程如下。

1）用户使用用户名和密码来请求服务器。

2）服务器验证用户的信息。

3）服务器通过验证发送给用户一个Token。

4）客户端存储Token值，并在每次请求时附送这个Token值。

5）服务器端验证Token值，并返回数据。

Token Auth的优点如下。

● 支持跨域访问：Cookie是不允许垮域访问的，Token机制支持跨域访问，前提是用户认证信息通过HTTP头传输。

● 无状态（也称服务器端可扩展行）：Token机制在服务器端不需要存储Session信息，因为Token自身包含了所有登录用户的信息，只需要在客户端的Cookie或本地介质存储状态信息。

● 更适用的内容分发网络（Content Delivery Network，CDN）：可以通过内容分发网络请求服务器端的所有资料（如JavaScript、HTML和图片等），而服务器端只需提供API即可。

● 去耦：不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在API被调用时，Token可以生成调用即可。

● 更适用于移动应用：当客户端是一个原生平台（iOS、Android和Windows 8等）时，Cookie是不被支持的，此时采用Token认证机制会简单得多。

5.2.5 JWT

JWT（JSON Web Token）作为一个开放的标准（RFC 7519），定义了一种简洁、自包含的方法，用于通信双方之间以JSON对象的形式安全地传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用密钥相关的哈希运算消息认证码（Hash-based Message Authentlcation Code，HMAC）算法或RSA的公私秘钥对进行签名。

JWT身份认证的特点如下。

● 简洁性：可以通过URL、POST参数或在HTTP header发送，因为数据量小，传输速度很快。

● 自包含性：负载中包含了所有用户所需要的信息，避免了多次查询数据库。

下列场景中使用JWT是很有用的。

● 授权（Authorization）：这是使用JWT最常见的场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，它的开销很小，可以轻松地跨域使用。

● 信息交换（Information Exchange）：对于安全地在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWT可以被签名，例如，用公钥/私钥对可以确定发送者的身份。另外，由于签名是使用头和有效负载计算的，还可以验证内容有没有被篡改。