现象：放行之后身份突然没了，长什么样
百度斗篷是本文的核心主题。上个月有个客户跑过来问，说百度推广落地页这边，用户点广告进来是能正常放行的，没问题。但奇怪的是，用户在落地页里待了两分多钟，再去点页面内的跳转，就被当成未授权请求给拦了，页面直接退回默认展示版本。乍一看像是跳转规则不稳，但我们顺着日志往下查，发现是鉴权链路里会话保持这一段掉链子了：Token在轮换窗口里没来得及续签，旧的那个过期了，新的又没绑到当前会话上，请求身份链就这么断了。
这种情况在百度斗篷部署里挺常见的。鉴权链路这玩意儿，你得把它看成一条从头贯到尾的通路——请求进来、身份判定、打放行标记、会话往下延续，每一环都串着。Token轮换跟会话保持策略怎么定，基本就决定了这条路走得稳不稳、能不能预期。
定义：百度斗篷鉴权链路到底指什么
百度斗篷鉴权链路，说的是在百度推广流量这个场景下，斗篷系统对进来的请求做身份验证、权限判定，还有会话状态维护的那条技术路径。它要干的核心事情是：不靠平台那边的Cookie，也不靠账号体系，斗篷系统自己得立起一套能验证、能延续的请求身份标识机制。
这条链路里一般有四个角色。请求入口，可能是广告点击，也可能是页面内跳转；鉴权服务，负责签发和校验Token；会话存储，存会话状态以及Token的绑定关系；最后是业务决策层，拿到鉴权结果后决定给放行版本还是回退版本。四个角色按固定顺序配合，哪个环节状态对不上，链路就断。
它跟通用API鉴权不太一样。百度斗篷鉴权链路面对的是搜索广告场景过来的请求——高并发、会话短、还跨页面跳。它得在极短时间里把Token校验完，同时保证同一个用户在多个页面跳转之间身份不丢。Token轮换和会话保持策略，就是冲着这个目标去设计的。
机制：把Token轮换的生命周期拆开看
输入阶段：Token签发和初始绑定
请求第一次通过斗篷放行判定之后，鉴权服务会签发一个短期Token，同时把它跟当前会话标识绑在一起。Token里面通常装会话ID、签发时间、有效期、版本号这些字段，用服务端密钥签名，客户端手上只有密文。为什么要绑定？是为了让后面的请求能靠Token反查会话状态，不用去依赖IP或者User-Agent这种容易漂移的信号。
签发的时候有两个参数得先定下来：Token有效期，还有轮换提前量。有效期管的是单个Token能用多久；轮换提前量管的是旧Token过期前多久开始签新的。两个参数配合起来，就形成了轮换窗口。
处理阶段：轮换怎么触发，怎么平滑过渡
Token轮换不是等到过期那一刻才动手，是在轮换窗口里提前做。常见的策略有下面两种：
- 时间驱动轮换。按固定时间间隔签发新Token，旧Token在宽限期内照样能校验通过。宽限期一般设成有效期的一个比例，用来覆盖请求在路上的时间。
- 事件驱动轮换。在特定事件发生时才轮换，比如会话状态变了、页面跳转层级变了、放行规则版本更新了。这种方式更精准，但触发条件的管理会复杂不少。
轮换的时候，新旧Token得并行有效一段时间。鉴权服务校验时优先认新Token，但旧Token的校验通道也保留着。这样一来，哪怕用户的请求正好在轮换那一瞬间到达，也不会因为Token切换被中断。
Token校验过了之后，鉴权链路会给业务决策层输出三样东西：会话有没有效、当前放行版本是哪个、还剩多少有效期。业务决策层拿着这些信息决定返回哪个页面版本，并且在响应里注入新的Token或者刷新标记。输出的内容必须跟输入阶段绑定的会话状态对得上，不然同一个会话里页面版本就会跳来跳去。
机制：会话保持策略由什么组成，边界在哪
会话标识怎么生成，存到哪
会话标识是整条鉴权链路的锚点。它一般在首次放行的时候生成，存进服务端会话存储，然后跟Token绑定。会话存储选什么方案，直接影响到保持能力：
- 集中式存储。所有鉴权节点共用同一个会话存储，一致性强，但存储延迟和单点风险得处理。
- 分布式存储。会话数据分片存放，扩展性好，不过跨分片查询还要额外的路由逻辑。
- 边缘会话。会话状态下沉到边缘节点，延迟低，可节点之间的同步得另加机制。
会话续期和失效怎么判定
会话保持可不是无限往下延。每次Token轮换的时候，会话续期条件都要重新过一遍：用户一直活跃，会话有效期就顺延；要是超过设定时长没有有效请求，会话就标记失效，后面的请求回到初始判定流程。续期条件通常看这几项——Token校验通过、请求间隔小于阈值、会话状态没被标记成异常。
失效判定得把两种情况分开：正常过期和异常中断。正常过期按预设时长处理就行；异常中断可能是Token校验失败、会话状态冲突或者存储不可达引起的，这种得单独记下来，还要触发回退逻辑。
鉴权链路在下面这些情况可能失效或者降级：
Token签发服务不可用。新请求拿不到Token，链路退回初始判定，重复判定的开销可能会涨。；会话存储延迟太高。Token校验等着等着超时了，请求被判成未授权，触发回退版本。；轮换窗口跟请求间隔不匹配。用户请求间隔比Token宽限期还长，旧Token已经失效、新Token又没签发，会话就断了。；多节点时钟有偏差。不同鉴权节点对Token有效期的判断不一致，同一个Token在部分节点通过、部分节点被拒。。
适用条件，以及跟相邻概念的对比
它跟通用会话管理差在哪
通用会话管理一般靠Cookie或者本地存储，会话标识由客户端拿着并回传。百度斗篷鉴权链路的Token轮换更强调服务端主动控制：有效期短、轮换频繁、绑定关系严格。这么做是为了压缩客户端信号被篡改或者复用的空间，同时让放行判定保持连续。
跟OAuth这类标准鉴权协议比，斗篷鉴权链路不追求跨系统授权，它只盯着单一投放场景里的会话延续。它的Token不是拿去访问第三方资源的，只用在斗篷系统内部的放行判定上。
实战案例：轮换窗口和请求间隔的匹配调整
有个做工具类应用的投放项目，日均点击量两千左右，落地页里有三次页面内跳转。初期配的是Token有效期三分钟，轮换提前量三十秒。跑了两天发现，部分用户在第二次跳转时被回退到默认版本。翻日志一看，这些用户的请求间隔集中在两分半到三分钟之间，正好卡在旧Token快过期、新Token还没签发的那个窗口里。
调整分了两步走：先把有效期拉到五分钟，轮换提前量提到九十秒；然后在页面内跳转的响应里加上Token刷新标记，让客户端在跳转前主动触发一次续签。改完之后，同类回退请求的占比从日均几十次掉到个位数。最后的状态是轮换窗口盖住了用户实际跳转间隔的分布区间，会话中断基本只出现在用户主动离开后重新进来的场景。
概念性 FAQ
Token轮换频率越高就越安全吗
并不是。轮换频率得跟请求间隔分布对上。频率太高，签发和校验开销上去了，还可能因为宽限期不够导致会话中断；频率太低，Token有效期太长，身份链路的可控性就下来了。比较合理的做法是先观察请求间隔分布，再去定有效期和轮换提前量。 不等于。会话保持的目标是在用户活跃期间把身份连续性维持住，不是无限往下延。无活动超时、Token校验连续失败、会话状态冲突，这些都应该触发失效。失效之后请求回到初始判定流程，重新走一遍放行判定。
鉴权链路和放行规则是什么关系
放行规则决定请求能拿到哪个页面版本，鉴权链路决定请求有没有资格拿到那个版本。顺序是先鉴权，后放行。鉴权没过，放行规则就不执行，请求直接进回退版本。把会话保持策略和放行规则解耦开，可以避免规则变更影响到身份链路的稳定性。
