单点登录

sso

彻底理解cookie，session，token

一. 单点登录的背景

​ 在企业发展初期，企业使用的系统很少，通常一个或者两个，每个系统都有自己的登录模块，运营人员每天用自己的账号登录，很方便。

但随着企业的发展，用到的系统随之增多，运营人员在操作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于运营人员
来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。

二. 什么是单点登录?

​ 单点登录(Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

​ 如图所示，图中有4个系统，分别是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他的业务模块，当Application1、Application2、Application3需要登录时，将跳到SSO系统，SSO系统完成登录，其他的应用系统也就随之登录了。这完全符合我们对单点登录（SSO）的定义。

三. 单点登录的解决方案

1. Session 跨域

​ 所谓的session跨域就是摒弃了系统提供的session,而使用自定义的类似Session的机制来保存客户端数据的一种解决方案.

​ 如: 通过设置cookie的domain(域)来实现cookie的跨域传递.在cookie中传递一个自定义的session_id.这 个session_id是客户端的唯一标记.将这个标记作为key,将客户端需要保存的数据作为value,在服务器端进行保 存(数据库报讯或NoSql保存).这种机制就是Session的跨域解决.

​ 什么是跨域: 客户端请求的时候,请求的服务器,不是同一个 IP, 端口号, 域名, 主机名的时候,都称为跨域.

​ 什么是域: 在应用模型中,一个完整的,有独立访问路径的功能集合称为一个域.

​ 如: 百度称为一个应用或系统.百度下有若干的域,

​ 搜索引擎(www.baizhi.com)

​ 百度地图(map.baidu.com)

​ 百度知道(zhidao.baidu.com)

​ 百度贴吧(tie.baidu.com)

​ 域信息有时也称为多级域名.域的划分 : 以 IP,域名,主机名为标准,实现划分.

​ localhost | 127.0.0.1 这就是跨域 localhost:域名 127.0.0.1 IP

​

---

2.WEB应用集群,session共享模式

​ 解决了单点性能瓶颈.

​ 问题 :

​ 1.多业务分布式数据独立管理,不适合统一维护一份session数据.

​ 2.布式按业务功能切分,用户,认证解耦合出来单独统一管理.

​ 3.cookie中使用jsessionId容易被篡改,盗取.

---

3.Token机制

1. 传统身份认证

​ HTTP是一种没有状态的协议,也就是它并不知道是谁访问应用.这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求的时候,还得再验证一下.

​ 解决的方法就是,当用户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的ID号发送给客户端,客户端收到以后把这个ID号存储在Cookie里,下次这个用户再像服务端发送请求的时候,可以带着这个Cookie,这样服务端会验证这个Cookie里的信息,看看能不能在服务端这里找到对应的记录,如果可以,说明用户已经通过了身份验证,就把用户请求的数据返回给客户端.

​ 上面说的就是session,我们需要在服务端存储为登录的用户生成的session,这些session可能会存储在内存,磁盘,或者数据库里,我们可能需要在服务端定期的去清理过期的session.

​ 这种认证中出现的问题是:

​ session:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息.当越来越多的用户请求时,内存的开销也会不断的增加.

​ 可扩展性:在服务端的内存中使用session存储登录信息,伴随而来的是可扩展性的问题.

​ CORS(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题.在使用Ajax抓取另一个域的资源,就可以会出现禁止请求的情况.

​ CSRF(跨站请求伪造):用户在访问银行网站时,他们容易受到跨站请求伪造的攻击,并且能偶够被利用其访问其他的网站.

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

2. Token身份认证

   ​ 客户端使用用户名,密码请求登录

   ​ 服务端收到请求,去验证用户名,密码

   ​ 验证成功后,服务端会签发一个token并将token,再把这个token发送给客户端

   ​ 客户端收到Token以后可以把它存储起来,比如放在Cookie里或者Local Storage里,客户端每次向服务端服务器请求资源的时候需要带着服务端签发的Token.

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

   ​ 使用Token验证的优势:

   ​ 无状态,可扩展

   ​ 在客户端存储的Token是无状态的,并且能够被扩展.基于这种无状态和不存储session信息,负载均衡器能够将用户信息从一个服务器传到其他的服务器上.

   ​ 安全性

   ​ 请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造).即使在客户端使用cookie存token,cookie也仅仅是一个存储机制而不是用于验证.不将信息存储在session中,让我们少了对session的操作.

---

4. JSON Web Token(JWT)机制

四. JSON Web Token(JWT)机制

​ JWT是一种 紧凑 且 自包含的,用于在多方传递JSON随想技术.传递的数据可以使用数字签名增加其安全性.可以使用HMAC加密算法或RSA公钥/私钥加密方式.

​ 紧凑: 数据小,可以通过URL,POST参数,请求头发送.且数据小代表传输速度快.

​ 自包含: 使用payload数据块记录用户必要且不隐私的数据,可以有效的减少数据库访问的次数,提高代码性能.

​ JWT一般用于处理用户身份验证或数据信息交换.

​ 用户身份验证: 一但是用户登录,每个后续请求都包含JWT,允许用户访问该令牌允许的路由,服务和资源.单点登录是当今广泛使用JWT的一项功能,因为他的开销小,并且能够轻松的跨不同的域使用.

​ 数据信息交换: JWT是一种非常方便的多方传递数据的载体,因为其可以使用数据签名来保证数据的有效性和安全性.

1. JWT数据结构

   JWT的数据结构是: A.B.C 由字符 ’ , ’ 来分割三部分数据.

   A. header 头信息

   ​ 数据结构: {“alg” : “加密算法” , “typ” : “JWT”}

   ​ alg是加密算法定义内容,如: HMAC(对称加密) SHA256 或 RSA(非对称加密) …

   ​ typ是token类型,这里固定为(JWT)

   B. payload (有效荷载)

   ​ 在payload数据块中一般用于记录实体(通常为用户信息)或其他数据的.主要分为三个部分,分别是: 已经注册信息(registered),公开数据(public claims),私有数据(private claims).

   ​ payload中常用信息有: iss(发行者),exp(到期时间),sub(主题),aud(受众)等. 这些列举的是已经注册的信息

   ​ 公开数据部分一般都会在JWT注册表中增加定义.避免和一注册信息冲突.

   ​ 公开数据和隐私数据可以由程序员任意定义.

   ​ 注意: 即使JWT有签名加密机制,但是payload内容都是明文记录,除非记录的是加密数据,否则不排除泄露隐私数据的可能.不推荐在payload中记录任何敏感数据.

   C. signature 签名

   ​ 签名信息: 这是一个有开发者提供的信息,是服务器验证的传递的数据是否有效安全的标准.在生成JWT最终数据之前,先使用header中定义的加密算法,将header和payload进行加密,并使用点进行连接.如: 加密后的head加密 . 后的payload.再使用相同的加密算法,对加密后的数据和签名信息进行加密.得到最终的结果.

五. 案例

1. 点击登录按钮,在登陆页面输入用户名和密码通过用户名和密码验证用户是够登陆成功,登录成功生成jwt的token返回给对应页面,在拦截器里面将返回的token写入cookie

1.主动登录 :

1. 登录两个页面

2. 首页登录并携带ReturnUrl回跳地址(登陆成功后回跳的地址)

3. 点击提交(验证成功生成token并储存在cookie)

4. 根据回跳地址ReturnUrl访问原始功能

4. 刷新

7. 主动登录小结 :

   1.访问首页页面
   被拦截器拦截
   判断是否有注解
   没有注解 : 直接放行
   有注解 : 根据自定义注解判断
   是否必须登录
   是否不必登录,但是必须验证token
   首页可以不登陆,但必须验证
   没登录过,一定没有token
   根据校验token的结果做出对应的处理
   2.点击登录,跳转到登陆页面携带ReturnUrl回跳地址(登陆成功后回跳的地址)
   被拦截器拦截
   跳转登陆页面,没有注解,直接放行
   3.登录(ajax请求)
   被拦截器拦截
   登陆没有注解,直接放行
   登陆失败 : 错误提示
   登陆成功 : 生成JWT的token,并存储到cookie中(设置cookie的domain可以实现跨域)
   4.返回到原始页面(也就是首页)
   被拦截器拦截
   首页可以不登陆,但必须验证token
   现在cookie中已经有token
   根据校验token的结果做出对应的处理

8. 后台代码实现

见后台代码实现篇章

2.被动登录

1. 访问首页

2. 未登录状态购买

3. 跳转到登陆页面

4. 跳转到订单页面

5. 被动登录小结 :

   1.访问首页
   被拦截器拦截
   判断是否有注解
   没有注解 : 直接放行
   有注解 : 根据自定义注解判断
   是否必须登录
   是否不必登录,但是必须验证token
   首页可以不登陆,但必须验证
   没登录过,一定没有token
   根据校验token的结果做出对应的处理
   2.点击购买
   被拦截器拦截
   订单必须登录
   判断是否有token
   没有token,跳转到登陆页面
   有token,进行token的校验
   没登录,一定没有token,跳转到登陆页面
   3.登录(ajax请求)
   被拦截器拦截
   登陆没有注解,直接放行
   登陆失败 : 错误提示
   登陆成功 : 生成JWT的token,并存储到cookie中(设置cookie的domain可以实现跨域)
   4.返回到订单页面
   被拦截器拦截
   订单必须登录
   判断是否有token
   没有token,跳转到登陆页面
   有token,进行token的校验
   登陆后已经有token,进行token的校验(成功: 跳转到订单页面 失败: 不跳转)

6. 被动登录后台代码见另一篇微博