单点登录与权限管理本质：单点登录介绍

 

继续介绍「单点登录与权限管理」系列的第一部分：单点登录与权限管理本质，前两篇介绍了session与cookie 和 HTTP重定向 ，有了他们，浏览器就可以在多个系统间自动交互，实现自动登录。

该系列的完整写作计划，可见：系列概述

本篇介绍下单点登录，所谓单点登录，就是说用户只需在一个地方登录，访问其他相关系统时，不需要重复登录，隐式地自动登录，这样体验会比较好。

主要从以下几个方面介绍：

• 一个常见的交互流程
• 常见单点登录协议
• 关键问题总结

一个常见的交互流程

我们项目中，使用CAS协议实现单点登录，下面就以项目中的实现为例，先来看下其交互流程，对其实现有个基本的了解。

有2个系统，系统A是「客服工作台」，主要给客服使用，可实时与来访用户及时聊天，解答用户的问题。系统B是「工单系统」，对于不能解答的问题，客服会创建一个工单，更高级别或相关度高的人会看到工单进行处理。

客服希望在登录系统A后，不需要手动登录系统B，需要一个「单点登录服务」，提供一个统一的登录验证，协调系统A、系统B的自动登录，定义该服务为服务S，其CAS协议的场景的流程如下：

花了不少时间画上面的图，看着比较复杂，其实还好，希望大家花时间看下，如果前两篇文章真正理解了，这块就相对简单了。

重点总结下该流程：

• 黑圆圈红字，标识cookie的生成和使用，ABCDE表示5个cookie，1表示生成，2表示使用；
• 无论是系统A，还是系统B，如果没有jessionid cookie，都会跳转到服务S，如果携带了cookie1（登录成功后生成的cookie），不需要登录，会自动登录，如果没有携带cookie1，会跳转到登录页面，登录成功后会设置cookie1。
• cookie1是保持浏览器和服务S的，表示用户已经登录过了；
• cookie2、cookie4都是临时cookie，主要是将服务码带到系统A或系统B，拿到服务码后，通过后端请求服务S进行验证，验证过后，临时cookie就失效了，主要是为了安全考虑。
• cookie3、cookie5和我们正常登录产生的jessionid一样，是各个子系统独有的cookie；

如果还有疑问，可在下面留言，我会第一时间回复。

常见单点登录协议

上面介绍的是CAS协议的一种，还有其他协议可实现单点登录，比如CAS官网列举的协议：

这些协议有不同的适用场景，比如好多网站都支持使用QQ、微信、微博直接登录，只要你的QQ、微信、微博登录者，就不用重复登录，使用OAuth协议可比较好的实现这种场景。

后面会单独介绍这些协议。

关键问题总结

无论是哪一种协议，都需要一个中间系统，对验证和授权进行统一管理。另外，cookie的管理和安全问题需要重点考虑。

后面一篇会介绍下可能存在哪些安全问题，而对于安全问题如何解决，cookie和session具体如何管理，会在介绍每个具体协议的时候重点说明。

​