Web认证_介绍Web开发中几种常用的认证机制

如今web服务随处可见，成千上万的web程序被部署到公网上供用户访问，有些系统只针对指定用户开放，属于安全级别较高的web应用，他们需要有一种认证机制以保护系统资源的安全，本文将探讨五种常用的认证机制及优缺点。  

 

HTTP基本认证（HTTP Basic Auth） 

在HTTP中，HTTP基本认证是一种允许Web浏览器或者其他客户端在请求时提供用户名和口令形式的身份凭证的一种登录验证方式。 

简单而言，HTTP基本认证就是我们平时在网站中最常用的通过用户名和密码登录来认证的机制。 

优点:

HTTP 基本认证是基本上所有流行的网页浏览器都支持。但是基本认证很少在可公开访问的互联网网站上使用，有时候会在小的私有系统中使用。

缺点:

HTTP 基本认证虽然足够简单，但是前提是在客户端和服务器主机之间的连接足够安全。如果没有使用SSL/TLS这样的传输层安全的协议，那么以明文传输的密钥和口令很容易被拦截。 由于现存的浏览器保存认证信息直到标签页或浏览器关闭，或者用户清除历史记录。导致了服务器端无法主动来当前用户登出或者认证失效。

 

OAuth（开放授权）

OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容
下面是OAuth2.0的流程：

（1）客户端（Client）向资源拥有者（Resource Owner）发送授权请求（Authorization Request） 
（2）资源拥有者授权许可（Authorization Grant） 
（3）客户端向验证服务器（Authorization Server）发送通过（2）获取的授权许可 
（4）验证服务器验证授权许可，通过的话，则返回Access Token给客户端 
（5）客户端通过Access Token 访问资源服务器（Resource Server） 
（6）资源服务器返回受保护的资源（Protected Resource）

这种基于OAuth的认证机制适用于个人消费者类的互联网产品，如社交类APP、豆瓣、微信js-SDK等应用，但是不太适合拥有自有认证权限管理的企业应用；

 

Cookie/Session

Cookie 是由客户端保存的小型文本文件，其内容为一系列的键值对。Cookie 是由 HTTP 服务器设置的，保存在浏览器中。Cookie会随着 HTTP请求一起发送。 

Session 是存储在服务器端的，避免在客户端 Cookie 中存储敏感数据。Session 可以存储在 HTTP 服务器的内存中，也可以存在内存数据库（如redis）中。   

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

 

Token认证

基于 Token的认证机制，有着无需长期保存用户名和密码，服务器端能主动让token失效等诸多好处，非常实用于 Web 应用和 App 已经被很多大型网站采用，比如Facebook、Github、Google+等。

其流程如下：   

1. 客户端使用用户名和密码请求登录
2. 服务端收到请求，去验证用户名与密码 
3. 验证成功后，服务器会签发一个 Token， 再把这个 Token 发送给客户端 
4. 客户端收到 Token 以后可以把它存储起来，如Cookie或者Web Storage 
5. 客户单每次向服务端请求资源的时候，都需要带着服务器端签发的 Token  
6. 服务器端收到请求，验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据；否的话，则返回对应的错误信息。

字由https://www.wode007.com/sites/73248.html 中国字体设计网https://www.wode007.com/sites/73245.html

Token认证的优点：

• 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
• 无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
• 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：JavaScript，html,图片等），而你的服务端只要提供API即可.
• 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
• 更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
• CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
• 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
• 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
• 基于标准化:你的API可以采用标准化的 jsON Web

 

但是存储在客户端的 Token 存在几个问题： 

 1. 存在泄露的风险。如果别人拿到你的 Token，在 Token过期之前，都可以以你的身份在别的地方登录 
 2. 如果存在 Web Storage（指sessionStorage和localStorage）。由于Web Storage 可以被同源下的JavaScript直接获取到，这也就意味着网站下所有的JavaScript代码都可以获取到web Storage，这就给了XSS机会 
 3. 如果存在Cookie中。虽然存在Cookie可以使用HttpOnly来防止XSS，但是使用 Cookie 却又引发了CSRF 

 

对于泄露的风险，可以采取对Token进行对称加密，用时再解密。 对于XSS而言，在处理数据时，都应该 escape and encode 所有不信任的数据。 与CSRF相比，XSS更加容易防范和意识到，因此并不建议将Token存在Cookie中。 

最后，网站或者应用一定要使用HTTPS。毕竟在网络层面上 Token 明文传输的话，还是非常的危险。