Hybrid App 中 Token 鉴权到底怎么做？-平芜编程栈

本文适用于：WebView 混合开发、Hybrid App、Android+iOS + H5、App 内嵌业务、前端 axios 调接口的项目。
核心目标：搞清楚 Token 是否能给前端、哪些接口让 H5 调、哪些必须走原生，以及最安全的架构是什么。

一、先说结论（最重要）

对于所有 Hybrid 项目，可以直接采用下面这套三段式分级策略：

① 不需要登录的接口（公共接口） → H5 自己 axios，无需 Token

例如：

Banner、文章列表、活动页内容
商品展示页
公共配置接口

这些接口本身没敏感风险，让前端自己请求，最省心。

② 需要登录但风险一般的接口（普通业务） → 统一走原生网络层（App.request），H5 不拿 Token

例如：

查询个人资料
普通订单列表
普通业务提交

这些接口需要鉴权，但不允许 H5 拿到 token，所以：

H5 调 JSBridge → 原生带 token 发出去 → 结果回调给 H5。

H5 完全看不到 token，更安全。

③ 高风险接口（资产 / 支付 / 关键控制） → 必须原生代发 + 内部加签名

例如：

登录 / Token 刷新
下单、支付
用户资产、账户操作
任何高价值动作（例如机器人控制指令）

这类接口必须：

H5 不得发请求
H5 不得获取 Token
统一App.request()
原生这里可以做：
- Token 注入
- 签名
- TLS Pinning
- 风控 / 设备ID / 限制算法

这是企业级安全架构的基本线。

二、为什么不能让 H5 直接拿 Token？

Hybrid 中最常见的两个误区是：

误区 1：axios + Authorization 就很安全？——并不

axios.get('/user/profile', { headers: { Authorization: `Bearer ${window.APP_TOKEN}` } });

只要 Token 暴露在：

window
JS 全局
localStorage
任意 JS 环境

就意味着：XSS、第三方脚本、被注入脚本都可以拿到 Token。

即便配合 CookieManager 也一样，因为：

只要 Token 不带 HttpOnly，JS 就能读，安全性 = 一般。

误区 2：CookieManager 写 Token 更安全？——其实也不

很多人会写：

cookieManager.setCookie("https://m.xxx.com", "token=abc")

三、真正安全的思路：不是保护 Token，而是不给 Token

这里是全文核心理念：

只要 H5 能调后端，H5 就必须带鉴权；
H5 只要带鉴权，就会暴露鉴权凭证；
因此最安全的办法是：H5 不调后端、让原生代发。

这就是为什么最终落地要：

无 Token 的接口 → H5 直接 axios
有 Token 的接口 → 原生代发，不给 H5 Token

而不是纠结 Token 放 Cookie 还是放 Header。

四、落地的代码架构（非常清晰）

① H5：公共接口

axios.get('/config/public').then(res => {}); axios.get('/article/list').then(res => {});

② H5：重要接口统一通过 JSBridge 调原生

window.App.request({ url: '/user/profile', method: 'GET', data: {}, success(res) { console.log(res); }, fail(err) { console.error(err); } });

H5 不接触 Token。

③ 原生：统一网络网关（Kotlin 示例）

@JavascriptInterface fun request(json: String) { val req = parse(json) val token = tokenStore.getAccessToken() val httpReq = buildRequest(baseUrl + req.url) { header("Authorization", "Bearer $token") header("Device-Id", deviceId) // 原生还能加签名、TLS Pinning、安全参数 } client.newCall(httpReq).enqueue(object : Callback { override fun onResponse(...) { callbackToJs(req.callbackId, bodyString) } override fun onFailure(...) { callbackToJsError(req.callbackId, errorMsg) } }) }