机器人调度系统鉴权：读写Token别再共用，否则前端一旦被抓包整个写接口全暴露

最近帮一个做机器人调度平台二次开发的客户做安全审计，他们前端代码被反编译了一次——幸好我们当时已经把读写 Token 拆开了，否则写接口一旦暴露，整个产线任务都能被人远程停掉。

我们调度平台第一次被"非授权访问"找上门，是上线第三周。

早期那个"简单清晰"的方案

最早我们用一个统一的 API Token，所有接口（读、写）共用。配置简单，文档好写，调用方也省事。

出问题的场景是这样的：客户的前端页面需要轮询查询状态，前端把 Token 写在了请求头里——结果前端代码被人抓包分析，Token 泄露。所有写接口跟着一起暴露。

还好当时没出大事，但从那以后我们彻底推翻了"一 Token 走天下"。

行业里常见的反思

跟几个同行聊，大家现在基本都认同一个原则：读写 Token 应该分开。理由其实不复杂：

• 🛡️ 写操作的破坏性大——能创建任务、终止任务、删设备
• 🔍 读操作的使用面广——前端轮询、监控看板、客户业务系统都要查
• 🎯 Token 分开后，写 Token 可以长期不轮换，只在受控场景使用
• 🔁 读 Token 即使泄露，攻击者也最多看到状态，看不到能改什么

听起来是个显而易见的道理，但真正落地的时候几个细节让人栽过：

• 📌 写 Token 不能配得很长很复杂，否则人工运维会嫌烦
• 📌 读 Token 即使配置了强制校验，也要考虑好"哪些接口强制、哪些不强制"
• 📌 内部调用要单独设计，不能让前端存写 Token

我们最终的做法（仅说思路）

大致是这几个层面：

• 🚪 写 Token：单独配置，只给客户的业务系统使用，不暴露给前端
• 🚪 读 Token：单独配置，可以放前端使用；按需启用强制校验
• 🚪 内部调用：用独立的环境变量，不与外部 Token 共用
• 🚪 Header 兼容：同时支持自定义 Header 和 Bearer 两种写法

关键的取舍

有人问：那按角色分 Token 是不是更细？ 我们没这么做，原因有两个：

• 🎯 调度平台是 B 端中后台，客户系统对接模式相对固定，过细的分级反而复杂
• 🚀 读写分离已经覆盖 80% 的安全诉求，再细分带来的收益不抵维护成本

这是工程上典型的"够用就好"取舍——不是不能做，是做了反而拖累业务。

写在最后

鉴权这件事，最容易踩的坑不是"做不做"，是"做的尺度"。过度设计会拖累所有调用方，设计不足会埋雷。

我们后来给客户的建议也很简单：写 Token 当作"系统级凭据"对待，读 Token 当作"展示级凭据"对待，两种凭据的运维节奏完全不同。

关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。