用户登录以及SSO

基于 Cookie/Session 的认证方案

Cookie的工作原理

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。

Cookie指的就是在浏览器里面存储的一种数据，仅仅是浏览器实现的一种数据存储功能。Cookie的保存时间，可以自己在程序中设置。如果没有设置保存时间，应该是一关闭浏览器，Cookie就自动消失。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

注意：

• Cookie功能需要浏览器的支持。如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。不同的浏览器采用不同的方式保存Cookie。IE浏览器会以文本文件形式保存，一个文本文件保存一个Cookie。
• Cookie的不可跨域名性。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。

  Session

  Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。

客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。

session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。

对于浏览器客户端，大家都默认采用 cookie 的方式，保存这个“身份标识”。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安。

可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

提示：
Session的使用比Cookie方便，但是过多的Session存储在服务器内存中，会对服务器造成压力。

Cookie与Session的区别和联系

1. Cookie数据存放在客户的浏览器上，Session数据放在服务器上；
2. Cookie不是很安全，别人可以分析存放在本地的COOKIE并进行 COOKIE欺骗，考虑到安全应当使用Session；
3. Session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE；
4. 单个Cookie在客户端的限制是4K，就是说一个站点在客户端存放的COOKIE不能超过3K；

Cookie和Session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的，上面我讲到服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie，因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用。

认证流程

• 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
• 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
• 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
• 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

使用 cookie 时需要考虑的问题

• 因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
• 不要存储敏感数据，比如用户密码，账户余额
• 使用 httpOnly 在一定程度上提高安全性
• 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
• 设置正确的 domain 和 path，减少数据传输
• cookie 无法跨域
• 一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie

• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

  使用 session 时需要考虑的问题

• 将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session

• 当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
• 当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
• sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？ 一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现

• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

  分布式架构下 session 共享方案

  1. session 复制

  任何一个服务器上的 session 发生改变（增删改），该节点会把这个 session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 session ，以此来保证 session 同步

• 优点： 可容错，各个服务器间 session 能够实时响应。

• 缺点： 会对网络负荷造成一定压力，如果 session 量大的话可能会造成网络堵塞，拖慢服务器性能。

  2. 粘性 session /IP 绑定策略

  采用 Ngnix 中的 ip_hash 机制，将某个 ip的所有请求都定向到同一台服务器上，即将用户与服务器绑定。 用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 session 机制

• 优点： 简单，不需要对 session 做任何处理。

• 缺点： 缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 session 信息都将失效。
• 适用场景： 发生故障对客户产生的影响较小；服务器发生故障是低概率事件

• 实现方式： 以 Nginx 为例，在 upstream 模块配置 ip_hash 属性即可实现粘性 session

  3. session 共享（常用）

• 使用分布式缓存方案比如 Memcached 、Redis 来缓存 session，但是要求 Memcached 或 Redis 必须是集群

• 把 session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：
  • 实现了 session 共享；
  • 可以水平扩展（增加 Redis 服务器）；
  • 服务器重启 session 不丢失（不过也要注意 session 在 Redis 中的刷新/失效机制）；
  • 不仅可以跨服务器 session 共享，甚至可以跨平台（例如网页端和 APP 端）

4. session 持久化

将 session 存储到数据库中，保证 session 的持久化

• 优点： 服务器出现问题，session 不会丢失
• 缺点： 如果网站的访问量很大，把 session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

只要关闭浏览器 ，session 真的就消失了？
不对。对 session 来说，除非程序通知服务器删除一个 session，否则服务器会一直保留，程序一般都是在用户做 log off 的时候发个指令去删除 session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分 session 机制都使用会话 cookie 来保存 session id，而关闭浏览器后这个 session id 就消失了，再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie 被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求头，把原来的 session id 发送给服务器，则再次打开浏览器仍然能够打开原来的 session。恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为 session 设置了一个失效时间，当距离客户端上一次使用 session 的时间超过这个失效时间时，服务器就认为客户端已经停止了活动，才会把 session 删除以节省存储空间。

基于token的认证方式

在大多数使用Web API的互联网公司中，Token 是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证

1. 无状态、可扩展
2. 支持移动设备
3. 跨程序调用
4. 安全

   Token的起源

   在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。

• 基于服务器的验证

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

• 基于服务器验证方式暴露的一些问题

1. Session：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
2. 可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
3. CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
4. CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器中。
这种概念解决了在服务端存储信息时的许多问题。NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）

基于Token的身份验证的过程如下:

1. 前端使用用户名跟密码请求首次登录
2. 后服务端收到请求，去验证用户名与密码是否正确
3. 验证成功后，服务端会根据用户id、用户名、定义好的秘钥、过期时间生成一个 Token，再把这个 Token 发送给前端
4. 前端收到 返回的Token ，把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 前端每次路由跳转，判断 localStroage 有无 token ，没有则跳转到登录页。有则请求获取用户信息，改变登录状态；

