CAS单点登录从原理到实战：TGT/ST票据交互与系统接入全解析-平芜编程栈

做统一登录这么多年，CAS这套东西我属实是又爱又恨。爱的是它老而弥坚，设计思路干净，撑起了无数老系统的认证半边天；恨的是初次接触的人，十有八九会被它那一堆 filter、service 参数和回调地址绕得晕头转向。但平心而论，对于需要快速打通多个内部系统账号体系的场景，它依然是那个最稳、最不容易翻车的“翻身好帮手”。这篇文章我不打算扯官方的长篇文档，就按照实际落地项目的顺序，把 CAS 单点登录从原理到排错，掰开揉碎讲一遍。

1. 先弄明白 CAS 到底在解决什么问题

1.1 没有 SSO 的日子有多痛苦

想象一下公司内部有 OA、ERP、Wiki、GitLab 五个系统，每个系统各有一套用户表。员工每天上班要在五个页面登五次账号密码，IT 部门要维护五份密码策略，新同事入职要在五个系统里各建一次账号。密码忘了要找回五次，改了密码要在五个地方同步。这种体验用“灾难”来形容一点不夸张。

从开发者的角度看，每个系统都要自己实现登录逻辑，自己存 session，自己管密码加密，代码重复且容易出安全漏洞。更麻烦的是，一旦某个系统被攻破拿到明文密码（或者弱 Hash），攻击者拿着同一套凭证去撞其他系统，风险立刻横向蔓延。

1.2 CAS 的核心思路：把登录这件事抽出来单干

CAS（Central Authentication Service）的思路非常朴素：既然登录认证是所有系统都要用的公共能力，那我干脆把它拆出来，做成一个独立的认证中心。所有系统都不再自己验证用户名密码，而是统一跳转到认证中心去登录。认证中心验证通过后，发给用户一个“通行证”，拿着这个通行证再去访问各个业务系统，业务系统验证通行证有效，就放行。

这个“通行证”在 CAS 协议里叫 TGT（Ticket Granting Ticket），存放在用户浏览器与 CAS 服务器之间的会话中（通常以 Cookie 形式）。而每次访问具体业务系统时临时签发的一次性凭证叫 ST（Service Ticket），有效期极短，用一次就作废。整个体系用一句话概括：认证中心负责发证，业务系统负责验票，浏览器负责存证。

1.3 CAS 和 JWT、OAuth2.0 这些有什么不一样

很多人会拿 CAS 和 JWT、OAuth2.0 对比，我简单理一下：

CAS 是重定向跳转式的 SSO 方案，用户浏览器全程参与，适合浏览器端 B/S 架构系统的统一登录。
OAuth2.0 更侧重授权，目标是让用户允许第三方应用访问自己的资源，典型场景是“用微信登录某个网站”，侧重点在开放授权。
JWT 是一种令牌格式，本身不是认证方案，它可以被用在 CAS、OAuth 等方案中作为 Token 的载体，两者不在一个维度。

如果你只是做企业内部系统的统一登录，且系统都是服务端渲染的 Web 应用，CAS 的成熟度和稳定性是经得起考验的。它没有 OAuth 那套授权码、Token 刷新的繁琐概念，核心就是“跳转、验票、建会话”三板斧，理解成本低，出了问题也好排查。

2. CAS 的体系架构与核心术语

2.1 架构里有哪些角色

用大白话描述，CAS 体系里有三个角色：

浏览器（User Agent）：员工本人操作的浏览器，负责存 Cookie、发请求、跟随重定向。
CAS Server（认证中心）：独立的 Web 应用，负责登录页展示、用户名密码校验、签发 TGT 和 ST。
CAS Client（业务系统）：各业务系统里接入的客户端组件（Java 项目常用 cas-client 或 Spring Security CAS，其他语言也有对应客户端），负责拦截未登录请求、跳转认证中心、校验 ST。

