认证机制

常见的认证机制

HTTP Basic Auth

HTTP Basic Auth 简单点说明就是每次请求 API 时都提供用户的 username 和 password ，简言之， Basic Auth 是配合

RESTful API 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的

风险，在生产环境下被使用的越来越少。因此，在开发对外开放的 RESTful API 时，尽量避免采用 HTTP Basic Auth

 

Cookie Auth

 

Cookie 认证机制就是为一次请求认证在服务端创建一个 Session 对象，同时在客户端的浏览器端创建了一个 Cookie

对象；通过客户端带上来 Cookie 对象来与服务器端的 session 对象匹配来实现状态管理的。默认的，当我们关闭浏

览器的时候， cookie 会被删除。但可以通过修改 cookie 的 expire time 使 cookie 在一定时间内有效

 

OAuth

 

OAuth （开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一 web 服务上存储的私密的资

源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。 OAuth 允许用户提供一个令牌，而

不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频

编辑网站 ) 在特定的时段（例如，接下来的 2 小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，

OAuth 让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容

 

这种基于 OAuth 的认证机制适用于个人消费者类的互联网产品，如社交类 APP 等应用，但是不太适合拥有自有认证

权限管理的企业应用。

 

Token Auth

 

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1. 客户端使用用户名跟密码请求登录

2. 服务端收到请求，去验证用户名与密码

3. 验证成功后，服务端会签发一个 Token ，再把这个 Token 发送给客户端

4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里

5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

6. 服务端收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据

 

 

Token Auth 的优点

支持跨域访问 : 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 (JWT). 这个标准已经存在多个后端库（ .NET, Ruby,

Java,Python, PHP ）和多家公司的支持（如： Firebase,Google, Microsoft ） .