6. 前端每次向服务端请求资源的时候需要在请求头里携带服务端签发的Token

7. 服务端收到请求，然后去验证前端请求里面带着的 Token。没有或者 token 过期，返回401。如果验证成功，【解密，认证签名，查询数据库获取用户信息】就向前端返回请求的数据。

8. 前端得到 401 状态码，重定向到登录页面。

• 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
• 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

• token 完全由应用管理，所以它可以避开同源策略

  Token的优势

• 无状态、可扩展

在客户端存储的Token是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。tokens自己hold住了用户的验证信息。

• 安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。

• 可扩展性

Tokens能够创建与其它程序共享权限的程序。

• 多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Refresh Token

我们先看两个例子。
一个例子是登录密码，一般要求定期改变密码，以防止泄漏，所以密码是有有效期的；
另一个例子是安全证书。SSL 安全证书都有有效期，目的是为了解决吊销的问题。
所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token 都需要设有效期。

• 那么有效期多长合适呢？

  只能说，根据系统的安全需要，尽可能的短，但也不能短得离谱

• 然后新问题产生了，如果用户在正常操作的过程中，Token 过期失效了，要求用户重新登录……用户体验岂不是很糟糕？

一种方案，使用 Refresh Token，它可以避免频繁的读写操作。这种方案中，服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新Token 继续使用。

这种方案中，服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。

• 时序图表示

使用 Token 和 Refresh Token 的时序图如下：
1）登录

2）业务请求

3）Token过期，刷新 Token

上面的时序图中并未提到 Refresh Token 过期怎么办。不过很显然，Refresh Token 既然已经过期，就该要求用户重新登录了。

JWT - JSON Web Token

JWT 认证流程：

• 用户输入用户名/密码登录，服务端认证成功后，根据密钥生成JWT，服务器认证以后，生成一个 JSON 对象，发回给用户会返回给客户端一个 JWT

  {
  "姓名": "张三",
  "角色": "管理员",
  "到期时间": "2018年7月1日0点0分"
  }

  
  它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。
  JWT 的三个部分依次Header头部 Payload Signature

• 客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）

• 当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样 Authorization: Bearer
• 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
• 因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要
• 因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）

• 因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制

  Token 和 JWT 的区别

  相同：

• 都是访问资源的令牌

• 都可以记录用户的信息
• 都是使服务端无状态化
• 都是只有验证成功后，客户端才能访问服务端上受保护的资源

区别：

• Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
• JWT： 将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

  SSO - Single Sign On

  SSO 英文全称 Single Sign On，单点登录。

在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。
比如：淘宝网（www.taobao.com），天猫网（www.tmall.com），聚划算（ju.taobao.com），飞猪网（www.fliggy.com）等，这些都是阿里巴巴集团的网站。在这些网站中，我们在其中一个网站登录了，再访问其他的网站时，就无需再进行登录，这就是 SSO 的主要用途。

认证流程

以采购商城系统为例，打开无痕窗口，输入url，会被重定向到
http://ssosv.it.test.sankuai.com/sson/login?client_id=e2d9425605&redirect_uri=https%3A%2F%2Fcaigou.it.test.sankuai.com%2Fsso%2Fcallback%3Foriginal-url%3D%252F

redirect_uri 是采购商城的url，sso登录之后，会返回sso_token
采购商城浏览器发起请求，都会带上sso_token，验证sso_token是否有效，返回用户信息
采购系统会创建对应的采购a_token,验证a_token有效，可以正常访问

SSO与OAuth的区别

谈到SSO很多人就想到OAuth，也有谈到OAuth想到SSO的，在这里我简单的说一下区别。
通俗的解释，SSO是处理一个公司内的不同应用系统之间的登录问题，比如阿里巴巴旗下有很多应用系统，我们只需要登录一个系统就可以实现不同系统之间的跳转。
OAuth是不同公司遵循的一种授权方案，也是一种授权协议，通常都是由大公司提供，比如腾讯，微博。我们常用的QQ登录，微博登录等，使用OAuth的好处是可以使用其他第三方账号进行登录系统，减少了因用户懒，不愿注册而导致用户流失的风险。
现在一些支付业务也用OAuth，比如微信支付，支付宝支付。
还有一些开放平台也用OAuth，比如百度开放平台，腾讯开放平台。

SSO与RBAC的关系

如果企业有多个管理系统，现由原来的每个系统都有一个登录，调整为统一登录认证。
那么每个管理系统都有权限控制，吸取统一登录认证的经验，我们也可以做一套统一的RBAC权限认证。

