当时公司的系统越来越多。管理后台一套登录，项目管理工具Jira一套登录，Confluence Wiki又一套登录。
新员工入职，要创建三次账号。员工忘密码，IT经常帮忙重置。员工离职，又要一个系统一个系统禁用账号。
更麻烦的是，有时候认证中心退出了，另外两个系统居然还能继续访问。
后来，我们就开始做一套统一认证。
我曾经落地过一套企业级单点登录（SSO），把内部管理后台、Jira、知识库这三个系统都接到同一个认证中心。后来，这套方案也一直作为公司的统一认证方案在用。本专栏会按我们当时做项目的顺序，从需求、架构一直讲到代码，一共九篇。
为什么要做SSO
左边是改造之前，每个系统各认各的密码。右边是接入SSO之后，登录都统一交给认证中心，员工登录一次，三个系统都能进。
一说SSO，大家第一反应往往是「登录一次，到处都能登录」。
往下做，你会发现远远不只是登录一次这么简单。
还有下面几件事要解决：
- 统一身份：一个人、一个主账号，各系统认的是同一张用户主数据。
- 统一登录入口：未登录时跳到认证中心，而不是每个系统各画一张登录页。
- 统一登出：在认证中心退一次，关联系统会话一起失效。
- 可扩展接入：新系统接入有章可循，而不是每次临时摸索。
我为什么写这个专栏
网上写SSO的文章不少，常见的是把CAS协议和几个接口讲清楚。
可到了落项目的时候，你会发现问题根本不是登录，而是：
- 第三方系统怎么接？
- 新系统怎么注册？
- 网关放哪里？
- 登录和登出怎么统一？
- OAuth2和CAS到底怎么配合？
所以这套专栏，我就按我们当时项目落地的顺序，一步一步写。里面会涉及管理后台、协作平台、知识库这三类最常见的接入场景，不是Demo，也不是Hello World。
本专栏解决什么问题
企业里最常见的就是下面三类系统（细节放在第02篇PRD）：
| 类型 | 专栏中的叫法 | 一句话说明 |
|---|---|---|
| 自研后台 | 内部管理后台 | 前后端分离，走一条登录路线 |
| 外部协作 | 协作平台A（Jira） | 成熟Web产品，走另一条路线 |
| 外部文档 | 知识库（Confluence） | 同上，产品不同，接法类似 |
学完CAS以后，一到项目里，下面这几个问题就会冒出来：
- 什么时候用OAuth2，什么时候用CAS？ 自研前后端分离后台和第三方Web产品，接入方式不一样，不能硬套同一种协议。
- 业务系统拿到的凭证长什么样？ 自研后台拿的是网关换取的业务JWT；第三方系统拿的是CAS一次性票据，向认证中心校验通过后在本地建立Session。
- 为什么要有网关？ 管理后台的API流量需要统一鉴权，登录入口也适合收敛在网关，这部分第06篇展开。
- 单点登出怎么才算真登出？ 认证中心退一次，自研后台的旧令牌和第三方系统的本地会话都要失效，第08篇专门讲。
这些东西现在不用急着记，我们后面再慢慢展开。
这张图不用记细节。浏览器请求从网关进来，登录交给认证中心，后面还有用户主数据，管理后台和第三方系统都接在这套体系里。具体模块为什么这么设计，第03篇会讲清楚。
专栏目录
我没有按知识点去拆，而是按当时项目推进的顺序来写。
先定需求，再定架构，再把认证中心搭起来，然后一个系统一个系统接进去，最后把单点登出补完整。
- 开篇词（本篇）
- 需求PRD：应用清单、场景对比、验收边界
- 技术架构设计方案：整体架构准绳
- CAS认证中心：多方式登录与JDBC认证
- 服务注册与环境隔离
- OAuth2与网关：前后端分离单点登录
- CAS协议：第三方应用接入实战
- 单点登出与全局会话失效
- 专栏总结与新应用接入指南
系统大概长什么样
一提SSO，大家第一个想到的就是CAS。
CAS只是其中一个模块。还有网关、用户主数据、业务令牌、管理后台。
现在不用关心实现，先知道整个系统有哪些模块：
| 模块 | 干什么 |
|---|---|
| 认证中心 | 统一登录页、发票据、登记接入应用、编排单点登出 |
| 网关 | 管理后台的登录入口和API流量入口 |
| 用户主数据 | 存查员工账号，登录时把邮箱、工号、扫码结果解析成同一个人 |
| 管理端用户服务 | 给管理后台签发业务令牌，接收认证中心的登出通知 |
四个模块为什么这么设计、各自负责什么，第03篇架构设计会讲清楚。
技术栈
整套方案基于JAVA 17，Apereo CAS、Spring Cloud Gateway、Spring Boot等企业常用技术栈实现，具体版本和选型理由在架构篇说明。
学完之后你能做什么
就是以后公司让你做SSO的时候，你知道第一步该干什么，第二步该干什么。
如果哪天领导跟你说：「把这个新系统接进统一认证。」
我希望你不会一脸懵，而是知道应该先去看认证中心、还是去改网关、还是注册CAS服务。