三者的交互过程表面看是浏览器地址栏一次次跳转，实际干活的流程我放在第三章详细讲。

2.2 核心术语：TGT、TGC、ST、PGT

这些缩写刚接触时容易混，我整理成一张对照表方便查阅：

缩写	全称	中文俗称	生命周期	主要用途
TGT	Ticket Granting Ticket	票据授予票据	较长（默认几小时到一天）	证明用户已经在 CAS 登录过
TGC	Ticket Granting Cookie	票据授予 Cookie	与 TGT 一致	浏览器侧存 TGT 的标识，关联服务端 TGT
ST	Service Ticket	服务票据	极短（默认几十秒到几分钟）	一次性凭证，换取业务系统本地会话
PGT	Proxy Granting Ticket	代理授予票据	较长	用于 CAS 代理模式下的二次认证

初学阶段你重点理解 TGT 和 ST 就足够了。TGT 存在 CAS 服务端内存（或分布式缓存）里，TGC 是写给浏览器的 Cookie，两者通过一个唯一 ID 关联。用户首次登录 CAS，服务端生成 TGT，同时给浏览器下发 TGC。后续访问其他业务系统时，浏览器带着 TGC，CAS 发现这个用户已经有有效的 TGT，就不再要求输密码，直接签发新的 ST。这就实现了“一次登录，处处访问”。

2.3 代理模式：服务端之间的认证穿越

还有一个高级概念叫 Proxy 模式，场景是：一个服务端应用需要以用户身份去访问另一个服务端应用，比如门户系统需要拉取 OA 系统的待办事项。这涉及服务端到服务端的认证，普通 ST 是发给浏览器端用的，服务端拿不到，这时需要用到 PGT 和 PT（Proxy Ticket）。实际工作中遇到这种场景不多，但真遇到了要能识别，否则会卡在“为什么 A 系统调 B 系统接口拿不到用户身份”的问题上很久。

3. CAS 单点登录的完整交互流程拆解

3.1 首次登录，浏览器引导下的三级跳

假设用户从未登录过，直接访问业务系统 A（配置了 CAS Client），完整流程是这样的：

浏览器请求http://app-a.example.com/main，CAS Client 拦截器发现 Session 里没有用户信息，于是返回一个 302 重定向，地址指向 CAS Server 的登录接口：https://cas.example.com/cas/login?service=http%3A%2F%2Fapp-a.example.com%2Fmain
注意这个service参数，它表示“登录成功后我该回哪去”，必须做 URL 编码。
浏览器跟随重定向，访问 CAS Server 的登录页，输入用户名密码提交。CAS Server 校验通过后，做了两件事：
- 在服务端创建 TGT，并通过响应头Set-Cookie下发 TGC 给浏览器；
- 生成一个一次性 ST，再次 302 重定向回业务系统，地址类似：http://app-a.example.com/main?ticket=ST-20240520-xxxxx
浏览器带着 ST 访问业务系统 A，CAS Client 拦截器拿到这个ticket参数后，在服务端请求 CAS Server 的验证接口：https://cas.example.com/cas/serviceValidate?service=http%3A%2F%2Fapp-a.example.com%2Fmain&ticket=ST-20240520-xxxxx
CAS Server 核验 ST 有效、且 service 参数与签发时一致，返回一段 XML（或 JSON），里面包含用户名、属性等信息。CAS Client 解析后，在业务系统本地创建 Session，并把用户信息写入 Session。
业务系统重定向去除地址栏中的ticket参数（这一步很重要，避免 ST 暴露在浏览器历史记录里），浏览器最终看到的是干净的http://app-a.example.com/main，用户处于登录状态。

提示：ST 是一次性的，CAS Server 验证过一次之后立即失效。所以如果 CAS Client 重复去验证同一个 ticket，会得到INVALID_TICKET的错误。这也是排查问题时需要留神的一个点。

3.2 第二次访问其他系统，静默登录的实现

