为什么你的账号总在多个系统反复登录？揭秘账号在多系统间反复登录的原因
不知道你们有没有这样的经历？早上刚登录了公司OA系统，打开报销平台又要重新输密码；好不容易填完报销单，进财务系统又跳出一堆验证码... 这时候总想拍桌子问：为什么不能像逛淘宝一样，登录一次全平台通用？ 其实这就是单点登录（SSO）要解决的问题。今天咱们就掰开了揉碎了，聊聊新手也能懂的CAS和OAuth2实现方案。
一、单点登录究竟怎么"偷懒"的？
想象一下你带着迪士尼通票进游乐场——买一次票就能玩遍所有项目。单点登录就是这个原理：用户只需在中央认证系统登录一次，就能访问所有关联应用。比如京东用同一套账号体系打通了商城、金融、物流，背后就是SSO在运作。
但具体怎么实现呢？目前主流的两种方案就像超市结账通道：
- CAS通道：企业自建的专用通道（适合内部系统）
- OAuth2通道：第三方合作的VIP通道（适合跨平台登录）
二、CAS：企业级"员工卡"系统
CAS（中央认证服务）相当于给每个员工发张万能工牌。咱们通过实际案例看流程：
- 小王第一次访问报销系统，系统发现他没"工牌"（TGC Cookie），直接把他推到认证中心登录页
- 输入账号密码后，认证中心给他两个凭证：TGT（长期通行证）存在服务端，TGC（工牌芯片）塞进浏览器Cookie
- 当他再点开OA系统时，系统自动拿着TGC去认证中心换临时门票（ST），全程无需重复登录
这里有个关键点：ST就像电影票，只能用一次且5分钟过期。这样既保证安全，又能避免黑客截取凭证后无限使用。
三、OAuth2：互联网界的"门禁卡互认"
如果说CAS是封闭小区门禁，OAuth2就是写字楼间的通行协议。最常见的微信扫码登录就是典型场景：
- 你想用知乎看文章，但懒得注册新账号
- 选择"微信登录"后，知乎会带你跳转到微信的授权页面
- 同意授权后，微信发给知乎两张票：access_token（短期通行证）和refresh_token（续期凭证）
这里特别要注意授权码模式的安全设计：
- 知乎先拿临时code换token，避免密码直接暴露
- token权限被严格限制（比如只能获取头像昵称）
- 每次token请求都需验证客户端密钥，像银行U盾一样双重保险
四、到底该选哪个方案？
通过对比表格来看差异：
| 对比项 | CAS | OAuth2 |
|---|---|---|
| 适用场景 | 企业内部系统 | 跨平台合作 |
| 认证方式 | 账号密码直接认证 | 第三方间接授权 |
| 安全机制 | 票据一次性使用 | HTTPS+动态令牌 |
| 典型应用 | 高校选课系统 | 微信/QQ快捷登录 |
| 开发成本 | 需部署认证中心 | 对接开放平台接口 |
如果是开发内部管理系统，CAS像定制西装——完全自主可控；要做第三方登录，OAuth2就是现成礼服——直接套用大厂方案更省事。
五、新手最常踩的三大坑
Q：为什么我照着教程配CAS，总出现循环跳转？
A：八成是Cookie域名冲突。比如前端用a.com，后端用b.com，两个系统互相覆盖session。解决办法就像给快递贴标签——给不同系统Cookie加上专属域名前缀。
Q：OAuth2的四种模式到底用哪个？
A：记住这个口诀：授权码保安全（网站应用）、隐藏式图方便（纯前端）、密码式别乱用（自家APP）、凭证式管后台（服务器对接）。95%的场景选授权码模式准没错。
Q：单点登录会不会降低安全性？
A：恰恰相反！统一认证就像给大楼装中央监控，比每个房间单独装警报器更易维护。但要注意两点：强制HTTPS加密传输，定期轮换加密密钥，就像银行每隔段时间就换保险库密码。
写着写着突然想起个事——去年帮朋友公司做系统集成，他们非要把CAS和OAuth2混着用，结果搞出个四不像。其实技术选型就像炒菜，不是调料越多越好。找准业务需求，用最简单的方案解决问题，才是工程师该有的思维。