背景刚入职1 派了个活多个三方系统登录入口统一。过程我刚接到时一脸懵逼没搞过怎么办管他呢先答应不得不感叹还好有 AI不然我这试用期可能就黄了也不是说搞不出来但会耗费大量时间跟精力结果搞出来不过是一个入口而已跟自己职级的承重不匹配。接到这个需求之后首先了解了各个项目的认证逻辑之前没怎么接触过认证的工作内容都是根据接口规范要 token 就传 token 好了至于 token 怎么来认证怎么实现都没有沉下心来去学习。既然这次有这个机会那就补一下技术债吧。总结下浏览器登录一般有两种认证方式cookie-sessin、token。1. cookie 浏览器自带的功能浏览器发起的请求会把 cookie 自动封住起来发给后端cookie 存放的信息是用户相关的我了解到比较关键的是 sessionId后端会存放 session用户请求过来之后便知道是谁了。2. token则是请求时带上 token后端校验属于无状态的。随着对项目的了解我发现每个系统的账号体系不同有手机号作为登录账号的有 LDAP 账号的还有其他开源组件例如Jenkins、Grafna。知道各个系统的认证实现后自己刚开始的思路是调研热度较高的开源项目看是否能融合进这个场景。我研究过的开源项目有两个分别是Authentik和Keycloak。下面分别介绍一下它们的特点和我的调研考虑下面的内容是 AI 助手生成的Authentik定位现代化的身份提供商IdP与访问管理平台专为云原生和容器化环境设计。核心功能支持 OAuth2、OIDC、SAML、LDAP 等多种协议可作为统一的认证网关。提供可视化的流Flows编辑器通过拖拽方式配置认证、注册、密码重置等流程。内置策略引擎支持基于属性、组、时间等条件的细粒度访问控制。提供 Webhook、SCIM 等集成接口便于与第三方系统对接。适用场景适合需要高度可定制认证流程、希望统一管理多个应用登录入口的场景尤其对 Kubernetes、Docker 等云原生环境友好。Keycloak定位由 Red Hat 开源的身份和访问管理解决方案功能全面、企业级成熟。核心功能开箱即用的用户管理、角色管理、组管理界面。支持 OAuth2、OIDC、SAML、Kerberos 等协议并自带登录、注册、账户管理页面。提供主题定制可整体更换登录页样式。支持社交登录Google、GitHub 等、双因素认证2FA。自带管理控制台无需额外开发即可配置客户端、范围、权限。适用场景适合需要快速搭建统一登录门户、对协议支持要求全面、希望减少自开发工作量的企业级项目。为什么调研这两个项目开源热度两者在 GitHub 上 star 数较高社区活跃文档相对完善。协议覆盖都支持 OAuth2、OIDC、SAML 等主流协议能够对接大多数现有系统如 Jenkins、Grafana 等。可扩展性提供 REST API、SPI服务提供接口等扩展机制便于二次开发或定制。部署灵活均提供 Docker 镜像支持 Kubernetes 部署符合现代运维习惯。初步评估后我发现这两个项目都能在一定程度上解决“多个三方系统登录入口统一”的问题但具体选型还需要结合公司现有的技术栈、运维能力和后续扩展需求来定。例如如果团队更熟悉 Java 生态、希望快速上线Keycloak 可能更合适如果追求更灵活的流程编排和云原生集成Authentik 值得深入尝试。基于上述的分析我个人直觉是选 Authentik因为他简单、轻量化、UI更润也做好了方案验证。大概的实施方向是各个第三方系统保留原有账号体系但需要支持 OIDC 协议通过此协议接入 Authentik。但在方案评审时被否定了。其实 1 的需求是使用最简单的方式实现跳转即可当然要支持多个系统的跳转。随后自己又阴差阳错的想到了 Spring Cloud Gateway想想真是欠思考了Gateway 的原理是按配置的断言规则路由不同的系统之间的 path 区别不明显甚至有交错相同的。自己就实施了一个系统当然能完成跳转关于原理其实之前是清楚的但当时急于求成想尽快推进这点被我忽略了。看来想达到琴水玉老师博客的水平还是差远了。随后又进行了第三版的方案设计用最原始的办法手撸一个前后端应用点击某个系统跳转时直接重定向到该系统主页需要的 token 放 url 的 token 参数上类似http://example.com?tokenxxxx。这样的话第三方系统里只需要支持前端支持带 token 的 url 跳转。说到这里需要提到一个跨域问题虽然 302 不会涉及跨域问题但在几次的方案讨论中同事们有提到过其实自己之前也听过但未花时间研究。这次也小补了一下谷歌为了安全在浏览器中加了跨域检测机制一旦检测到请求跨域其 cookie 时无法共享的。看过一个小故事小李如往常一样浏览自己的谷歌邮箱内容基本都是验证码邮件无聊的滚动着邮件列表突然发现了一条内容为“比特币活动只要98”的邮件这让小李眼前一亮未作过多思考便点击了页面跳出的空白页面本身也没报太大期待随后关闭了页面。这件事情过了半个月之后小李突然收到一封匿名邮件内容是xxx 元赎回 yyy 域名。小李恍然大悟之前点击的空白页面其实是攻击链接点击后以小李的认证信息开启邮件的某个机制每次收发邮件都会触发此机制将认证信息暴露到第三方地址。就这样整个攻击事情被归类为跨域攻击google 后续修复了这个问题所以正在阅读的你不需要太担心。扯远了一点总结下来只要协议、域名、端口任意元素发生了变化都会被识别为跨域。不过 302 是页面重定向不会涉及的。剩下的内容其实就是平台的常用功能了例如用户管理、角色管理、平台账号与第三方系统权限的映射关系管理。设计内容包括接口、库表结构定义、灰度节奏等。终于 tm 的过了本次需求不难却暴露了不少问题。第一点对于常见的 Web 开发技术知识掌握不牢固比如跨域、认证方式没有系统的认识以往专注的业务功能开发对每天都接触到的登录认证确实疏忽再疏忽。第二点整个方案设计周期太长自己思考其原因是应该隔一两天找 1 对齐方向能及时调整方向避免在错误的方向上花太多时间比如本文中提到的关于开源项目的方案验证最终并没有用上一丁点。关于第二点我也为自己找了点开脱由于新环境还没掌握如何高频次与 1 沟通哈哈。但想成为琴水玉老师一样的牛人这点不应该成为绊脚石应该努力提升沟通能力努力尝试中目前采用的办法是发言沟通有意识的留意自己的表现且发言前尽量的自己重复几遍还有写作。方案设计完成之后进入开发阶段这里不得不感叹 AI 编程的强大。入职以来从未写过一行代码连看的可能都不超过 10 行。每天跟 chatGPT 交互的时间占了 80% 左右沟通能力不知道会不会更弱了呀大概一周完成整个平台的开发、测试工作并且在测试环境联调接入了一个第三方系统自己觉得可能还能更快因为一部分时间花在环境的熟悉上面。总结截止现在还未上线此 SSO 平台但功能基本 OK。准备本周部署到正式环境让大家使用起来。忽然觉得 AI 编程什么都能干那人干什么呢现在还没有实现全自动化再将来肯定是全自动化发展的那自己的学习方向应该是什么呢迷茫中…下面是我让右侧 AI 助手生产的右侧推荐的功能试试效果吧。认证方式对比为了更清晰地理解两种认证方式的差异下面是一个对比表格对比维度Cookie-SessionToken (如 JWT)存储位置Cookie 存储在浏览器端Session 存储在服务器端内存、Redis等Token 存储在客户端LocalStorage、Cookie 或内存状态管理有状态服务器需要保存 Session 状态无状态服务器不保存状态Token 自包含安全性依赖 HTTPS 防窃听Session ID 可能被劫持XSS/CSRF需要 HTTPS 防窃听Token 可能被窃取XSS但可设置较短有效期适用场景传统 Web 应用需要服务器端状态管理的场景前后端分离、分布式系统、移动端、API 调用优点1. 浏览器自动管理 Cookie2. 服务器可主动销毁 Session3. 适合需要服务器控制会话的场景1. 无状态扩展性好2. 适合跨域、分布式部署3. 可携带自定义声明Claims缺点1. 服务器存储开销2. 跨域限制需配置 CORS/域名3. 易受 CSRF 攻击需额外防护1. Token 一旦签发在有效期内无法主动失效需黑名单或短有效期2. 体积可能较大尤其携带大量声明时3. 需客户端代码手动处理存储和发送简单来说Cookie-Session更适合传统的服务器渲染 Web 应用服务器需要完全控制会话生命周期。Token更适合现代前后端分离架构、分布式微服务以及需要跨域认证的场景。