用户登录过 A 系统后，再去访问业务系统 B，流程缩短为：

浏览器访问业务系统 B，被拦截，302 跳转到 CAS Server 的/login?service=...B的地址...。
浏览器带着 TGC Cookie 访问 CAS Server，CAS Server 检查 TGC 对应的 TGT 是否有效（未过期、未被销毁）。
如果有效，CAS Server 不展示登录页，直接生成一个新的 ST，302 重定向回业务系统 B。
业务系统 B 后面的流程和首次登录完全一致：拿 ST 去验证、建本地 Session、去掉 ticket 参数。

整个过程用户无感知，浏览器从点击 B 系统的链接到看到 B 系统首页，可能就一两秒钟，中间地址栏快速闪几下。这就是 SSO 的“一次登录，处处漫游”体验。

3.3 登出：如何做到“一处退出，处处退出”

登出是很多人容易忽略的问题。如果用户在 CAS Server 点了退出，只销毁了 TGT，但业务系统 A 和 B 的本地 Session 还在，用户再去访问 A 系统时，CAS Client 发现本地有 Session 就直接放行了，造成“退出失效”的假象。

CAS 的单点登出（Single Log Out，SLO）原理是：CAS Server 在销毁 TGT 之前，会记录这个 TGT 曾经给哪些 service 签发过 ST（这个列表叫 Registered Services），然后向这些 service 的回调地址发送一个 LogoutRequest 消息（SOAP 或 HTTP 方式），通知各个业务系统销毁本地 Session。业务系统需要实现这个回调接口才能完成真正的单点登出。

不过实话说，SLO 在真实环境里属于“理想很丰满，现实很骨感”的功能，跨域、网络隔离、系统未实现回调接口等原因经常导致登出不彻底。我的经验是：在内部系统中单点登录是刚需，单点登出往往容忍度较高，能保证 CAS Server 侧的 TGT 销毁，再保证核心系统的本地 Session 同步销毁，基本够用了。

4. 动手部署一个生产可用的 CAS Server

4.1 版本选型：经典 Apereo CAS 6.6.x 实践

目前社区活跃度最高的是 Apereo CAS，Java 技术栈，版本迭代到现在已经到 6.6.x（更高版本也有，但 6.6 资料最全、案例最多，适合大多数内部项目）。有些人会觉得 Java 重，但 CAS Server 本身是可以打成 WAR 包丢进 Tomcat 跑的，运营成本并不高。如果你的环境偏好更轻量，也可以找一些社区重写的 Go、Python 版本，但它们对协议细节的覆盖程度参差不齐，我建议生产环境还是优先用 Apereo CAS 官方版本，省得在诡异的边界行为上踩坑。

4.2 部署方式与核心配置

Apereo CAS 6.6 官方主推的是 Overlay 方式，意思是你下载一个空壳工程，把自己需要的模块以依赖的方式加进去，最后构建出一个自定义的 WAR 包。这种方式的好处是：官方升级时你只需要切换依赖版本，自己写的配置代码不受影响。

构建完部署到 Tomcat，第一件要改的事情是 HTTPS。CAS 安全规范要求生产环境必须走 HTTPS，这是硬性要求，不是建议——因为 TGT、ST 都是敏感凭证，明文传输等于裸奔。内部环境如果确实没有正规证书，可以用自签证书，但所有客户端都要信任该 CA，这又是一个工作量点。

核心配置集中在application.properties里，常见的关键配置项如下：

