SSO
SSO
SSO 仅仅是一个概念，
Same Sign On
Single Sign On
实现这个概念的方式有很多很多种，对于Same sign on而言，所有登录接口公用一个数据库就能实现Same Sign On的
Single Sign On的实现方式可以为，将所有登录逻辑的JWT放到一起做，签发的Token大家一起用，但这样做风险太大了
所以说SSO仅仅是一个概念，有着很多很多的实现方式，我们公司的实现方式是通过OIDC协议的方式实现的
OIDC是OAUTH协议的进阶版，这个协议最初不是专门用来完成认证功能的，而是用来完成授权服务的
JWT
为用户开放一个登录接口，用户请求后API校验账号密码，是否成功登录，如果成功登录返回一个Token，Client每次请求都拿着这个Token请求
但这时仍然没完成登录，只是拿到了一个令牌（token）而已
对于Client来说，拿着token请求API获取到UserInfo，这个才是真正意义上的登陆成功
这里很重要，一定要明确什么才算是真正意义上的登录
OAUTH
在一个OAUTH服务的登录流程中分为三个模块，SSO服务器、Client、API
当用户使用浏览器请求访问Client时，Client会给用户一些信息（scope、clientId、secret等），浏览器拿着这些信息去找SSO服务器登录
SSO会校验这些信息的合法性，如果信息合法则开发登录
如果登录成功，SSO会返回给用户两个东西：access-token和cookie，同时自己存一份session（用以校验cookie）
cookie用来保存登录状态，access-token用以访问API
client拿到access-token之后，请求SSO服务器获取UserInfo接口，获取用户信息，这样就实现登录功能
这时Client就可以拿着access-token去访问API被保护的资源了，如果access-token为长token，API可自行校验，如果access-token为短token，则需要请求SSO的introspection接口进行校验
单点登录
这时，如果浏览器继续访问Client2，仍然会被Client2带到SSO服务前，但SSO会用自己的Session验证浏览器的Cookie是否为登陆状态，如果仍然为登陆状态，则询问用户是否授权，公司这里的逻辑直接跳过用户授权，直接判定登陆成功，然后签发access-token，这样就真正意义上的实现了单点登录
OIDC
Client拿到access-token之后，请求SSO服务器获取UserInfo接口，获取用户信息，这样就实现登录功能，因为实现登录功能并不是OAUTH的本意，但授权本身的前提就是完成认证，所以这个UserInfo不是OAUTH协议提供的，大家实现起来没有规范，所以就出现了OIDC，OIDC是OAUTH协议的进阶版本
OIDC提供了一个额外的Token，这个Token一定为JWT类型的Token（长Token），一起返回给Client，这个Token的名字为Id-Token
当client拿到Id-Token之后直接解析，就能获取到UserInfo，而无需再请求不规范的UserInfo接口来获取用户信息，完成用户登录
scope
scope定义了签发access-token的使用范围
最开始由client将浏览器带到SSO时，就会有一些信息，其中就包括scope，而这个scope本身也会由SSO服务器定义，如果两个scope相符，才会判断为合法
scope定义了OAUTH协议的授权范围，当你使用Client访问API１的时候，再去访问API2，API２会因为token需求不同而拒绝访问，scope就可以勾选上API2，从最开始请求access-token时就定义要访问的范围，这样就完成了服务间调用token权限不足的问题
换token
门诊医生站（outp）没有访问住院医生站（emr）的权限，但门诊医生站存在访问医院信息管理系统（his）的权限，且医院信息管理系统有访问住院医生站的权限
这时，我们使用outp调用his，在his更换access-token，且更换了scope，但保留发起者是outp这一条重要信息，这样，通过间接的方式，outp就请求到了emr
这种方式仅限于内部环境使用，我们默认彼此之间是比较信任的，如果放在外网使用会有权限爆炸的风险
Authorization授权
我们上面所说的授权，指的是使用OAUTH协议给Client授权访问SSO调取个人信息的这一过程
这样我们在其他项目中就无需维护登录模块
在这里我们引入另一种授权的概念，即角色授权：维护一套Roles角色表，将用户与角色关联起来，就可以限制某个用户能访问到的资源
这种角色授权目前一共有三种实现方式：
- Synyi的SSO内置了RBAC，可以在SSO维护这一套角色表，嵌入后端
- 在SSO之外单独建立一套ACL系统来精细化控制授权，更精准的把控用户能访问的资源和行为
- 在项目中，单独维护一套用户和角色，在项目中规范用户能够访问的内容、
这里需要注意，一定要区分这里的授权，和前面讲到OAUTH的授权是完全不同的概念