一、常见的认证机制
常见的认证机制
1 HTTP Basic Auth
HTTP Basic Auth 简单点说明就是每次请求 API 时提供用户的 username 和 password，简而言之，Basic Auth 是配合 RESTful API 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的 RESULTful API 时，尽量避免采用 HTTP Basic Auth。
2 Cookie Auth
Cookie 认证机制就是为了一次请求认证在服务器端创建一个 Session 对象，同时在客户端的浏览器端创建一个 Cookie 对象；通过客户端带来的 Cookie 对象来与服务器端的 Session 对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie 会被删除。但可以通过修改 cookie 的 expire time 使 cookie 在一定时间内有效。
弊端：
1：对于移动端，某些手机不存在 cookie，无法做认证；
2：如果服务器端设置多个（微服务），当请求第一个服务器的时候有 cookie，而到了其他服务器，涉及到跨域的话，携带的信息就不一致了。
3 OAuth
OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一 web 服务器上存储的私密资源（如照片、视频、联系人列表等），而无需将用户名和密码提供给第三方应用。OAuth 允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每个令牌授权一个特定的第三方系统（例如，视频编辑网站）在特定的时段（例如，接下来的 2 小时内）内访问特定资源（例如仅仅是某一相册中的视频）。这样，OAuth 让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。
举例：我们经常看到在某些网站某些应用中，有 QQ、微信、微博登录的窗口，在第三方应用中访问 QQ、微信和微博，其实这是典型的 OAuth 认证。简单的图形说明如下：
这种 OAuth 的认证机制适用于个人消费者类的互联网产品，如社交类 APP 等应用，但是不太实用拥有自有认证权限管理的企业应用。
4 Token Auth
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程如下：
- 客户端使用用户名和密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里
- 客户端每次向服务端请求资源时需要携带服务端签发的 Token
- 服务端收到请求后，去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
优点：
- 支持跨域访问：Cookie 是不允许跨域访问的，这一点对 Token 机制是不存在的，前提是传输的用户认证信息通过 HTTP 头传输。
- 无状态（也称：服务端可扩展行）：Token 机制在服务端不需要村粗 Session 信息，因为 Token 自身包含了所有登录用户的信息，只需要在客户端的 cookie 或本地介质存储状态信息。
- 更适合 CDN：可以通过内容分发网络请求你服务端的所有资源（如：javascript，HTML，图片等），而你的服务端只需提供 API 即可。
- 去耦：不需要绑定到一个特定的身份验证方案。Token 可以在任何地方生成，只需在你的 API 被调用的时候，你可以进行 Token 生成调用即可。
- 更适合用于移动应用：当你的客户端是一个原生平台（IOS，Android，Window 8 等）时，Cookie 是不会被支持的（你需要通过 Cookie 容器进行处理），这时采用 Token 认证机制就会简单得多。
- CSRF：因为不再以来于 Cookie，所以你就不需要考虑对 CSRF（跨站请求伪造）的防范。
- 性能：一次网络往返时间（通过数据库查询 session 信息）总比做一次 HMACSHA256 计算的 Token 验证和解析要消耗的时间多。
- 不需要为登录页面做特殊处理：如果你使用 Protractor 做功能测试的时候，不再需要为登录页面做特殊处理。
- 基于标准化：你的 API 可以采用标准化的 JSON Web Token（JWT）。这个标准已经存在多个后端库（.NET，Ruby，Java，Python，PHP）和多家公司支持（如：Google，Microsoft，Firebase）