SSO相关

单点登录

• 单点登录（Single Sign On），简称为SSO，SSO使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

先前开发的时候对单点登录存在认识上的错误，错将长短token认定为了单点登录。长短token是拿来实现长期化登录的....比如OAuth2.0的refresh_token就是这个原理...所以简单记录一下

单点登录的核心是这样的

• 有一个统一身份认证中心IDP（Identity Provider），所有系统都信任这个IDP，用户首次访问某个系统的时候，会被重定向到这个IDP上。
• 登录成功后，IDP会返回一个凭证token，token用来认证身份信息。
• 各个子平台通过公钥私钥等方法和IDP进行通信，验证token的有效性。比如之前使用过的OAuth2.0.

举例一下OAuth2的流程

• 用户访问系统A
• 系统A发现用户未登录，重定向到IDP进行登录
• 用户在IDP登录成功，返回系统A，携带token
• 系统A验证token有效，允许用户访问
• 用户访问系统B，系统B也会进行上述流程，但是IDP是已经登陆的状态，所以不用重新登录

上述的token通用吗

• 不通用，每个系统都有自己的token，所以需要每个系统都进行上述流程
• 但是IDP会记住用户登录状态，所以用户在IDP登录后，再次访问其他系统时，不需要重新登录

上述token存哪里（JWT）

• 前端拿到JWT后，请求系统A时，把它放在请求头中
• 系统A收到请求后，使用IDP提供的公钥验证JWT的有效性
• 如果验证通过，系统A解码JWT，获取userId等信息，识别用户

为什么JWT不用存？

• 因为JWT是签名后的申明信息，服务端只需要验证签名是否被篡改、是否过期，不需要与数据库交互

不是JWT，token存哪里

• 有一个Opaque Token，IDP存在数据库中，需要走IDP进行验证

refresh_token怎么办

• refresh_token也是IDP提供的，和上面的JWT一起提供
• refresh_token如果要存储，存储在HttpOnly的cookie中，这样前端是看不到的，通过后端Set-cookie来设置。不能通过前端存储在两个storage中，会存在XSS隐患