常见认证方式的区别与联系
认证方式
认证机制解决的问题是，确定访问资源的用户是谁；权限机制解决的问题是，确定用户是否被许可使用、修改、删除或创建资源。权限机制通常与服务的业务逻辑绑定，因此权限机制需要在每个系统内部定制，而认证机制基本上是通用的，常用的认证机制包括 session auth(即通过用户名密码登录)，basic auth，token auth 和 OAuth，服务开发中常用的认证机制为后三者。
常见认证方式
- HTTP Basic auth
- Session auth
- Token auth
- OAuth（开放授权）
HTTP Basic auth
在 HTTP 1.0 提出，客户端请求某个资源后，服务器会发送一个 401（未授权）的响应，在响应中带了 Realm 信息表示使用 Basic 认证。 浏览器接收到这个响应后会弹出一个框，输入用户名和密码。点取消表示取消认证，点确定会提交用户名、密码到服务器。 提交的方式是在 HTTP 头中加入：WWW-Authorization:Basic XXXXXXX，Basic 后面是用户名、密码的BASE64编码。
只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。一般 Basic Auth 只在开发环境中使用。因此，在开发对外开放的 API 时，尽量避免采用 Basic Auth。
Basic 认证方式是一种无状态的认证方式，就是不需要服务器端保存必要的 session，所以也没有 session 失效期。客户端每次都需要将密码和用户名发送给服务器来完成认证，而且用户名和密码是保存在浏览器进程的内存中的，也就是只有当浏览器关闭的时候，用户名和密码也随之删除，才表示这次服务和认证结束，下一次请求需要重新输入用户名和密码。
Session auth
依赖于Cookie，有同域限制。
Token
与 Basic Auth 的区别是，不将用户名和密码发送给服务器做用户认证，而是向服务器发送一个事先在服务器端生成的 token 来做认证。因此 Token Auth 要求服务器端要具备一套完整的 Token 创建和管理机制，该机制的实现会增加大量且非必须的服务器端开发工作。
现在常用的管理方式是通过 redis 进行管理。
标准化方案：JSON Web Token (JWT)。
OAuth
OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一 web 服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth 允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth 让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。
正是由于 OAUTH 的严谨性和安全性，现在 OAUTH 已成为 RESTful 架构风格中最常用的认证机制，和 RESTful 架构风格一起，成为企业级服务的标配。
目前 OAuth 已经从 OAuth1.0 发展到 OAuth2.0，但这二者并非平滑过渡升级，OAuth2.0 在保证安全性的前提下大大减少了客户端开发的复杂性，建议在实战应用中采用 OAuth2.0 认证机制。