# 服务端基础地址，所有回调都会基于这个地址拼接 cas.server.name=https://cas.example.com cas.server.prefix=${cas.server.name}/cas # 登录成功后的默认跳转地址 cas.view.default-redirect-url=https://app-a.example.com/index # TGT 超时时间，单位秒（默认 8 小时） cas.tgt.max-time-to-live-in-seconds=28800 cas.tgt.time-to-kill-in-seconds=7200 # ST 有效期，单位秒 cas.ticket.st.time-to-kill-in-seconds=60 # 允许的 service 白名单，未匹配到的 service 直接拒绝 cas.service-registry.json.location=file:/etc/cas/services/ # 认证方式，这里用 JDBC 查用户表 cas.authn.jdbc.query[0].url=jdbc:mysql://127.0.0.1:3306/cas_db?useUnicode=true&characterEncoding=utf8 cas.authn.jdbc.query[0].user=cas_user cas.authn.jdbc.query[0].password=your_password cas.authn.jdbc.query[0].sql=SELECT * FROM sys_user WHERE login_name = ? cas.authn.jdbc.query[0].password-encoder.type=bcrypt

4.3 Service 注册：控制哪些系统可以接入

Service 注册是 CAS Server 侧的一道闸门。新接入的业务系统必须在服务注册表里登记自己的 service 地址前缀，CAS Server 才会给这个系统签发 ST。好处是防止有人恶意构造 service 参数，让 CAS 往自己控制的地址发票据。

在services目录下一个 JSON 文件对应一个业务系统，示例：

{ "@class": "org.apereo.cas.services.RegexRegisteredService", "serviceId": "^http://app-a\\.example\\.com/.*", "name": "App A", "id": 100001, "evaluationOrder": 1, "attributeReleasePolicy": { "@class": "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy", "allowedAttributes": { "@class": "java.util.TreeMap", "uid": "username", "displayName": "cn", "email": "mail" } } }

这里面的attributeReleasePolicy很关键。不少业务系统的本地用户表里需要邮箱、部门信息，CAS Server 验证 ST 时可以返回这些属性，但必须在 Service 注册表里声明允许释放哪些属性，保护用户隐私。默认情况下 CAS 只会放行用户名，想要更多属性需要显式配置映射。

4.4 用户认证源：从内存用户到数据库再到 LDAP

开发环境可以先用内存用户：

cas.authn.accept.users=casuser::Mellon

生产环境一般对接数据库或 LDAP（公司统一账号体系通常是 AD 域）。用 JDBC 配置时要注意密码加密方式的一致性，常见的有 bcrypt、MD5（不推荐但老系统常见）、SHA 系列。如果老系统的密码是 MD5 存的，CAS 侧需要配置 MD5 encoder，但建议顺带做一个“首次登录强制改密”的过渡方案，慢慢平滑迁移到 bcrypt。

5. 业务系统接入 CAS 的完整实操

5.1 Java 生态：Spring Boot + CAS 的最快姿势

Java 后端接入 CAS，我个人最推荐的方式是 Spring Boot 全家桶，用 Spring Security CAS 单点登录模块。在pom.xml里加依赖：

<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-cas</artifactId> <version>5.8.11</version> </dependency>

配置核心就三件事：定义 Service 地址、定义 CAS Server 地址、写一个 UserDetailsService 从 ST 返回的用户名去本地库加载权限。

@Configuration @EnableWebSecurity public class CasSecurityConfig { @Bean public ServiceProperties serviceProperties() { ServiceProperties sp = new ServiceProperties(); sp.setService("http://app-a.example.com:8080/login/cas"); sp.setSendRenew(false); return sp; } @Bean public CasAuthenticationEntryPoint casEntryPoint(ServiceProperties sp) { CasAuthenticationEntryPoint entryPoint = new CasAuthenticationEntryPoint(); entryPoint.setLoginUrl("https://cas.example.com/cas/login"); entryPoint.setServiceProperties(sp); return entryPoint; } @Bean public CasAuthenticationFilter casAuthenticationFilter(ServiceProperties sp, AuthenticationManager authManager) { CasAuthenticationFilter filter = new CasAuthenticationFilter(); filter.setServiceProperties(sp); filter.setAuthenticationManager(authManager); filter.setFilterProcessesUrl("/login/cas"); return filter; } @Bean public CasAuthenticationProvider casAuthenticationProvider() { CasAuthenticationProvider provider = new CasAuthenticationProvider(); provider.setServiceProperties(serviceProperties()); provider.setTicketValidator(new Cas30ServiceTicketValidator("https://cas.example.com/cas")); provider.setUserDetailsService(new CustomUserDetailsService()); provider.setKey("cas-auth-provider-key"); return provider; } }

