access_token是什么

你在接第三方接口时，文档里一会儿让你填 access token，一会儿让你填 app token，两边长得很像，到底该用哪个、能不能混着用、放在代码哪个位置才不会被扒走——这些卡人的地方，本篇一次说清。读完你能分清两类凭证的职责边界，知道哪些地方只能放服务端，并拿到一份保管、轮换、排错的检查顺序。

你在接第三方接口时，文档里一会儿让你填 access token，一会儿让你填 app token，两边长得很像，到底该用哪个、能不能混着用、放在代码哪个位置才不会被扒走，这些卡人的地方本篇一次说清。

读完你能分清两类凭证的职责边界，知道哪些地方只能放服务端，并拿到一份保管、轮换、排错的检查顺序。顺带提醒一句：具体平台的凭证命名、有效期、权限粒度各家都不太一样，遇到对不上的地方，以官方文档和你后台控制台当时的显示为准。

access_token 到底是什么东西

一句话定位：它是服务端发给调用方的一张临时通行证，代表「这次请求以谁的身份、能干什么」。它本身不是账号，也不是密码，泄露了不代表账号被改，但代表有人能顶着你的身份去调接口。

典型形态是一串随机字符串，请求时放在 Authorization 头或 query 参数里，服务端拿到后去查它对应哪个应用、哪个用户、还剩多少有效期。它通常有有效期，过期后要用另一套凭证去换新的，这和长期不变的密钥是两种东西。

判断要点

看文档里这个字段是「每次调用都要带」还是「用来换 token 的」，前者是 access token，后者是换取它的凭据。

常见的坑

把换来的那串东西又拿回去当换取的凭据用，结果是反复报鉴权失败。

access token 和 app token 差在哪

app token（有的平台叫 client 凭证、应用密钥）证明「你是哪个应用」，一般长期有效、由你自己保管，不随请求变化。access token 证明「这次请求获准做什么」，短时有效、可撤销，往往是用 app token 加用户授权换来的。

分辨动作：拿到两份字符串时，看哪一份出现在换取流程里、哪一份出现在业务请求里，前者是 app token，后者是 access token。如果平台把两者合并成一个长期密钥，就不能用「短时/长期」去判断，只能回到文档看字段说明。

• 先看文档里这个字段是出现在获取凭证的接口，还是出现在业务接口。
• 再看控制台里能不能单独重置它，能单独重置的多半是应用级凭证。
• 最后看有没有过期时间字段，有明确过期时间的基本是 access token。

一次请求里它怎么流转

典型链路是：你的服务端拿 app 凭证去鉴权端点换 access token，拿到后再带着它调业务接口，业务接口校验通过才返回数据。整条链路上，真正需要保密的是换取环节用到的那份凭证。

1. 第一步：确认发起端先看这次请求是从浏览器、App 还是你自己的服务器发出的。前端能打开开发者工具看到的东西，一律当公开处理。
2. 第二步：确认带的哪类凭证把请求头里的字段名和文档对一遍，是业务请求该带的，还是换取流程该带的。
3. 第三步：确认是否需要转发前端要调，就由你自己的后端做一层转发，前端只跟自己的后端打交道，真正的凭证留在服务端。
4. 第四步：复现最小请求拿一个最简单的调用验证通不通，通了再加业务逻辑，别一上来就在复杂代码里猜。

排查顺序记住一点：先确认这次请求是从哪一端发出的，再确认它带的是哪一类凭证，多数「鉴权失败」问题在这一步就能定位，不用急着怀疑平台。

存哪里、怎么存：一份对照清单

先说最容易出事的：密钥写死进源码再推到远程仓库，基本等于公开，即使事后删除历史记录，也可能已经被抓取或进了别人本地的副本。这类事故没有后悔药，只能靠事前约束。

• 本地开发用示例文件加占位符，真实值不提交，只在自己机器上填。
• 打印请求内容时屏蔽凭证字段，别让它们跟着异常堆栈进日志系统。
• 把带凭证的界面发给同事或贴到论坛，和写进代码是同一类事故，别觉得截图无所谓。
• 团队里多人共用一份凭证很难追溯是谁在用，更推荐一人一份、用完即撤。

怀疑泄露了，按这个顺序处理

顺序很重要：先止损，再查因。很多人第一反应是去翻代码找原因，结果凭证还在生效，异常调用一直持续。

1. 第一步：撤销到平台控制台把可疑的凭证作废或重置，撤销后旧的立刻失效，这比排查原因更急。
2. 第二步：看用量与调用记录判断有没有异常来源或异常时间段的请求，把时间线记下来，后面排查流程时用得上。
3. 第三步：换新并全量更新换新凭证后确认所有调用点都换完，避免半新半旧导致大面积报错。
4. 第四步：补流程回头问一句凭证是怎么流出去的，是写进了代码、日志，还是贴在了聊天记录里，把这一类出口堵上。

轮换与权限收窄：把损失压小

泄露不可能百分百避免，能做的是让它发生时的损失小一点。两个抓手：权限给到最小，有效期和轮换节奏控制住。

• 只开这次任务需要的范围，别一上来就申请全量权限，出问题时损失面小很多。
• 开发、测试、生产各用各的凭证，避免测试环境出问题时生产跟着遭殃。
• 定期轮换，并保证轮换期间新旧能短暂并存，否则换证那一刻会出现一批鉴权类错误。
• 给凭证加上备注或命名，写清用途和负责人，半年后回看还能知道它是干什么的。

什么情况下这套做法不适用？如果平台本身不提供多份凭证、不支持并存，就别强行搞平滑切换，改成挑低峰期一次性替换，并提前通知相关调用方。各家平台对凭证数量、权限粒度、轮换方式的限制不一样，动手前到站内凭证与计费相关页面核对当时的说明。

常见的鉴权失败怎么快速定位

先看报错文本而不是只看状态码：凭证缺失、过期、权限不足、签名不匹配，处理方式完全不同。状态码只能告诉你「没过」，报错文本才告诉你是哪一类没过。

如果换成新凭证仍失败，检查是不是凭证类型放错了位置，比如把应用级凭证塞进了业务请求头。拿不准时用最简请求复现，一个字段一个字段地加回去，比在完整业务代码里猜要快得多。

什么时候这套理解不够用

第一种是涉及第三方代用户授权、需要用户点同意页面的场景，流程会多出授权码换取这一步，不能只看两个 token 就下结论。这时候要理清的是「谁授权给谁、授权范围是什么」。

第二种是企业内网代理或网关二次封装的环境，实际发出的可能是网关凭证，真正的上游凭证由网关持有，排查要往上游看，不能只盯着自己这一层。第三种是做自动化脚本或本地小工具，凭证落在本机磁盘上，安全边界和线上服务完全不同，需要单独评估。

凭证这件事，思路永远是：能不给就不给，必须给就给最小的，给了的要能撤、能换、能查。