淘宝扫码登录：umid、x5sec 与风控参数的缠绕

淘宝扫码登录为什么难

淘宝的扫码登录流程本身不复杂，难在风控参数贯穿始终：umid（设备指纹）、x5sec（风控令牌）、havana（登录网关的会话体系）层层嵌套。它是"协议简单 + 风控复杂"的典型，值得单独拆解。

流程拆解

第一步：生成二维码

GET https://qrlogin.taobao.com/qrcodelogin/generateQRCode4Login.do?...

返回二维码图片地址和 lgToken（轮询凭证）。二维码内容是 https://qr.m.taobao.com/...?t=xxx 的链接。

第二步：轮询状态

GET https://qrlogin.taobao.com/qrcodelogin/qrcodeLoginCheck.do?lgToken=xxx&...

状态：NEW（等待）→ SCANED（已扫）→ CONFIRMED（确认）→ EXPIRED（过期）。

第三步：确认后跳转

确认后返回跳转 URL，跟着走种下 cookie2、sgcookie、havana 系列登录 cookie。

风控参数的缠绕点

umid：阿里系设备指纹，生成二维码和轮询时都要带。它由安全 SDK 生成，协议模拟时从真实环境采集固定。umid 异常的表现不是报错，而是二维码生成后直接要求滑块。

x5sec：阿里的行为风控令牌。触发场景：轮询过快、IP 异常、设备新。表现形式是接口返回 FAIL_SYS_USER_VALIDATE 并要求过滑块，过了之后种下 x5sec cookie，后续请求带上才放行。x5sec 有有效期，过了要重新验证。

havana 会话：登录网关的会话体系，havanaId 是登录态的核心标识。扫码确认后 havana 体系落地，后续所有登录态校验走它。

精髓：四个实战要点

1. 轮询频率是风控敏感点。淘宝的轮询接口对频率敏感，2 秒一次是安全线，再快 x5sec 伺候。别家可以 1 秒，淘宝不行
2. 设备档案决定一切。umid + IP + cookie 历史构成设备画像，新设备画像的首次扫码大概率要滑块。工程上先"养设备"：用该设备档案正常浏览几天再扫码
3. cookie2 是核心。登录成功后 cookie2 是会话核心，配合 sgcookie 使用。它和 mtop 的 _m_h5_tk 是两套体系（登录态 vs 签名密钥），别搞混
4. 扫码登录 vs 密码登录的风控差异。扫码登录的风控通过率远高于密码登录（因为扫码有 App 端的真实设备背书）——这是扫码路线在工程上的核心价值，能扫码就别模拟密码登录

协议模拟的现实建议

淘宝协议模拟的现实路径排序：

1. 扫码登录（推荐）：人工或半自动扫码，拿 cookie2 体系，风控最宽松
2. 短信登录：协议可行但要过短信验证环节，适合有接码资源的场景
3. 密码登录：风控最严（密码接口必过滑块/图形验证），非必要不碰

拿到登录态后，mtop 接口的签名体系（_m_h5_tk）按前文"淘宝 mtop 签名"篇对接即可。

总结

1. 淘宝扫码协议简单，难在 umid/x5sec/havana 风控三件套
2. 轮询 2 秒一次，快了触发 x5sec 滑块
3. 设备画像要养，新设备扫码必验证
4. 扫码 > 短信 > 密码，登录方式的选择就是风控难度的选择

交流微信：run1255