要注意${server.address}是app-a.example.com:8080，serviceProperties 里的地址必须和 CAS Serverservice参数的地址完全一致，包括端口和路径。很多对接问题都是这个地址不一致导致的。

5.2 非 Java 系统：Python/Node 怎么接入

如果不是 Java 生态，CAS 官方没有统一客户端，但社区方案成熟。Python 推荐用python-cas库，Node.js 可以用cas-authentication。原理大同小异：

写一个中间件拦截所有请求；
检查 Session 里是否有用户；
没有则重定向到 CAS Server 的 login 地址，带上当前地址作为 service；
捕获回调请求里的 ticket 参数，用 requests 或 http 模块调用/serviceValidate验证；
验证通过后解析 XML/JSON 里的用户名，写进 Session。

Python 的代码骨架：

from flask import Flask, request, redirect, session from cas import CASClient app = Flask(__name__) app.secret_key = 'some-secret' cas_client = CASClient( version=3, server_url='https://cas.example.com/cas', service_url='http://app-b.example.com:5000/login' ) @app.route('/login') def login(): ticket = request.args.get('ticket') if not ticket: return redirect(cas_client.get_login_url()) user, attributes, pgtiou = cas_client.verify_ticket(ticket) if user: session['user'] = user return redirect('/') return '登录失败', 401 @app.before_request def check_login(): if request.endpoint == 'login': return None if 'user' not in session: return redirect('/login')

Node.js 的cas-authentication也是类似的中间件思路。重点在于service_url参数的一致性，很多联调问题都是这个地址写错。

5.3 前端页面改造与登录按钮的隐藏逻辑

前端关心的核心问题是：什么时候显示“登录”按钮，什么时候显示当前用户名。做法通常是后端在渲染模板时把当前用户信息塞进去：

用户已登录：页面右上角显示用户名、退出按钮；
用户未登录：显示“登录”按钮，点击后跳转https://cas.example.com/cas/login?service=当前页面地址；
前端拿到 401/302 响应时，不要盲目弹提示，应该触发跳转登录。

如果业务系统是前后端分离架构（Vue/React + 后端 API），需要额外注意。CAS 是基于服务端渲染的重定向流程，前后端分离时有两种常见方案：

方案一：网关层做 CAS Client，浏览器访问页面时由网关完成 CAS 登录，登录后把用户信息通过 HTTP Header 传给后端 API。
方案二：前端直接和后端约定一个/auth/cas/login接口，后端返回 302 重定向地址，前端用window.location.href跳转，登录成功后service参数指回一个前端页面，再由前端校验登录态后继续访问 API。

方案二更常见，但要注意前端路由的service参数不能带 hash（很多 SPA 用 history 模式，hash 不会被发送到服务端），会被截断导致回跳地址不对。

6. 生产环境里那些不得不防的坑

6.1 ST 过期与时钟同步问题

ST 默认有效期只有 60 秒，这在现代网络环境下通常够用，但有两个隐患：

应用服务器和 CAS 服务器的系统时间不同步，会导致 ST 验证时出现“未来时间戳无效”的问题。这种问题表现很诡异，验证接口报INVALID_TICKET，查日志发现时间戳差了十几分钟。解决方法是统一用 NTP 同步时间。
浏览器端到 CAS Server、CAS Server 到 Client 之间还有网络延迟，如果 ST 有效期设得太短（比如 10 秒），在极端网络下也会出现过期。经验值是 60 秒到 120 秒比较稳。

6.2 回调地址比对失败

