单点登录这个词做过中后台系统的人应该都不陌生。早期我们给内部做统一认证最土的办法是每个子系统各存一份用户表用户在每个系统里各注册一遍密码规则还不一样运维起来简直是灾难。后来大家学聪明了搞一个统一的认证中心所有子系统都跳到这里登录登录完再跳回去这就是单点登录SSO最朴素的样子。而 OAuth2 是目前落地 SSO 最主流的一套授权框架它本身不是协议而是一个授权委托的标准核心思想是让用户把证明自己是谁这件事委托给一个可信的第三方业务系统只拿授权结果不碰用户密码。这篇文章我想聊的不是 OAuth2 的 RFC 文档翻译而是我在实际项目里把 OAuth2 落地成 SSO 时踩过的坑、做过的取舍以及那些文档里不会写但线上一定会遇到的问题。适合正在做统一认证、准备接入第三方登录、或者被多系统登录态同步折磨过的开发者。如果你只是想知道OAuth2 有哪四种模式那网上随便一搜都是但如果你想知道为什么我用了授权码模式还是被安全扫描挑出一堆问题那这篇应该能帮到你。1. 先把 OAuth2 和 SSO 的关系理清楚很多人一上来就把 OAuth2 和 SSO 画等号这是个很常见的认知偏差。OAuth2 解决的是授权问题SSO 解决的是认证问题两者目标不一样只是经常被组合使用。理解这一点后面很多设计决策才不会跑偏。1.1 授权和认证到底差在哪举个生活化的例子。认证就像你进小区大门时刷门禁卡物业确认你是这个小区的业主授权则是你进了小区之后能不能进健身房、能不能用游泳池这是权限范围的问题。OAuth2 的设计初衷是让第三方应用在不拿到用户密码的前提下获得访问用户某些资源的权限比如允许某应用读取我的头像和昵称。那为什么 OAuth2 能做 SSO 呢因为 OAuth2 的授权码模式里有一个关键角色叫授权服务器它负责验证用户身份并颁发令牌。如果我们把这个授权服务器当成统一的认证中心各个业务系统当成 OAuth2 里的客户端那么用户只需要在授权服务器登录一次之后访问其他系统时授权服务器发现已有登录态直接颁发新的授权码用户就无感跳转过去了。这就是 OAuth2 实现 SSO 的本质。注意OAuth2 本身没有定义用户信息的标准格式所以实践中通常会配合 OIDCOpenID Connect一起用OIDC 在 OAuth2 之上加了一层身份层提供了 ID Token 和 UserInfo 接口这才是完整的 SSO 方案。1.2 为什么不用 SAML 或者 CAS老牌的 SSO 方案里SAML 和 CAS 都比 OAuth2 资历老。SAML 基于 XML配置繁琐报文体积大移动端支持不友好CAS 是耶鲁大学搞的协议简单但生态相对封闭主要用在教育领域。OAuth2 的优势在于JSON 格式轻量、移动端和前后端分离场景支持好、生态成熟、几乎所有主流语言都有现成的库。我做过一个对比同样是接入三个子系统用 CAS 大概要写三套客户端配置每套都得处理票据校验和 XML 解析用 OAuth2 的话客户端只需要配置四个参数client_id、client_secret、授权端点、令牌端点剩下的交给库处理。当然OAuth2 也不是没有代价它的灵活性带来了更多配置项稍不注意就会配出安全漏洞这个后面会详细讲。对比维度SAMLCASOAuth2 OIDC报文格式XMLXML/自定义JSON移动端支持差一般好前后端分离不友好一般友好生态成熟度企业级教育领域全领域学习曲线陡平缓中等2. 授权码模式为什么是 SSO 的唯一正解OAuth2 有四种授权模式授权码、隐式、密码、客户端凭证。做 SSO 的时候只有授权码模式是推荐使用的其他三种要么不安全要么不适用。这一章我把为什么这么选讲透。2.1 四种模式的适用场景拆解授权码模式用户跳转到授权服务器登录后授权服务器返回一个临时的 code客户端拿 code 去换 access_token。这个 code 是一次性的、短时效的即使被截获攻击者没有 client_secret 也换不到令牌。这是最安全的模式适合有服务端的应用。隐式模式授权服务器直接把 access_token 放在 URL 片段里返回。这个模式是给纯前端应用设计的但令牌暴露在浏览器历史里安全性差现在已经被 OIDC 的授权码 PKCE 模式取代了。密码模式用户把用户名密码直接给客户端客户端拿去换令牌。这个模式要求客户端完全可信一般只用于自家官方应用做 SSO 时绝对不能用因为业务系统不应该接触用户密码。客户端凭证模式没有用户参与纯粹是服务间调用。做 SSO 用不上。所以结论很明确做 SSO认准授权码模式如果是纯前端应用用授权码 PKCE。2.2 授权码模式的完整交互链路我把一次完整的 SSO 登录拆成八步每一步都有它的意义用户访问业务系统 AA 发现用户未登录生成一个 state 参数重定向到授权服务器的授权端点。授权服务器检查用户是否有登录态没有则展示登录页。用户输入凭证授权服务器验证通过建立自己的会话通常是写一个 Cookie。授权服务器生成一个一次性 code重定向回业务系统 A 的回调地址带上 code 和 state。业务系统 A 校验 state 是否一致防 CSRF然后用 code client_id client_secret 去令牌端点换令牌。授权服务器校验 code 和客户端凭证颁发 access_token 和 id_token。业务系统 A 用 id_token 解析用户身份建立自己的会话。用户访问业务系统 BB 同样重定向到授权服务器授权服务器发现用户已有登录态直接颁发新 code用户无感登录。这里面state 参数和code 一次性是两个关键安全设计。state 防止跨站请求伪造code 一次性防止重放攻击。我见过有团队为了省事把 state 写死成固定值这等于把 CSRF 防护直接废掉了。2.3 PKCE 到底解决了什么问题PKCEProof Key for Code Exchange是授权码模式的一个扩展专门防授权码拦截攻击。它的原理是客户端在发起授权请求时生成一个随机的 code_verifier把它哈希后作为 code_challenge 一起发过去换令牌时再把原始的 code_verifier 带上授权服务器比对哈希值是否匹配。为什么需要这个因为对于公开客户端比如纯前端应用、移动 Appclient_secret 没法安全保存攻击者如果能截获授权码就能直接换令牌。加了 PKCE 之后攻击者没有 code_verifier即使拿到 code 也换不了令牌。// 生成 PKCE 参数的示例 function generateCodeVerifier() { const array new Uint8Array(32); crypto.getRandomValues(array); return base64UrlEncode(array); } async function generateCodeChallenge(verifier) { const encoder new TextEncoder(); const data encoder.encode(verifier); const digest await crypto.subtle.digest(SHA-256, data); return base64UrlEncode(new Uint8Array(digest)); }实测下来PKCE 的计算开销可以忽略不计但安全收益很大现在 OAuth 2.1 草案已经把 PKCE 列为授权码模式的强制要求了。3. 令牌设计JWT 不是万能药令牌是 OAuth2 的核心产物设计得好不好直接决定了系统的安全性和可维护性。很多团队一上来就用 JWT觉得无状态、可自包含很香但用着用着就发现坑不少。3.1 access_token 和 refresh_token 的分工access_token 是访问资源的凭证有效期应该短一般 15 分钟到 2 小时refresh_token 用来刷新 access_token有效期可以长一些比如 7 天到 30 天。这样设计的原因是access_token 使用频繁暴露风险高短有效期能降低泄露后的危害refresh_token 使用频率低可以配合更严格的存储和轮换策略。我见过有团队把 access_token 有效期设成 7 天理由是减少刷新次数提升体验。这其实是个危险的取舍一旦令牌泄露攻击者能用的时间窗口太长了。正确的做法是缩短 access_token 有效期用 refresh_token 静默刷新用户其实感知不到。3.2 JWT 的自包含特性和撤销难题JWT 的好处是自包含令牌里直接带了用户 ID、角色、过期时间等信息资源服务器不用查库就能验证。但这也带来一个致命问题令牌签发后无法撤销。用户登出了、权限被回收了、账号被封禁了只要令牌还没过期它就依然有效。解决这个问题的常见方案有三种短有效期 黑名单access_token 设短一点登出时把令牌加入黑名单存 Redis资源服务器每次校验时查一下黑名单。这个方案简单但引入了状态JWT 的无状态优势打了折扣。令牌版本号用户表里存一个 token_version签发令牌时带上校验时比对。用户登出或改密码时递增版本号旧令牌全部失效。这个方案对用户粒度控制好但每次校验还是要查库。引用令牌令牌本身不含信息只是一个随机字符串资源服务器拿它去授权服务器换用户信息。这个方案最灵活但性能开销最大。我的经验是如果系统对实时性要求不高用短有效期 黑名单就够了如果对安全性要求极高用令牌版本号。纯无状态的 JWT 在 SSO 场景下其实不太现实因为 SSO 天然需要中心化的会话管理。3.3 id_token 和 access_token 别搞混OIDC 里有两个令牌容易混淆id_token 是给客户端用的用来确认用户是谁它是一个 JWT包含用户身份信息access_token 是给资源服务器用的用来访问受保护资源。客户端拿到 id_token 后应该验证签名、校验 iss、aud、exp 等字段然后解析出用户信息。我踩过一个坑有次把 access_token 当成 id_token 用直接解析里面的用户信息结果发现 access_token 的格式不固定有时候是 JWT有时候是随机字符串解析直接报错。后来才明白access_token 对客户端是不透明的客户端不应该去解析它要用户信息就老老实实用 id_token 或者调 UserInfo 接口。4. 会话管理SSO 最容易被忽视的重灾区令牌搞定了不代表 SSO 就稳了。会话管理才是真正考验功力的地方尤其是登出和跨域这两个场景坑特别多。4.1 单点登出的三种实现思路单点登录容易单点登出难。用户在业务系统 A 点了登出怎么让 B、C、D 也一起登出常见方案有三种前端轮询业务系统定期调授权服务器的接口检查会话状态发现失效就跳登录。这个方案实现简单但实时性差有延迟。后端通知授权服务器在用户登出时主动调用各个业务系统的登出回调接口。这个方案实时性好但需要维护业务系统列表而且如果某个系统挂了通知会失败。共享会话存储所有系统共享一个 Redis 存会话状态登出时直接删 key。这个方案最彻底但要求所有系统能访问同一个存储架构耦合度高。我实际项目里用的是后端通知 失败重试的组合授权服务器维护一个订阅列表登出时异步通知失败的进队列重试。这样既保证了实时性又不会因为某个系统故障影响整体。4.2 跨域场景下的 Cookie 和 Token 传递前后端分离之后跨域成了绕不开的问题。如果业务系统和授权服务器不同域Cookie 默认是带不过去的需要设置SameSiteNone; Secure而且必须是 HTTPS。但SameSiteNone会带来 CSRF 风险所以还得配合 CSRF Token。另一个方案是不用 Cookie用 Token。前端把 access_token 存在内存里不要存 localStorageXSS 能直接偷走每次请求放在 Authorization 头里。这个方案天然跨域但刷新页面后令牌会丢需要配合 refresh_token 重新获取。我个人的建议是如果业务系统和授权服务器同域用 Cookie HttpOnly 最省心如果跨域用 Token 内存存储 refresh_token 刷新。两种方案我都落地过各有取舍关键是要和前端团队对齐好。4.3 会话固定攻击和并发登录控制会话固定攻击是指攻击者先获取一个会话 ID然后诱导用户用这个 ID 登录登录后攻击者就能共享用户的会话。防御方法很简单用户登录成功后必须重新生成会话 ID废弃登录前的那个。并发登录控制则是另一个维度的问题。有些系统要求同一账号只能在一个设备登录这时候需要在授权服务器维护用户 - 会话的映射新登录时踢掉旧会话。实现上可以用 Redis 存user_id - session_id的映射新登录时覆盖旧值旧会话校验时发现 session_id 不匹配就失效。提示并发登录控制要谨慎使用有些业务场景比如多设备办公反而需要允许多端同时在线这个要和产品经理确认清楚别自己拍脑袋决定。5. 安全加固那些安全扫描一定会挑的问题OAuth2 的灵活性是把双刃剑配置不当就会引入漏洞。这一章我列出安全扫描最常挑出的几个问题以及对应的修复方案。5.1 重定向 URI 校验不严导致的令牌泄露这是 OAuth2 最经典的漏洞。如果授权服务器对 redirect_uri 校验不严攻击者可以构造一个恶意回调地址诱导用户授权后授权码或令牌就发到攻击者服务器了。防御方法redirect_uri 必须白名单精确匹配禁止通配符和模糊匹配。我见过有团队用startsWith做前缀匹配结果https://legit.com.evil.com这种域名就能绕过。正确做法是完整字符串比对一个字符都不能差。// 错误示范前缀匹配 if (redirectUri.startsWith(registeredUri)) { ... } // 正确示范精确匹配 if (registeredUris.contains(redirectUri)) { ... }5.2 CSRF 防护和 state 参数的正确用法state 参数是防 CSRF 的关键但很多团队用错了。正确的用法是每次授权请求生成一个随机 state存到用户会话里回调时比对比对完立即删除。这样攻击者无法预测 state也就无法伪造回调请求。我见过两种错误用法一是 state 写死成固定值等于没有二是 state 存了但回调时不校验形同虚设。这两种在安全扫描里都是高危项。5.3 令牌泄露的应急响应即使防护做得再好也要做好令牌泄露的预案。一旦发现令牌泄露需要能快速失效相关令牌。这就要求授权服务器支持按用户、按客户端、按时间范围批量撤销令牌。我的做法是在 Redis 里维护一个撤销列表key 是令牌的 jtiJWT IDvalue 是过期时间。资源服务器校验令牌时先查撤销列表命中则拒绝。同时提供一个管理接口支持按条件批量撤销。这个方案在几次应急演练里表现都不错撤销能在秒级生效。安全问题常见错误配置正确做法重定向 URI前缀匹配、通配符白名单精确匹配CSRF 防护state 固定值或不校验随机生成、会话存储、回调比对令牌撤销无撤销机制黑名单 批量撤销接口客户端认证公开客户端用 client_secret公开客户端用 PKCE令牌存储localStorage内存 refresh_token6. 落地实践中的性能与可用性权衡安全搞定了还得考虑性能和可用性。授权服务器是整个 SSO 体系的单点它挂了所有系统都登不进去这个风险必须正视。6.1 授权服务器的高可用设计授权服务器要做到无状态会话数据存 Redis 集群这样可以水平扩展多个实例前面挂负载均衡。令牌签发用非对称加密RS256私钥签名、公钥验签资源服务器只需要公钥就能校验令牌不用每次调授权服务器。数据库层面用户表和客户端配置表要做主从复制读多写少的场景下从库能分担不少压力。Redis 用哨兵或集群模式避免单点故障。6.2 令牌校验的性能优化如果资源服务器每次校验令牌都要调授权服务器那授权服务器压力会很大。优化方案是本地验签 缓存公钥资源服务器启动时拉取公钥并缓存校验时本地验签只有验签失败或需要用户详细信息时才调授权服务器。公钥缓存要注意轮换问题。授权服务器轮换密钥时要保留旧公钥一段时间比如 24 小时等所有资源服务器都更新了再下线旧公钥。这个可以通过 JWKS 端点实现资源服务器定期刷新。6.3 灰度发布和回滚策略SSO 改造往往涉及多个系统不可能一次性全切。我的做法是按系统灰度先切一个非核心系统验证流程跑一周没问题再切核心系统。每个系统保留回退开关出问题能快速切回旧登录方式。回滚策略要提前演练别等出事了才想怎么回滚。我经历过一次授权服务器升级导致令牌格式变化幸好有回滚开关5 分钟就切回去了没造成大面积影响。7. 几个真实踩坑的复盘最后分享几个我在实际项目里踩过的坑都是文档里不会写但线上一定会遇到的。坑一时钟偏移导致令牌校验失败。授权服务器和资源服务器的系统时间差了几分钟导致令牌的 nbf生效时间校验失败。解决方案是所有服务器统一走 NTP 时间同步令牌校验时留一定的时钟容差比如 60 秒。坑二移动端 WebView 的 Cookie 问题。移动端 WebView 对第三方 Cookie 的限制比浏览器更严格导致 SSO 跳转后登录态丢失。解决方案是移动端改用 Token 方案不走 Cookie。坑三并发刷新令牌导致令牌失效。前端多个请求同时发现令牌过期同时发起刷新结果第一个刷新成功后 refresh_token 轮换了后面的刷新用旧 refresh_token 失败。解决方案是前端加一个刷新锁同一时间只允许一个刷新请求其他请求排队等待。坑四日志里打印了完整令牌。调试时为了方便把令牌完整打印到日志里结果日志被采集到日志平台令牌泄露。解决方案是日志里只打印令牌的前 8 位和后 8 位中间用星号代替。这些坑说起来都不复杂但真遇到了很耽误事。我的体会是SSO 这种基础设施细节决定成败每一个参数、每一个配置都要想清楚为什么这么设不能照抄网上的示例代码。网上的示例为了简洁往往省略了安全校验和异常处理直接拿到生产用迟早出事。如果让我给正在做 SSO 的团队一个建议那就是先把授权码模式的完整链路跑通再逐个加固安全和性能不要一上来就追求大而全。我见过太多团队一开始就想把单点登出、并发控制、多租户全做了结果基础链路都没跑稳最后项目延期。小步快跑逐步完善才是靠谱的落地方式。 
长河君 · 2026/10/21 17:50:22 · 阅读 1.2k OAuth2 落地 SSO 实战：授权码模式、令牌设计与安全加固
单点登录这个词做过中后台系统的人应该都不陌生。早期我们给内部做统一认证最土的办法是每个子系统各存一份用户表用户在每个系统里各注册一遍密码规则还不一样运维起来简直是灾难。后来大家学聪明了搞一个统一的认证中心所有子系统都跳到这里登录登录完再跳回去这就是单点登录SSO最朴素的样子。而 OAuth2 是目前落地 SSO 最主流的一套授权框架它本身不是协议而是一个授权委托的标准核心思想是让用户把证明自己是谁这件事委托给一个可信的第三方业务系统只拿授权结果不碰用户密码。这篇文章我想聊的不是 OAuth2 的 RFC 文档翻译而是我在实际项目里把 OAuth2 落地成 SSO 时踩过的坑、做过的取舍以及那些文档里不会写但线上一定会遇到的问题。适合正在做统一认证、准备接入第三方登录、或者被多系统登录态同步折磨过的开发者。如果你只是想知道OAuth2 有哪四种模式那网上随便一搜都是但如果你想知道为什么我用了授权码模式还是被安全扫描挑出一堆问题那这篇应该能帮到你。1. 先把 OAuth2 和 SSO 的关系理清楚很多人一上来就把 OAuth2 和 SSO 画等号这是个很常见的认知偏差。OAuth2 解决的是授权问题SSO 解决的是认证问题两者目标不一样只是经常被组合使用。理解这一点后面很多设计决策才不会跑偏。1.1 授权和认证到底差在哪举个生活化的例子。认证就像你进小区大门时刷门禁卡物业确认你是这个小区的业主授权则是你进了小区之后能不能进健身房、能不能用游泳池这是权限范围的问题。OAuth2 的设计初衷是让第三方应用在不拿到用户密码的前提下获得访问用户某些资源的权限比如允许某应用读取我的头像和昵称。那为什么 OAuth2 能做 SSO 呢因为 OAuth2 的授权码模式里有一个关键角色叫授权服务器它负责验证用户身份并颁发令牌。如果我们把这个授权服务器当成统一的认证中心各个业务系统当成 OAuth2 里的客户端那么用户只需要在授权服务器登录一次之后访问其他系统时授权服务器发现已有登录态直接颁发新的授权码用户就无感跳转过去了。这就是 OAuth2 实现 SSO 的本质。注意OAuth2 本身没有定义用户信息的标准格式所以实践中通常会配合 OIDCOpenID Connect一起用OIDC 在 OAuth2 之上加了一层身份层提供了 ID Token 和 UserInfo 接口这才是完整的 SSO 方案。1.2 为什么不用 SAML 或者 CAS老牌的 SSO 方案里SAML 和 CAS 都比 OAuth2 资历老。SAML 基于 XML配置繁琐报文体积大移动端支持不友好CAS 是耶鲁大学搞的协议简单但生态相对封闭主要用在教育领域。OAuth2 的优势在于JSON 格式轻量、移动端和前后端分离场景支持好、生态成熟、几乎所有主流语言都有现成的库。我做过一个对比同样是接入三个子系统用 CAS 大概要写三套客户端配置每套都得处理票据校验和 XML 解析用 OAuth2 的话客户端只需要配置四个参数client_id、client_secret、授权端点、令牌端点剩下的交给库处理。当然OAuth2 也不是没有代价它的灵活性带来了更多配置项稍不注意就会配出安全漏洞这个后面会详细讲。对比维度SAMLCASOAuth2 OIDC报文格式XMLXML/自定义JSON移动端支持差一般好前后端分离不友好一般友好生态成熟度企业级教育领域全领域学习曲线陡平缓中等2. 授权码模式为什么是 SSO 的唯一正解OAuth2 有四种授权模式授权码、隐式、密码、客户端凭证。做 SSO 的时候只有授权码模式是推荐使用的其他三种要么不安全要么不适用。这一章我把为什么这么选讲透。2.1 四种模式的适用场景拆解授权码模式用户跳转到授权服务器登录后授权服务器返回一个临时的 code客户端拿 code 去换 access_token。这个 code 是一次性的、短时效的即使被截获攻击者没有 client_secret 也换不到令牌。这是最安全的模式适合有服务端的应用。隐式模式授权服务器直接把 access_token 放在 URL 片段里返回。这个模式是给纯前端应用设计的但令牌暴露在浏览器历史里安全性差现在已经被 OIDC 的授权码 PKCE 模式取代了。密码模式用户把用户名密码直接给客户端客户端拿去换令牌。这个模式要求客户端完全可信一般只用于自家官方应用做 SSO 时绝对不能用因为业务系统不应该接触用户密码。客户端凭证模式没有用户参与纯粹是服务间调用。做 SSO 用不上。所以结论很明确做 SSO认准授权码模式如果是纯前端应用用授权码 PKCE。2.2 授权码模式的完整交互链路我把一次完整的 SSO 登录拆成八步每一步都有它的意义用户访问业务系统 AA 发现用户未登录生成一个 state 参数重定向到授权服务器的授权端点。授权服务器检查用户是否有登录态没有则展示登录页。用户输入凭证授权服务器验证通过建立自己的会话通常是写一个 Cookie。授权服务器生成一个一次性 code重定向回业务系统 A 的回调地址带上 code 和 state。业务系统 A 校验 state 是否一致防 CSRF然后用 code client_id client_secret 去令牌端点换令牌。授权服务器校验 code 和客户端凭证颁发 access_token 和 id_token。业务系统 A 用 id_token 解析用户身份建立自己的会话。用户访问业务系统 BB 同样重定向到授权服务器授权服务器发现用户已有登录态直接颁发新 code用户无感登录。这里面state 参数和code 一次性是两个关键安全设计。state 防止跨站请求伪造code 一次性防止重放攻击。我见过有团队为了省事把 state 写死成固定值这等于把 CSRF 防护直接废掉了。2.3 PKCE 到底解决了什么问题PKCEProof Key for Code Exchange是授权码模式的一个扩展专门防授权码拦截攻击。它的原理是客户端在发起授权请求时生成一个随机的 code_verifier把它哈希后作为 code_challenge 一起发过去换令牌时再把原始的 code_verifier 带上授权服务器比对哈希值是否匹配。为什么需要这个因为对于公开客户端比如纯前端应用、移动 Appclient_secret 没法安全保存攻击者如果能截获授权码就能直接换令牌。加了 PKCE 之后攻击者没有 code_verifier即使拿到 code 也换不了令牌。// 生成 PKCE 参数的示例 function generateCodeVerifier() { const array new Uint8Array(32); crypto.getRandomValues(array); return base64UrlEncode(array); } async function generateCodeChallenge(verifier) { const encoder new TextEncoder(); const data encoder.encode(verifier); const digest await crypto.subtle.digest(SHA-256, data); return base64UrlEncode(new Uint8Array(digest)); }实测下来PKCE 的计算开销可以忽略不计但安全收益很大现在 OAuth 2.1 草案已经把 PKCE 列为授权码模式的强制要求了。3. 令牌设计JWT 不是万能药令牌是 OAuth2 的核心产物设计得好不好直接决定了系统的安全性和可维护性。很多团队一上来就用 JWT觉得无状态、可自包含很香但用着用着就发现坑不少。3.1 access_token 和 refresh_token 的分工access_token 是访问资源的凭证有效期应该短一般 15 分钟到 2 小时refresh_token 用来刷新 access_token有效期可以长一些比如 7 天到 30 天。这样设计的原因是access_token 使用频繁暴露风险高短有效期能降低泄露后的危害refresh_token 使用频率低可以配合更严格的存储和轮换策略。我见过有团队把 access_token 有效期设成 7 天理由是减少刷新次数提升体验。这其实是个危险的取舍一旦令牌泄露攻击者能用的时间窗口太长了。正确的做法是缩短 access_token 有效期用 refresh_token 静默刷新用户其实感知不到。3.2 JWT 的自包含特性和撤销难题JWT 的好处是自包含令牌里直接带了用户 ID、角色、过期时间等信息资源服务器不用查库就能验证。但这也带来一个致命问题令牌签发后无法撤销。用户登出了、权限被回收了、账号被封禁了只要令牌还没过期它就依然有效。解决这个问题的常见方案有三种短有效期 黑名单access_token 设短一点登出时把令牌加入黑名单存 Redis资源服务器每次校验时查一下黑名单。这个方案简单但引入了状态JWT 的无状态优势打了折扣。令牌版本号用户表里存一个 token_version签发令牌时带上校验时比对。用户登出或改密码时递增版本号旧令牌全部失效。这个方案对用户粒度控制好但每次校验还是要查库。引用令牌令牌本身不含信息只是一个随机字符串资源服务器拿它去授权服务器换用户信息。这个方案最灵活但性能开销最大。我的经验是如果系统对实时性要求不高用短有效期 黑名单就够了如果对安全性要求极高用令牌版本号。纯无状态的 JWT 在 SSO 场景下其实不太现实因为 SSO 天然需要中心化的会话管理。3.3 id_token 和 access_token 别搞混OIDC 里有两个令牌容易混淆id_token 是给客户端用的用来确认用户是谁它是一个 JWT包含用户身份信息access_token 是给资源服务器用的用来访问受保护资源。客户端拿到 id_token 后应该验证签名、校验 iss、aud、exp 等字段然后解析出用户信息。我踩过一个坑有次把 access_token 当成 id_token 用直接解析里面的用户信息结果发现 access_token 的格式不固定有时候是 JWT有时候是随机字符串解析直接报错。后来才明白access_token 对客户端是不透明的客户端不应该去解析它要用户信息就老老实实用 id_token 或者调 UserInfo 接口。4. 会话管理SSO 最容易被忽视的重灾区令牌搞定了不代表 SSO 就稳了。会话管理才是真正考验功力的地方尤其是登出和跨域这两个场景坑特别多。4.1 单点登出的三种实现思路单点登录容易单点登出难。用户在业务系统 A 点了登出怎么让 B、C、D 也一起登出常见方案有三种前端轮询业务系统定期调授权服务器的接口检查会话状态发现失效就跳登录。这个方案实现简单但实时性差有延迟。后端通知授权服务器在用户登出时主动调用各个业务系统的登出回调接口。这个方案实时性好但需要维护业务系统列表而且如果某个系统挂了通知会失败。共享会话存储所有系统共享一个 Redis 存会话状态登出时直接删 key。这个方案最彻底但要求所有系统能访问同一个存储架构耦合度高。我实际项目里用的是后端通知 失败重试的组合授权服务器维护一个订阅列表登出时异步通知失败的进队列重试。这样既保证了实时性又不会因为某个系统故障影响整体。4.2 跨域场景下的 Cookie 和 Token 传递前后端分离之后跨域成了绕不开的问题。如果业务系统和授权服务器不同域Cookie 默认是带不过去的需要设置SameSiteNone; Secure而且必须是 HTTPS。但SameSiteNone会带来 CSRF 风险所以还得配合 CSRF Token。另一个方案是不用 Cookie用 Token。前端把 access_token 存在内存里不要存 localStorageXSS 能直接偷走每次请求放在 Authorization 头里。这个方案天然跨域但刷新页面后令牌会丢需要配合 refresh_token 重新获取。我个人的建议是如果业务系统和授权服务器同域用 Cookie HttpOnly 最省心如果跨域用 Token 内存存储 refresh_token 刷新。两种方案我都落地过各有取舍关键是要和前端团队对齐好。4.3 会话固定攻击和并发登录控制会话固定攻击是指攻击者先获取一个会话 ID然后诱导用户用这个 ID 登录登录后攻击者就能共享用户的会话。防御方法很简单用户登录成功后必须重新生成会话 ID废弃登录前的那个。并发登录控制则是另一个维度的问题。有些系统要求同一账号只能在一个设备登录这时候需要在授权服务器维护用户 - 会话的映射新登录时踢掉旧会话。实现上可以用 Redis 存user_id - session_id的映射新登录时覆盖旧值旧会话校验时发现 session_id 不匹配就失效。提示并发登录控制要谨慎使用有些业务场景比如多设备办公反而需要允许多端同时在线这个要和产品经理确认清楚别自己拍脑袋决定。5. 安全加固那些安全扫描一定会挑的问题OAuth2 的灵活性是把双刃剑配置不当就会引入漏洞。这一章我列出安全扫描最常挑出的几个问题以及对应的修复方案。5.1 重定向 URI 校验不严导致的令牌泄露这是 OAuth2 最经典的漏洞。如果授权服务器对 redirect_uri 校验不严攻击者可以构造一个恶意回调地址诱导用户授权后授权码或令牌就发到攻击者服务器了。防御方法redirect_uri 必须白名单精确匹配禁止通配符和模糊匹配。我见过有团队用startsWith做前缀匹配结果https://legit.com.evil.com这种域名就能绕过。正确做法是完整字符串比对一个字符都不能差。// 错误示范前缀匹配 if (redirectUri.startsWith(registeredUri)) { ... } // 正确示范精确匹配 if (registeredUris.contains(redirectUri)) { ... }5.2 CSRF 防护和 state 参数的正确用法state 参数是防 CSRF 的关键但很多团队用错了。正确的用法是每次授权请求生成一个随机 state存到用户会话里回调时比对比对完立即删除。这样攻击者无法预测 state也就无法伪造回调请求。我见过两种错误用法一是 state 写死成固定值等于没有二是 state 存了但回调时不校验形同虚设。这两种在安全扫描里都是高危项。5.3 令牌泄露的应急响应即使防护做得再好也要做好令牌泄露的预案。一旦发现令牌泄露需要能快速失效相关令牌。这就要求授权服务器支持按用户、按客户端、按时间范围批量撤销令牌。我的做法是在 Redis 里维护一个撤销列表key 是令牌的 jtiJWT IDvalue 是过期时间。资源服务器校验令牌时先查撤销列表命中则拒绝。同时提供一个管理接口支持按条件批量撤销。这个方案在几次应急演练里表现都不错撤销能在秒级生效。安全问题常见错误配置正确做法重定向 URI前缀匹配、通配符白名单精确匹配CSRF 防护state 固定值或不校验随机生成、会话存储、回调比对令牌撤销无撤销机制黑名单 批量撤销接口客户端认证公开客户端用 client_secret公开客户端用 PKCE令牌存储localStorage内存 refresh_token6. 落地实践中的性能与可用性权衡安全搞定了还得考虑性能和可用性。授权服务器是整个 SSO 体系的单点它挂了所有系统都登不进去这个风险必须正视。6.1 授权服务器的高可用设计授权服务器要做到无状态会话数据存 Redis 集群这样可以水平扩展多个实例前面挂负载均衡。令牌签发用非对称加密RS256私钥签名、公钥验签资源服务器只需要公钥就能校验令牌不用每次调授权服务器。数据库层面用户表和客户端配置表要做主从复制读多写少的场景下从库能分担不少压力。Redis 用哨兵或集群模式避免单点故障。6.2 令牌校验的性能优化如果资源服务器每次校验令牌都要调授权服务器那授权服务器压力会很大。优化方案是本地验签 缓存公钥资源服务器启动时拉取公钥并缓存校验时本地验签只有验签失败或需要用户详细信息时才调授权服务器。公钥缓存要注意轮换问题。授权服务器轮换密钥时要保留旧公钥一段时间比如 24 小时等所有资源服务器都更新了再下线旧公钥。这个可以通过 JWKS 端点实现资源服务器定期刷新。6.3 灰度发布和回滚策略SSO 改造往往涉及多个系统不可能一次性全切。我的做法是按系统灰度先切一个非核心系统验证流程跑一周没问题再切核心系统。每个系统保留回退开关出问题能快速切回旧登录方式。回滚策略要提前演练别等出事了才想怎么回滚。我经历过一次授权服务器升级导致令牌格式变化幸好有回滚开关5 分钟就切回去了没造成大面积影响。7. 几个真实踩坑的复盘最后分享几个我在实际项目里踩过的坑都是文档里不会写但线上一定会遇到的。坑一时钟偏移导致令牌校验失败。授权服务器和资源服务器的系统时间差了几分钟导致令牌的 nbf生效时间校验失败。解决方案是所有服务器统一走 NTP 时间同步令牌校验时留一定的时钟容差比如 60 秒。坑二移动端 WebView 的 Cookie 问题。移动端 WebView 对第三方 Cookie 的限制比浏览器更严格导致 SSO 跳转后登录态丢失。解决方案是移动端改用 Token 方案不走 Cookie。坑三并发刷新令牌导致令牌失效。前端多个请求同时发现令牌过期同时发起刷新结果第一个刷新成功后 refresh_token 轮换了后面的刷新用旧 refresh_token 失败。解决方案是前端加一个刷新锁同一时间只允许一个刷新请求其他请求排队等待。坑四日志里打印了完整令牌。调试时为了方便把令牌完整打印到日志里结果日志被采集到日志平台令牌泄露。解决方案是日志里只打印令牌的前 8 位和后 8 位中间用星号代替。这些坑说起来都不复杂但真遇到了很耽误事。我的体会是SSO 这种基础设施细节决定成败每一个参数、每一个配置都要想清楚为什么这么设不能照抄网上的示例代码。网上的示例为了简洁往往省略了安全校验和异常处理直接拿到生产用迟早出事。如果让我给正在做 SSO 的团队一个建议那就是先把授权码模式的完整链路跑通再逐个加固安全和性能不要一上来就追求大而全。我见过太多团队一开始就想把单点登出、并发控制、多租户全做了结果基础链路都没跑稳最后项目延期。小步快跑逐步完善才是靠谱的落地方式。