在线教育视频防盗链与播放鉴权实战：签名URL、Token时效与续期、并发限制

在线教育的核心资产是课程视频，而视频一旦被人拿到原始地址批量下载、拼车共享，付费体系就形同虚设。很多团队初期只用 Referer 防盗链或在 URL 里拼一个固定密钥，结果很快被抓包绕过。可靠的视频保护不是单一开关，而是"播放凭证签发、时效控制、续期、并发与异常行为约束"串起来的一套机制。本文拆解生产可用的播放鉴权方案，以及每一步最容易被忽略的坑。

一、先认清：Referer 和固定密钥为什么挡不住

先排除两种常见的"伪防盗链"：

• 只校验 Referer：Referer 是请求头，抓包工具可以任意伪造，几乎零成本绕过；它只能挡住别的网站直接 <video src> 引用你的地址，挡不住蓄意下载；
• URL 里写死长期密钥：一旦地址泄露（浏览器历史、抓包、群聊转发），在密钥轮换前所有人都能无限访问，且无法定位是哪个账号泄露。

正确思路是把"能不能看、看到什么时候、在几台设备看"都收敛到有时效、可追溯、和用户身份绑定的播放凭证上，原始视频地址不直接暴露给前端。

二、签名 URL：让地址本身带有效期和身份

播放地址由服务端按需签发，包含对象标识、用户、过期时间，并对这些字段做签名。客户端拿到的是一个"过期即作废、篡改即失效"的临时地址。

一个典型的签名地址形如：

https://media.example.com/play/course-88/lesson-3.m3u8 ?uid=10086&exp=1725960000&rnd=9f3a&sig=8c1d...

服务端校验逻辑：

function verifySignedUrl(query, secret) {
  const { uid, exp, rnd, sig } = query;
  if (Date.now() / 1000 > Number(exp)) return { ok: false, reason: "EXPIRED" };
  const expect = hmac(secret, `${uid}.${exp}.${rnd}`); // 与签发端同一算法
  if (!timingSafeEqual(expect, sig)) return { ok: false, reason: "BAD_SIGN" };
  return { ok: true, uid };
}

关键点：

1. 签名覆盖所有敏感字段：uid、exp、资源路径都要参与签名，改任意一个都会导致签名不匹配；
2. 用 HMAC 而非简单拼接 MD5，密钥只在服务端，永不下发；
3. 比较签名用恒定时间比较，避免时序侧信道；
4. 加随机数 rnd 防缓存：避免同一用户的地址被 CDN 或中间层长期缓存、过期后仍命中；
5. HLS/DASH 分片也要保护：只签 m3u8 而不签 ts 分片，分片地址仍可被直接拖走，需要让 m3u8 内的分片地址同样带签名，或用带鉴权的 Cookie/Token 联动。

三、两层凭证：短期播放票据 + 登录态

直接把登录 Token 的有效期设成视频时长并不合适——登录态要长期保持，播放凭证却应当短命。推荐两层结构：

• 登录态 Token（长）：标识用户身份、会员状态，小时级到天级；
• 播放票据 PlayTicket（短）：每次进入播放页时，用登录态向后端换取，分钟级有效，绑定具体课时。

POST /course/play-ticket  Authorization: Bearer <loginToken>
# 响应: { "ticket": "pt_xxx", "expiresIn": 300, "playUrl": "https://..." }

这样即使播放地址泄露，攻击窗口也只有几分钟；而用户正常观看一节课通常超过票据有效期，于是需要续期机制。

四、无感续期：在票据到期前平滑换新

视频不能看到一半突然鉴权失败。续期要做到"用户无感知、且只有真实在看的人能续"：

1. 前端在到期前主动续：监听播放进度，在票据剩余约 1/3 有效期时请求新票据，替换后续分片的地址；
2. 续期接口校验播放行为：要求携带上一张票据、当前播放位置（currentTime），服务端判断进度是否合理（例如 5 分钟内进度只前进了几秒，可能是挂着没看或在录屏）；
3. HLS 用密钥接口续期更平滑：对真正要防下载的内容，可对视频分片做加密（HLS AES-128 / 样本加密），播放器通过短期票据向密钥接口换取解密密钥，密钥不落盘、分片加密，即使下载了分片没有密钥也无法播放；
4. 续期失败降级而非黑屏：先缓冲重试一次，仍失败再提示重新登录，避免网络抖动直接打断学习。