serviceValidate接口验证时对比的 service 参数，必须是签发 ST 时使用的 service 参数，完全一致，一个字符都不能差。常见坑有：

HTTPS 和 HTTP 混杂，应用通过 HTTP 访问，配置里写了 HTTPS；
端口不一致，应用实际跑在 8080，service 参数写成了 80；
末尾斜杠差异，http://app-a.com/main和http://app-a.com/main/是两个不同地址；
域名用了 IP 和域名混写，http://127.0.0.1:8080和http://app-a.com:8080校验不过。

排查时先把两个地址打印出来逐字符比对，比瞎猜快得多。

6.3 用户属性获取不到

很多业务系统不仅需要用户名，还需要邮箱、部门、手机号。如果发现拿不到属性，按这个顺序排查：

CAS Server 的用户源（数据库/LDAP/AD）里有没有这些属性；
CAS 用户配置里有没有启用属性解析器；
Service 注册表的attributeReleasePolicy里有没有声明释放；
业务系统的 TicketValidator 是否配置了需要返回属性（Java 端默认 CAS 3.0 协议会返回，旧版需开启）。

其中第 3 点是最容易漏的，我刚接触的时候在 CAS Server 配了属性，却忘了在 Service 注册表里放行，结果客户端一直拿不到。

6.4 分布式会话下的 TGT 存储

如果 CAS Server 做了集群部署，TGT 不能存在单机内存里，否则请求被负载均衡到另一台机器时，从 TGC 找不到对应的 TGT，用户被反复要求登录。解决方案：

使用 Redis 存储 TGT，配置cas.ticket.registry.redis相关参数；
或使用数据库存储（性能较差，不推荐高频场景）；
使用 Hazelcast/Infinispan 等分布式缓存，集成复杂度略高。

我见过不少小团队把 CAS Server 单机部署在虚拟机里，觉得没必要做集群。但如果你的用户量超过几千人，或者绑定了关键业务系统，建议至少做一主一备 + Redis 共享 TGT，避免单点故障导致全员无法登录。

6.5 回调地址泄露与 CSRF 防护

CAS 登录接口没有做内置 CSRF Token，这是协议设计的简化。实际项目中可以靠以下手段缓解：

CAS Server 侧开启cas.theme.allow-flow-customization时谨慎暴露自定义 JS，防止被注入恶意代码；
业务系统的回调地址必须做白名单校验，不能让登录接口接受任意service地址；
Service 注册表 URL 匹配尽量用精确的正则，避免.*这种宽松匹配。

7. 常见问题排查速查表

现象	可能原因	排查方法
访问业务系统无限重定向	业务系统未信任 HTTPS 证书，或 service 地址不匹配	查看 CAS Client 日志，把 service 参数打印出来比对
登录页能出，点登录没反应	数据库连接异常、密码编码器不一致	查看 CAS Server 日志中的`AuthenticationException`，检查 JDBC 配置
提示`INVALID_TICKET`	ST 已过期、重复验证、时钟不同步	确认有效期，检查是否重复调用验证接口，NTP 同步时间
提示`INVALID_SERVICE`	service 参数与注册表不匹配	用浏览器 F12 看地址栏，复制到注册表正则里测试
登录成功后跳回原地址，报 403	业务系统本地 Session 创建失败，或权限初始化失败	查看业务系统日志，确认 UserDetailsService 是否能从用户名加载到权限
单点登出无效	业务系统没实现登出回调接口	检查 logout 参数，或实现`/logout/cas`回调接口
属性为空	attributeReleasePolicy 未配置	检查 Service 注册表 JSON 和 CAS 用户属性解析器

排查问题有一个通用的建议：先看 CAS Server 的日志，再看 CAS Client 的日志。CAS Server 收到验证请求时会有完整的 ticket 校验过程日志，能明确告诉你失败原因；CAS Client 的日志则能看到它准备把用户重定向到哪里去、验证结果是什么。两端日志一对照，80% 的问题都能定位。

