SSO 方案演进

admin

背景介绍
随着业务与技术的发展，现今比以往任何时候都更需要单点登录 SSO 身份验证。

现在几乎每个网站都需要某种形式的身份验证才能访问其功能和内容。

随着网站和服务数量的增加，集中登录系统已成为一种必要。

在本文中，我们将研究 SSO 身份验证的方案演进。



问题描述
开发团队迟早会面临一个问题，已经开发了网站 A，新开发的网站 B 希望使用网站 A 的登录信息，而不是使用一套新的登录信息，如下图所示：


事实上，你可能还希望已经在网站 A 登录的用户自动完成网站 B 的登录。

问题的解决方案显然是实现跨不同域之间共享会话信息。但是，由于安全原因，浏览器会强制执行同源策略 - Same Origin Policy。

该策略规定，Cookies 只能由其创建者访问。换句话说，如果网站 A 和 网站 B 不是同域，网站 B 无法访问网站 A 的 Cookies，反之亦然，如下图所示：

SSO 其实就是要以某种方式解决不同域之间共享会话信息。

解决方案
一、同源解决方案

要解决不同域之间共享会话信息，一个最简单粗暴的办法就是让网站同域，如下图所示：

1. 用户浏览网站 A

2. 网站 A 发现无 *.domain.com 的 Cookies，重定向到认证中心

3. 认证中心要求用户使用账号密码登录

4. 认证中心保存 Cookies 到 *.domain.com

5. 重定向返回网站 A

6. 网站 A 读取 *.domain.com 下的 Cookies 完成校验，展示网站内容

7. 用户浏览网站 B

8. 网站 B 读取 *.domain.com 下的 Cookies 完成校验，展示网站内容



二、非同源解决方案

同源的解决方案可以满足大部分场景，但是针对一些多产品的场景，比如，阿里巴巴有天猫和淘宝两个产品，同源解决方案显然不能满足需求。

不同的 SSO 协议以不同的方式共享会话信息，但基本概念是相同的：有一个认证中心，执行身份验证，然后以某种方式与其他域共享会话信息。

其中一种方式是使用 JWT - JSON Web Token，认证中心使用 JWE - JSON Web Encryption 对用户信息进行加密，生成 JWT。

然后通过重定向的方式，把 Token 传回原始站点，Token 包含需要验证用户所需的所有信息。

由于 Token 是使用 JWT 加密的，除了认证中心外无法以任何方式修改它，具体流程如下：

1. 用户浏览网站 A

2. 网站 A 发现无 domain1.com 的 Cookies，重定向到认证中心

3. 认证中心要求用户使用账号密码登录

4. 认证中心保存 Cookies 到 auth.com

5. 重定向返回网站 A 并在 URL 携带验证用户信息的 Token

6. 网站 A 校验 Token 完成验证

7. 网站 A 保存 Cookies 到 domain1.com，供后续验证使用，并显示网站内容

8. 用户浏览网站 B

9. 网站 B 发现无 domain2.com 的 Cookies，重定向到认证中心

10. 认证中心发现有 auth.com 的 Cookies，对 Cookies 进行校验

11. 重定向返回网站 B 并在 URL 携带验证用户信息的 Token

12. 网站 B 校验 Token 完成验证

13. 网站 B 保存 Cookies 到 domain2.com，供后续验证使用，并显示网站内容