组成部分
- 业务系统A
- 业务系统B
- SSO认证中心
基本介绍
系统A, B没有登陆界面，登陆操作由SSO认证中心统一完成。通过跳转完成参数传递。
系统A，B的代码基本不用变化。只需新增第一次去SSO认证中心验证check_token的代码。
验证流程
- 用户从系统A登陆，系统A后台判定用户有没有权限，没有：第二步，有：验证结束。
- 前端自动跳转到SSO认证中心， url参数带上系统A的返回地址。
- SSO验证中心，判断有没有存储access_token, 没有:第四步， 有:第五步。
- 用户在SSO认证中心输入用户名和密码，拿到access_token。
- 验证access_token, 判断有没有过期， 没有：第六步， 有：第四步。
- SSO认证中心存储access_token【以便下次用户登陆其他系统获取】【可用localStorage存储】。
- 用户跳转回系统A, 跳转地址为第一步的url参数，同时带上access_token
- 系统A拿到access_token,传回后台，后台与SSO认证中心进行通信，如果验证成功，将用户在系统A的用户身份信息【比如用户名，用户id】返回给系统A后台，验证失败，执行第二步。
- 系统A根据自身验证授权机制【cookie, session】进行接下来的操作。
- 系统A登陆过程完成。
- 当用户转入系统B, 执行步骤等同于系统A的验证步骤。
注意事项
- SSO验证平台要管理用户名和密码
- SSO验证平台要管理自身用户名和各个业务系统用户身份信息的映射关系。
- SSO验证平台要管理可接入的业务系统信息【比如系统后台IP】，用来确定验证请求需要的身份信息。
缺点
- SSO验证平台在每一个业务系统接入需要配置用户映射。
- 管理力度弱，无法共用一套组织架构和用户权限信息。【相对来说，如果对已有系统进行SSO改造，这也是优点。】