8. 安全加固与性能优化的最后几件事

8.1 核心安全配置项

生产环境必须检查这么几项：

强制 HTTPS：所有 service 地址和登录地址必须是 HTTPS。
ST 过期时间：短一些，尽量 60 秒。防止票据被窃取后长时间有效。
TGC 设置 Secure + HttpOnly 标志：Apereo CAS 默认会设置，但要确认。HttpOnly 防 XSS 读取 Cookie，Secure 防明文 HTTP 传输。
限制 service 匹配正则：不要用.*这种全匹配，不然攻击者可以构造任何地址来获取 ST。
启用密码策略策略模块：如密码过期提醒、连续输错锁定，CAS 提供cas.authn.password-policy相关配置，需要启用。

8.2 性能考量：不要忽略一次认证的额外请求

CAS 接入后，每次新会话首次访问业务系统，需要额外发起一次serviceValidate请求到 CAS Server。如果业务系统是短连接频繁创建会话的场景，这个开销会明显放大。优化手段：

业务系统本地 Session 超时时间配长一点（比如 8 小时），避免频繁回 CAS 验证；
CAS Server 和业务系统之间走内网专用域名访问，减少公网延迟；
业务系统本地做好 Session 缓存，不要每次请求都去查数据库。

8.3 日志监控与告警

CAS Server 一定要配置好日志留存和监控告警。建议至少监控这几个指标：

serviceValidate成功率：低于 95% 说明有大量系统对接异常；
TGT 创建速率：突增可能意味着遭遇撞库；
失败认证次数：连续失败超过阈值要告警；
登出请求数：异常增多的可能是登出回调风暴。

把这些指标接入现有监控体系（Prometheus + Grafana 或 Zabbix 都可以），能大幅降低被问题时才知道系统挂了的情况。

9. 经验心得总结与设计建议

我在实际部署 CAS 过程中最深的一个体会是：单点登录的技术难点从来不在服务端，而在与各个业务系统的接入规范上。CAS Server 部署好后，后面数十个业务系统接入，如果每个系统对接人理解不一致，就会出现各种千奇百怪的问题：有的把 service 地址带上了 URL 编码导致匹配失败，有的回调地址填的是本机 localhost，还有的直接在浏览器地址栏手动构造 ticket 参数去访问（那当然会失败）。

所以我强烈建议在项目初期制定一份内部对接文档，明确：

业务系统接入的 service 地址填写规范（统一 HTTPS、统一域名、明确端口）；
回调地址匹配规则（HTTP 还是 HTTPS，路径是否包含末尾斜杠）；
用户信息属性的映射字典（统一属性名，避免 A 系统叫email，B 系统叫mail）；
联调步骤和常见报错处理清单。

这份文档能替你省掉大量重复答疑的时间。

另外，如果公司内部系统复杂，比如同时存在老式 JSP 系统、前后端分离新系统、第三方商业系统，我建议采用分阶段的接入策略：

第一批接入 2-3 个核心系统，验证流程和配置的标准化；
第二批接入重活系统，解决属性映射、权限同步等细节；
最后再接入边缘系统，有些老系统如果实在改不动，可以考虑用一个轻量反向代理包一层认证，代理完成 CAS 登录后把用户信息透传给老系统。

回头看，CAS 的设计虽然有年头了，但它的核心思想——把认证从业务系统中剥离出来，统一管理、统一发放凭证、统一登出——至今仍然是企业内部统一身份认证的基石。理解清楚 TGT、ST、TGC 这几个概念和一条完整的重定向链路，后续无论用 Apereo CAS 还是其他类 CAS 协议的产品，都会轻松很多。我现在每接到一个统一登录需求，第一反应还是先想想 CAS 这套方案能不能复用，因为它的稳定性和生态，真的对得起“好帮手”这三个字。

CAS单点登录从原理到实战：TGT/ST票据交互与系统接入全解析