五、并发与设备限制：防"拼车共享账号"

防盗链防的是地址外泄，并发限制防的是"一个会员多人同时用"。常见做法：

• 登录设备数上限：维护账号的可信设备列表，新设备登录按策略踢掉最旧设备或要求二次验证；
• 同时播放会话数上限：服务端为每个账号维护活跃播放会话（带心跳），同一时刻只允许 N 路（通常 1～2 路），新会话挤掉最旧会话；
• 心跳保活：播放器每 15～30 秒上报一次"正在播放课时 + 进度 + 票据"，超时未续的会话自动释放名额。

// 会话抢占：只保留最新 maxConcurrency 路
async function startPlay(uid, deviceId) {
  const sessions = await redis.lrange(`play:${uid}`, 0, -1);
  if (sessions.length >= MAX_CONCURRENCY) {
    await evictOldest(uid); // 通知最旧一路"账号在别处播放"
  }
  await redis.lpush(`play:${uid}`, JSON.stringify({ deviceId, at: Date.now() }));
}

注意并发判断要放在服务端、用原子操作（Lua 脚本或事务）完成，不能依赖前端自觉；同时要给"同一用户换设备、网络切换"留容错，避免正常用户频繁被误踢。

六、异常行为识别：把风险拦在批量泄露之前

签名和并发解决"身份与数量"，行为分析解决"看起来合法但不正常"：

• 单账号短时大量拉取不同课时分片、播放进度跳变异常，疑似批量下载；
• 同一 IP 段下大量不同账号播放同一课程，疑似工作室拼车；
• 票据续期频率异常、始终不推进进度，疑似录屏或挂机；
• User-Agent 与播放器指纹不符、非标准播放器内核直接拉分片。

这些信号不一定要实时封号，可以先打分、分级处置：低风险只要求重新验证，高风险临时冻结播放并人工复核，兼顾安全与正常用户体验。

七、踩坑清单

• 只签 manifest 不签分片，HLS 分片被直接拖走；
• 密钥或签名算法下发到前端，等于公开；
• 播放地址有效期设成几小时，泄露后攻击窗口过大；
• 续期不校验播放进度，挂着也能无限换新票据；
• 并发限制只在前端做，改个请求就能多开；
• 设备/并发策略过严，正常用户切网络、换设备被反复误踢；
• 视频加密了但解密密钥长期有效或可被缓存，防护形同虚设；
• 只做技术防盗、不保留访问日志，出了问题无法定位泄露账号。

八、工程落地建议

落地顺序建议分三步：第一步先上"短期签名 URL + HMAC + 分片签名"，用最小成本挡住绝大多数地址外泄；第二步引入"登录态/播放票据两层凭证 + 无感续期 + 加密密钥接口"，把攻击窗口压到分钟级；第三步再叠加"设备与并发会话 + 行为风控"。存储上，活跃会话适合放在 Redis 并设置与心跳匹配的 TTL；签名与续期逻辑收敛在网关或媒体鉴权服务，便于统一轮换密钥。务必保留完整的签发、续期、抢占、拒绝日志，让每一次播放都能追溯到账号与设备——安全机制不仅要拦得住，还要事后查得到。

九、上线前复盘清单

1. 原始视频地址是否从不直接暴露，所有访问都经短期签名；
2. 签名是否覆盖 uid、过期时间、资源路径，密钥是否只在服务端；
3. HLS 分片是否同样受保护，加密分片的密钥是否短期且不落盘；
4. 播放票据是否短命、续期是否校验真实播放进度；
5. 并发会话是否在服务端原子判断，是否对正常换设备留容错；
6. 是否有异常行为打分与分级处置，而不是一刀切封号；
7. 全链路日志能否把一次播放追溯到具体账号、设备、IP。

结语

视频防盗链的本质，是让"地址"变得短期、和人绑定、可被追溯，让"播放"变得有数量上限、有行为合理性校验。与其追求一个绝对无法破解的方案，不如用分层机制把批量泄露和账号共享的成本抬到远高于课程本身的价值——对绝大多数在线教育场景，这就是综合代价最低、也最稳妥的防护。