Day118:说一下单点登录实现原理
Genzhen opened this issue · comments
一、什么是单点登录
单点登录SSO(Single Sign On),是一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录得到其他所有系统的信任
比如现有业务系统A、B、C以及SSO系统,第一次访问A系统时,发现没有登录,引导用户到SSO系统登录,根据用户的登录信息,生成唯一的一个凭据token,返回给用户。后期用户访问B、C系统的时候,携带上对应的凭证到SSO系统去校验,校验通过后,就可以单点登录;
单点登录在大型网站中使用的非常频繁,例如,阿里旗下有淘宝、天猫、支付宝等网站,其背后的成百上千的子系统,用户操作一次或者交易可能涉及到很多子系统,每个子系统都需要验证,所以提出,用户登录一次就可以访问相互信任的应用系统
单点登录有一个独立的认证中心,只有认证中心才能接受用户的用户名和密码等信息进行认证,其他系统不提供登录入口,只接受认证中心的间接授权。间接授权通过令牌实现,当用户提供的用户名和密码通过认证中心认证后,认证中心会创建授权令牌,在接下来的跳转过程中,授权令牌作为参数发送给各个子系统,子系统拿到令牌即得到了授权,然后创建局部会话。
二、单点登录原理
单点登录有同域和跨域两种场景
1)同域
适用场景:都是企业自己的系统,所有系统都使用同一个一级域名通过不同的二级域名来区分。
举个例子:公司有一个一级域名为 zlt.com ,我们有三个系统分别是:门户系统(sso.zlt.com)、应用1(app1.zlt.com)和应用2(app2.zlt.com),需要实现系统之间的单点登录,实现架构如下
核心原理:
- 门户系统设置的cookie的domain为一级域名也是zlt.com,这样就可以共享门户的cookie给所有的使用该域名xxx.alt.com的系统
- 使用Spring Session等技术让所有系统共享Session
- 这样只要门户系统登录之后无论跳转应用1或者应用2,都能通过门户Cookie中的sessionId读取到Session中的登录信息实现单点登录
2)跨域
单点登录之间的系统域名不一样,例如第三方系统。由于域名不一样不能共享Cookie了,需要的一个独立的授权系统,即一个独立的认证中心(passport),子系统的登录均可以通过passport,子系统本身将不参与登录操作,当一个系统登录成功后,passprot将会颁发一个令牌给子系统,子系统可以拿着令牌去获取各自的保护资源,为了减少频繁认证,各个子系统在被passport授权以后,会建立一个局部会话,在一定时间内无需再次向passport发起认证
基本原理
- 用户第一次访问应用系统的时候,因为没有登录,会被引导到认证系统中进行登录;
- 根据用户提供的登录信息,认证系统进行身份校验,如果通过,返回给用户一个认证凭据-令牌;
- 用户再次访问别的应用的时候,带上令牌作为认证凭证;
- 应用系统接收到请求后会把令牌送到认证服务器进行校验,如果通过,用户就可以在不用登录的情况下访问其他信任的业务服务器。
登录流程
- 用户访问系统1的受保护资源,系统1发现用户没有登录,跳转到sso认证中心,并将自己的地址作为参数
- sso认证中心发现用户未登录,将用户引导到登录页面
- 用户提交用户名、密码进行登录
- sso认证中心校验用户信息,创建用户与sso认证中心之间的会话,称之为全局会话,同时创建授权令牌
- sso 带着令牌跳转回最初的请求的地址(系统1)
- 系统1拿着令牌,去sso认证中心校验令牌是否有效
- sso认证中心校验令牌,返回有效,注册系统1(也就是返回一个cookie)
- 系统一使用该令牌创建与用户的会话,成为局部会话,返回受保护的资源
- 用户访问系统2受保护的资源
- 系统2发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数
- sso认证中心发现用户已登录,跳转回系统2的地址,并且附上令牌
- 系统2拿到令牌,去sso中心验证令牌是否有效,返回有效,注册系统2
- 系统2使用该令牌创建与用户的局部会话,返回受保护资源
- 用户登录成功之后,会与sso认证中心以及各个子系统建立会话,用户与sso认证中心建立的会话称之为全局会话,用户与各个子系统建立的会话称之为局部会话,局部会话建立之后,用户访问子系统受保护资源将不再通过sso认证中心
注销流程
- 用户向系统提交注销操作
- 系统根据用户与系统1建立的会话,拿到令牌,向sso认证中心提交注销操作
- sso认证中心校验令牌有效,销毁全局会话,同时取出所有用此令牌注册的系统地址
- sso认证中心向所有注册系统发起注销请求,各注册系统销毁局部会话
- sso认证中心引导用户到登录页面