Sam_Deep_Thinking

前面的登录流程已经打通了：员工打开管理后台，跳转到统一认证中心完成登录，认证成功后再回到管理后台。登录成功，并不代表后面的事情就结束了。浏览器回到管理后台之后，还要继续访问后台的各种业务接口。问题来了：这些接口怎么知道当前这个人已经登录了？这里还需要做一个动作。统一认证中心负责证明你是谁，管理后台自己的接口并不直接使用这次登录拿到的凭证。登录成功后，网关还需要拿着当前用户的loginName，向换取一张业务JWT。之后浏览器再访问管理后台接口，就带着这张JWT，由网关完成身份校验。

第04篇已经把认证中心的登录流程跑通了，员工账号能够完成认证并创建TGT。但这时候，从service-gateway或协作平台A发起登录，仍然可能被CAS直接拒绝，报「未授权的服务（Unauthorized service）」。原因不在登录认证本身，而在于认证中心还不知道这个应用是谁、回调地址是什么。换句话说，用户已经认出来了，但CAS还没认这个应用。这时候认证中心本身已经能完成登录，但base-oauth2还没有登记这个应用的回调地址，所以请求会被CAS拒绝。

当时公司的系统越来越多。管理后台一套登录，项目管理工具Jira一套登录，Confluence Wiki又一套登录。新员工入职，要创建三次账号。员工忘密码，IT经常帮忙重置。员工离职，又要一个系统一个系统禁用账号。更麻烦的是，有时候认证中心退出了，另外两个系统居然还能继续访问。后来，我们就开始做一套统一认证。我曾经落地过一套，把内部管理后台、Jira、知识库这三个系统都接到同一个认证中心。后来，这套方案也一直作为公司的统一认证方案在用。

这篇作为整个SSO专栏的架构基线。后面几篇涉及的服务名、表名、接口路径、Redis Key以及JWT约定，都以本文为准。下文均指专栏服务（与第01、02篇中的「认证中心」同义）。上一篇PRD把问题拆成了四件事：统一身份、统一登录、统一登出、可扩展接入。真正困难的地方，不是实现一次登录，而是让十年前的Web系统、现在的前后端分离应用，以及未来的新系统，共用一套身份体系。

第03篇已经明确了整体服务划分和核心链路。本篇先聚焦认证中心这一段：用户登录成功后，如何创建TGT并进入后续流程。不管走OAuth2还是CAS ST，用户都要先在登录页完成身份认证。真正麻烦的地方不是JDBC查询本身，而是邮箱、工号、钉钉扫码三个入口，最终都要映射到里的同一个用户主体；同时还要处理验证码校验、登录频率限制以及历史密码迁移。OAuth2授权码回调、网关换JWT、服务注册JSON，分别留给第05、06篇；这里不展开。