不管是什么公司,只要产品数量大于一个,那么单点登录势必是绕不过去的一个问题。作为前端程序员,我们对其虽然接触不多,但适当的了解还是必要的。本文就来谈谈单点登录相关的问题。
了解 SSO,最好具备以下知识。当然,如果不是特别熟,也不影响阅读。
SSO 是英文 Single Sign On 的缩写,翻译过来就是单点登录。顾名思义,它把两个及以上个产品中的用户登录逻辑抽离出来,达到只输入一次用户名密码,就能同时登录多个产品的效果。
打个比方,SSO 和我们去迪士尼玩时购买的通票很像。
我们只要买一次通票,就可以玩所有游乐场内的设施,而不需要在过山车或者摩天轮那里重新买一次票。在这里,买票就相当于登录认证,游乐场就相当于使用一套 SSO 的公司,各种游乐设施就相当于公司的各个产品。
使用 SSO 的优点很明显:
就以我厂为例。我厂有两个产品,丁香人才网和丁香园论坛,假如你是我厂用户,肯定无法忍受登录丁香园论坛的时候输入一次用户名密码,登录人才网又要输入一次用户名密码吧?
假如你是我厂后端,每天任务都饱和的不行,肯定无法忍受到人才网开发一套登录逻辑,到论坛又开发一套登录逻辑吧?
假如你是我厂运维,发现了一个安全隐患需要紧急修复。你肯定无法忍受给茫茫多的产品后端都发一封邮件,责令修复吧?万一漏了一个呢?
综合看来,SSO 不仅是有用的,而且是必要的。
SSO 仅仅是一种架构,一种设计,而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然,除了 CAS 之外,实现 SSO 还有其他手段,比如简单的 cookie。
CAS (Central Authentication Service)中心授权服务,本身是一个开源协议,分为 1.0 版本和 2.0 版本。1.0 称为基础模式,2.0称为代理模式,适用于存在非 Web 应用之间的单点登录。本文只涉及 CAS 1.0,下文中将详细介绍。
下面详述一下各种场景下的 SSO,它们之间是逐步升级,逐步复杂化的关系。
如图,同域 SSO 是最简单的一种情况。
此时,两个产品都是在一个域名下,单点登录是很自然的选择。我们来捋一捋步骤,搞清楚这里的步骤是理解后文的基础,千万不要跳过。
实际上,这种场景就是最简单最传统的登录操作。虽然我们把产品 a 和 b 人为分开了,但由于它们在同域上,就算看成是同一产品的不同类目也未尝不可。我们没有设置独立的 SSO 服务器,因为业务后台服务器本身就足以承担 SSO 的职能。
同父域 SSO 是同域 SSO 的简单升级,唯一的不同在于,服务器在返回 cookie 的时候,要把cookie 的 domain 设置为其父域。
比如两个产品的地址分别为 a.dxy.cn 和 b.dxy.cn,那么 cookie 的域设置为 dxy.cn 即可。在访问 a 和 b 时,这个 cookie 都能发送到服务器,本质上和同域 SSO 没有区别。
可以看到,在上面两种情况下,我们都没有专门设置 SSO 服务器。但是当两个产品不同域时,cookie 无法共享,所以我们必须设置独立的 SSO 服务器了。这个时候,我们就是通过标准的 CAS 方案来实现 SSO 的。下面我们就来详细介绍一下:
CAS 1.0 协议定义了一组术语,一组票据,一组接口。
TGT 是 CAS 为用户签发的登录票据,拥有了 TGT,用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时,CAS 以此 Cookie 值(TGC)为 key 查询缓存中有无 TGT ,如果有的话,则相信用户已登录过。
CAS Server 生成TGT放入自己的 Session 中,而 TGC 就是这个 Session 的唯一标识(SessionId),以 Cookie 形式放到浏览器端,是 CAS Server 用来明确用户身份的凭证。
ST 是 CAS 为用户签发的访问某一 service 的票据。用户访问 service 时,service 发现用户没有 ST,则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求,CAS 发现用户有 TGT,则签发一个 ST,返回给用户。用户拿着 ST 去访问 service,service 拿 ST 去 CAS 验证,验证通过后,允许用户访问资源。
票据之间的关系如下图。注意,PGTIOU, PGT, PT 是 CAS 2.0 中的内容,感兴趣的同学可以自行了解。
看到这里,是不是又有点晕了?没关系,下面我们借助一个简单的场景,再来仔细捋一捋用 CAS 实现 SSO 的详细步骤,顺便加深理解之前提出的概念。
开始!
如图所示,至此,整个登录流程结束。之后当用户访问 a 或者 b 后,直接会携带 a cookie/b cookie,就不用再向 SSO 确认了。
实际开发时,可以根据 CAS 增加更多的判断逻辑,比如,在收到CAS Server签发的ST后,如果 ST 被 hacker 窃取,并且 client 本身没来得及去验证 ST,被 hacker 抢先一步验证 ST,怎么解决。此时就可以在申请 ST 时添加额外验证因子(如ip、sessionId等)。
本文作者:丁香园F2E
原文链接:https://juejin.im/post/5a002b536fb9a045132a1727