单点登陆原理

概述

随着造的轮子越来越多,重复鉴权就变得越来越恶心了。出于这个需求,前人也想到了应对办法,就是单点登陆SingleSignOn,简称SSO。通过把登陆验证功能独立出来,业务系统在需要鉴权时候跳转到SSO进行鉴权,授权通过后,返回业务系统进行后续操作。

优缺点

目前有很多行业大佬的产品都是通过SSO实现的。例如,阿里系的淘宝、天猫、支付宝,百度系的网盘、贴吧,数不胜数。优点很明显,减少用户在多个业务平台的鉴权操作,只要用户在任意业务进行登陆验证,其他系统都可以完成鉴权。缺点主要还是体现到逻辑复杂程度上,SSO不比单业务的登陆验证,需要跨业务进行数据交互,这就增加了逻辑处理的复杂程度,同时在后续接入系统的时候,需要考虑多业务平台是否都开放给用户。

实现流程

单点登陆

w1.com/profile -> sso.com/checkLogin -> sso.com/login -> w1.com/profile?token=xxx -> sso.com/verify?token=xxx -> w1.com/profile
假设有业务网站w1,用户在访问w1.com/profile的时候需要进行身份验证

  1. w1网站先检测本身的session信息是否存在有效信息,如果存在直接正常访问
  2. 如果不存在,跳转到sso.com/checkLogin,通过SSO系统验证是否存在主session信息
  3. 如果不存在主session信息,跳到转sso.com/login进行登陆验证。
  4. 验证通过后设置主session并返回业务网站w1,并携带token信息(w1.com/profile?token=xxx)
  5. w1网站在收到token信息后,去SSO系统校验有效性(sso.com/verify?token=xxx)
  6. 如果token校验通过,返回业务网站w1并设置子session

以上操作就完成了登陆鉴权逻辑,相比单系统的登陆验证,增加了SSO系统的检测登陆和token验证操作。
后续如果有业务网站w2需要登陆的时候,同样跳转sso.com/checkLogin验证主session信息,由于已经存在主session信息,直接跳转w2.com/anything?token=yyy,然后同样经过SSO验证token有效性,最终返回w2,实现登陆验证操作。

单点注销

单点注销操作的逻辑实现需要在单点登陆操作的过程中保存已登陆的子业务系统的session和注销地址,在用户通过任意子业务系统进行注销的时候,实际上访问的是SSO系统的注销功能,SSO收到用户的注销请求后,检索之前保存的用户已登陆子系统session信息,逐个系统进行注销操作。

通过以上流程可以分析出一下3点:

  1. 主session如果存在,子session未必存在
  2. 任意子session存在,主session必然存在
  3. 主session注销,子session必然注销

参考连接

单点登陆SSO