常见的登录验证方式

1. http basic auth

每次请求API时都提供用户的username和password。

容易把帐号密码暴露给第三方客户端，在生产环境下被使用的愈来愈少。

1. Oauth

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

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

 

+--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

1. Cookies-session Auth

Cookie-session 认证机制就是为一次请求认证在服务端建立一个Session对象，同时在客户端的浏览器端建立了一个Cookie对象；经过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当咱们关闭浏览器的时候，cookie会被删除。但能够经过修改cookie 的expire time使cookie在必定时间内有效。Session 是存储在服务器端的，避免在客户端 Cookie 中存储敏感数据。Session 能够存储在 HTTP 服务器的内存中，也能够存在内存数据库（如redis）中。
可是这种基于cookie-session的认证使应用自己很可贵到扩展，随着不一样客户端用户的增长，独立的服务器已没法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来。

• Session :每一个用户通过咱们的应用认证以后，咱们的应用都要在服务端作一次记录，以方便用户下次请求的鉴别，一般而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
• 扩展性 :用户认证以后，服务端作认证记录，若是认证的记录被保存在内存中的话，这意味着用户下次请求还必需要请求在这台服务器上,这样才能拿到受权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
• CSRF :由于是基于cookie来进行用户识别的, cookie若是被截获，用户就会很容易受到跨站请求伪造的***.

1. Token Auth

基于token的鉴权机制相似于http协议也是无状态的，它不须要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不须要去考虑用户在哪一台服务器登陆了，这就为应用的扩展提供了便利。

流程：

• 用户使用用户名密码来请求服务器
• 服务器进行验证用户的信息
• 服务器经过验证发送给用户一个token
• 客户端存储token，并在每次请求时附送上这个token值
• 服务端验证token值，并返回数据

这个token必需要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，通常咱们在服务端这么作就能够了Access-Control-Allow-Origin。

Token Auth的优势

• 支持跨域访问
  Cookie是不容许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息经过HTTP头传输.
• 无状态(服务端可扩展行)
  Token机制在服务端不须要存储session信息，由于Token 自身包含了全部登陆用户的信息，只须要在客户端的cookie或本地介质存储状态信息.
• 更适用CDN:
  能够经过内容分发网络请求你服务端的全部资料（如：javascript，HTML,图片等），而你的服务端只要提供API便可.
• 去耦:
  不须要绑定到一个特定的身份验证方案。Token能够在任何地方生成，只要在你的API被调用的时候，你能够进行Token生成调用便可.
• 更适用于移动应用
  当你的客户端是一个原平生台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你须要经过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
• CSRF(跨站请求伪造Cross-site request forgery)
  由于再也不依赖于Cookie，因此你就不须要考虑对CSRF（跨站请求伪造）的防范。
• 性能:
  一次网络往返时间（经过数据库查询session信息）总比作一次HMACSHA256计算 的Token验证和解析要费时得多.
• 不须要为登陆页面作特殊处理:
  若是你使用Protractor 作功能测试的时候，再也不须要为登陆页面作特殊处理.
• 基于标准化
  你的API能够采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）

缺点�：

1. 存在泄露的风险。若是别人拿到你的 Token，在 Token过时以前，均可以以你的身份在别的地方登陆
2. 若是存在 Web Storage（指sessionStorage和localStorage）。因为Web Storage 能够被同源下的JavaScript直接获取到，这也就意味着网站下全部的JavaScript代码均可以获取到web Storage，这就给了XSS机会
3. 若是存在Cookie中。虽然存在Cookie可使用HttpOnly来防止XSS，可是使用 Cookie 却又引起了CSRF

对Token认证的五点认识

• 一个Token就是一些信息的集合；
• 在Token中包含足够多的信息，以便在后续请求中减小查询数据库的概率；
• 服务端须要对cookie和HTTP Authrorization Header进行Token信息的检查；
• 基于上一点，你能够用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；
• 由于token是被签名的，因此咱们能够认为一个能够解码认证经过的token是由咱们系统发放的，其中带的信息是合法有效的；

1. JWT

• 身份认证
  在这种场景下，一旦用户完成了登录，在接下来的每一个请求中包含JWT，能够用来验证用户身份以及对路由，服务和资源的访问权限进行验证。因为它的开销很是小，能够轻松的在不一样域名的系统中传递，全部目前在单点登陆（SSO）中比较普遍的使用了该技术。
• 信息交换
  在通讯的双方之间使用JWT对数据进行编码是一种很是安全的方式，因为它的信息是通过签名的，能够确保发送者发送的信息是没有通过伪造的。

1. SSO

SSO（Single Sign On）单点登陆。

指在多系统应用群中登陆一个系统，即可在其余全部系统中获得受权而无需再次登陆，包括单点登陆与单点注销两部分。

实现方式：

• 有一个公共缓存cache用来验证登陆
• cookie保存登陆信息

做者：DamaoShao著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。