web应用认证概述

1 常见的认证方式

1.1 Http Basic Auth

每次请求都提供用户的用户名和密码。简单说 Basic Auth是配合Restful API 使用的最简单的认证方式，只需提供用户名密码即可，但是存在把用户名暴露给第三方客户端的风险，再生产环境中避免使用。

1.2 Cookie Auth

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

• 某些移动端可能不存在cookie（比如微信小程序）
• cookie存在跨域问题（在微服务之间端口不一样，或存在跨域问题。）

1.3 OAuth

OAuth（开放授权）是一个开放的授权标准，允许第三方应用访问在某一web服务器上存储的私密资源，而无需将用户名和密码提供给第三方软件。OAuth允许用户提供一个令牌，每一个令牌授权一个特定的第三方系统，通过这个令牌访问存在特定服务器上的资源。

1.4 Token Auth

Http Basic Auth的演化版本，每次请求服务端带上token标志，后台服务校验这个token是否合法，从而决定客户端是否可以访问后台资源。无状态
基于Token Auth的好处

• 支持跨域访问：cookie不允许跨域访问，token不存在这个问题。一般将token信息设置在http请求头里
• 无状态，服务端可自行扩展，token机制在服务端不需要存储session，因而无需解决session共享问题。
• 更适合用CDN：跨域通过内容分发网络请求你服务端的所有资料，你的服务端只需要提供API即可
• 去耦：不需要绑定一个特定的身份认证方案
• 更适合原生应用：当你的客户端是一个原生平台（IOS,Android，Window8），cookie不被支持，你需要通过cookie容器解决
• CSRF： 因为不在依赖cookie，所以不需要考虑跨站请求伪造问题。
• 可以做到标准化，例如jwt（json web token）

2 有状态服务和无状态服务

2.1 有状态服务

有状态服务：服务端会存储请求上下文相关的数据，先后的请求可能是有关联的。例如，传统web应用中，使用session维护已登录用户的数据。客户端（浏览器）存储jsession数据，在提交请求后，找到次jsessionid 对应的session数据。虽然http是无状态的，但是借助session可以使http服务装换为有状态的。

2.2 无状态服务

无状态服务：本次请求不依赖于之前的请求，本次请求的数据全部包含在该次请求中。例如，基于token的验证方式，不需要sesession维持会话数据。