跳到主要内容

【举一反三】— 单点登录的三种实现

6 分钟阅读

前言​

今天在逛淘宝的时候偶然发现在淘宝登录之后再去访问天猫竟然不需要登录操作,我勒个去,用了这么久淘宝天猫竟然现在才发现。但这到底是为什么呢? 于是抱着一个强烈的好奇心开始了我的探索之路，没错,头发就是这样一点点没的。

抱着心中的疑问我开始在互联网上进行了一系列的搜索,“为什么,在一个网站登录之后就可以访问与这个网站同属一家公司的另一个网站呢?","什么是单点登录?"。

就这样,通过我一步步的抽丝剥茧,我渐渐的接近了真相,尽管最后还是没有查阅到阿里是如何实现 单点登录的,但我对单点登录还是有了一个全新的认识。

什么是单点登录?​

单点登录指的就是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。再简单点说的话就是单点登录的本质就是在多个应用系统中共享登录状态。

就拿阿里举个例子

天猫淘宝实现了单点登录,那么你只需要登录其中的任意一个,在访问另一个网站时就无须再次登录了。

单点登录的原理​

单点登录的核心原理在于两个字: 共享.

Session实现登录​

多个应用系统后台之间共享Session 如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。

多个域名之间共享session ID

仅仅是共享session是不够的,因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。

Token实现登录​

使用token实现也和上面一样需要让token在多个域之间共享。

所以我们知道了

实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

单点登录的实现​

父域Cookie​

一般来说Session ID是存在Cookie中的,因此,如何让 Session ID（或 Token）在多个域中共享的问题也就变成了如何让多个域名之间共享Cookie。

但是我们知道由于浏览器的同源策略,不同域之间是不能互相访问Cookie的。但同时我们别忘了Cookie有一个特点,那就是父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。

利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。

不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

总结：此种实现方式比较简单，但不支持跨主域名。

认证中心​

我们可以部署一个专门用于处理登录请求的独立的Web服务,也称之为认证中心。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。

如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

举个例子 假如我们要访问系统1和系统2

流程如下

  • 用户访问系统1的受保护资源，系统1发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数

  • sso认证中心发现用户未登录，将用户引导至登录页面

  • 用户输入用户名密码提交登录申请

  • sso认证中心校验用户信息，创建用户与sso认证中心之间的会话，称为全局会话，同时创建授权令牌

  • sso认证中心带着令牌跳转会最初的请求地址（系统1）

  • 系统1拿到令牌，去sso认证中心校验令牌是否有效

  • sso认证中心校验令牌，返回有效，注册系统1

  • 系统1使用该令牌创建与用户的会话，称为局部会话，返回受保护资源

  • 用户访问系统2的受保护资源

  • 系统2发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数

  • sso认证中心发现用户已登录，跳转回系统2的地址，并附上令牌

  • 系统2拿到令牌，去sso认证中心校验令牌是否有效

  • sso认证中心校验令牌，返回有效，注册系统2

  • 系统2使用该令牌创建与用户的局部会话，返回受保护资源 用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系

  • 局部会话存在，全局会话一定存在

  • 全局会话存在，局部会话不一定存在

  • 全局会话销毁，局部会话必须销毁

这里顺便介绍两款认证中心的开源实现：

  • Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。
  • XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

LocalStorage 跨域​

前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？

很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。

不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。

在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

关键代码如下：

// 获取 token
var token = result.data.token;

// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
    iframe.remove();
}, 6000);

// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
    localStorage.setItem('token', event.data)
}, false);

前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。

总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。

参考​

傻傻分不清之 Cookie、Session、Token、JWT

前端关于单点登录的知识

Loading Comments...
0%