OAuth2.0

OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。

OAuth 2.0 不能做什么呢？

1. OAuth 不是身份认证协议（是授权协议）。
2. OAuth 没有定义用户对用户的授权机制（主要是面向第三方软件的），用户对用户授权有 UMA（User Managed Access）协议。
3. OAuth 没有定义授权处理机制（只提供了防范来传达授权，具体授权内容未定义）。
4. OAuth 未定义令牌格式，你可以使用 JWT 或自定义的令牌格式。
5. OAuth 没有定义加密方法。

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

OAuth 四种模式

授权码许可

最安全的模式，以小明委托小兔打单软件打印京东商家订单为例：

小明是资源拥有者，小兔是第三方软件，还可以分为前端浏览器和后端服务器，京东开发平台包含授权服务、受保护资源服务。

为什么要有授权码 code，而不是直接返回访问令牌 access_token 呢？
授权服务需要以 URL 重定向的方式把授权信息（授权码）传递给小兔软件，如果把访问令牌放在 URL 里，就会暴露在浏览器上，不够安全。URL 里放授权码 code，小兔后端拿到后用授权码去授权服务换访问令牌即可。拿到访问令牌后，就可以访问受保护资源了。同时要求 code 是一次性的，才能保证 code 泄漏后不被重复利用。
要点：

1. 授权服务的核心就是，先颁发授权码code值，再颁发访问令牌access_token值。
2. 在颁发访问令牌的同时还会颁发刷新令牌refresh_token值，这种机制可以在无须用户参与的情况下用于生成新的访问令牌。
3. 授权还要有授权范围，不能让第三方软件获得比注册时权限范围还大的授权，也不能获得超出了用户授权的权限范围，始终确保最小权限安全原则。
4. OAuth 2.0规范并没有约束访问令牌内容的生成规则，只要符合唯一性、不连续性、不可猜性就够了。

   资源拥有者凭据许可

   从“资源拥有者凭据许可”这个命名上，你可能就已经理解它的含义了。没错，资源拥有者的凭据，就是用户的凭据，就是用户名和密码。
   可见，这是最糟糕的一种方式。那为什么OAuth 2.0还支持这种许可类型，而且编入了OAuth 2.0的规范呢？ 假如小兔此时就是京东官方出品的一款软件，小明也是京东的用户，那么小明其实是可以使用用户名和密码来直接使用小兔这款软件的。原因很简单，那就是这里不再有“第三方”的概念了。
   但是呢，如果每次小兔都是拿着小明的用户名和密码来通过调用Web API的方式，来访问小明店铺的订单数据，甚至还有商品信息等，在调用这么多API的情况下，无疑增加了用户名和密码等敏感信息的攻击面。 如果是使用了token来代替这些“满天飞”的敏感信息，不就能很大程度上保护敏感信息数据了吗？
   这样，小兔软件只需要使用一次用户名和密码数据来换回一个token，进而通过token来访问小明店铺的数据，以后就不会再使用用户名和密码了。
   

   客户端凭据许可

   如果没有明确的资源拥有者，换句话说就是，小兔软件访问了一个不需要用户小明授权的数据，比如获取京东LOGO的图片地址，这个LOGO信息不属于任何一个第三方用户，再比如其它类型的第三方软件来访问平台提供的省份信息，省份信息也不属于任何一个第三方用户。
   此时，在授权流程中，就不再需要资源拥有者这个角色了。当然了，你也可以形象地理解为 “资源拥有者被塞进了第三方软件中” 或者 “第三方软件就是资源拥有者”。这种场景下的授权，便是客户端凭据许可，第三方软件可以直接使用注册时的app_id和app_secret来换回访问令牌token的值。
   

   隐式许可

   如果小明使用的小兔打单软件应用没有后端服务，就是在浏览器里面执行的，比如纯粹的JavaScript应用，应该如何使用OAuth 2.0呢？
   其实，这种情况下的授权流程就可以使用隐式许可流程，可以理解为第三方软件小兔直接嵌入浏览器中了。 在这种情况下，小兔软件对于浏览器就没有任何保密的数据可以隐藏了，也不再需要应用密钥app_secret的值了，也不用再通过授权码code来换取访问令牌access_token的值了。因为使用授权码的目的之一，就是把浏览器和第三方软件的信息做一个隔离，确保浏览器看不到第三方软件最重要的访问令牌access_token的值。
   因此，隐式许可授权流程的安全性会降低很多。在授权流程中，没有服务端的小兔软件相当于是嵌入到了浏览器中，访问浏览器的过程相当于接触了小兔软件的全部，因此我用虚线框来表示小兔软件，整个授权流程如下图所示：
   

References

JWT-阮一峰
Cookie-Session-Token-JWT