Client Credentials 模式在 Postman 中需选 Grant Type 为 Client Credentials，Access Token URL 填 token 端点，正确配置 Client ID/Secret 和 Scope；认证方式依服务端选 client_secret_post（默认）或手动设 Authorization 头为 Basic Base64(client_id:client_secret)；Token 过期需手动更新或用 Pre-request Script 自动刷新。
Client Credentials 模式在 Postman 里怎么填参数
Postman 的 OAuth 2.0 流程支持 client_credentials 授权类型，但必须手动触发 Token 获取（不会自动刷新），且所有字段都得对齐授权服务器要求。填错任意一项，返回的都是 401 Unauthorized 或 invalid_client 错误。
关键配置项如下：
-
Grant Type必须选Client Credentials（不是 Authorization Code 或 Password） -
Auth URL一般不用填——client_credentials不走授权码流程，这个字段留空或删掉 -
Access Token URL必须是授权服务器的 token 端点，例如https://www.php.cn/link/fef087ff27dd2875eeb8c2498615602b -
Client ID和Client Secret要跟服务端注册时完全一致，注意大小写和特殊字符 -
Scope是可选但常被忽略：如果服务端校验 scope（比如 Authing 要求book:read），这里必须填，多个用空格分隔
client_secret_basic 和 client_secret_post 到底该选哪个
Postman 自身不提供「认证方式」下拉选项，它默认按 client_secret_post 发送（即把 client_id 和 client_secret 当作表单参数 POST）。如果你的服务端只接受 client_secret_basic（Base64 编码后放 Authorization 头），Postman 就不兼容开箱即用。
此时只能手动处理：
- 在请求的
Headers标签页，手动添加Authorization头，值为Basic - 删掉
Body中的client_id、client_secret字段（否则会重复传参，部分服务器直接拒收） - 确保
Content-Type是application/x-www-form-urlencoded - Postman 的 OAuth 2.0 面板此时仅作辅助参考，实际发请求要切到
Body+Headers手动构造
为什么获取 Token 后调用接口还是 401
拿到 access_token 后，Postman 默认把它塞进 Authorization: Bearer 头里——这本身没错，但容易漏掉两个硬性前提：
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- Token 必须没过期：
client_credentials模式通常不支持 refresh，过期就得重取；检查响应里的expires_in字段，单位是秒 - 资源服务器必须信任该 Token 的签发方（Issuer）和签名密钥（JWKS URI），不是所有 Spring Authorization Server 都默认开放公钥端点
- Scope 权限不匹配：Token 里带的
scope必须覆盖接口所需权限，比如 Token 是book:read，但接口要求book:write，照样 403 - Postman 的
Bearer Token认证类型不会自动更新 Token 值，你得手动粘贴新值，或用 Pre-request Script 从环境变量读取
用 Pre-request Script 自动续 Token 最省事
适合频繁调试、Token 过期快的场景。不需要每次点 “Get New Access Token”，靠脚本自动判断并刷新。
示例逻辑（放在需要认证的请求的 Pre-request Script 中）：
const accessToken = pm.environment.get("access_token");
const expiresAt = pm.environment.get("expires_at");
<p>if (!accessToken || Date.now() > expiresAt * 1000) {
const res = pm.sendRequest({
url: "<a href="https://www.php.cn/link/fef087ff27dd2875eeb8c2498615602b">https://www.php.cn/link/fef087ff27dd2875eeb8c2498615602b</a>",
method: "POST",
header: "Content-Type: application/x-www-form-urlencoded",
body: {
mode: "urlencoded",
urlencoded: [
{ key: "grant_type", value: "client_credentials" },
{ key: "client_id", value: "test_client" },
{ key: "client_secret", value: "xxx" },
{ key: "scope", value: "book:read" }
]
}
}, (err, res) => {
if (err) console.error(err);
else {
const json = res.json();
pm.environment.set("access_token", json.access_token);
pm.environment.set("expires_at", Date.now()/1000 + json.expires_in);
}
});
}</p>
注意：pm.sendRequest 是异步的，后续请求仍会用旧 Token；更稳的做法是拆成两个请求（先取 Token 的独立请求 + 主业务请求），用测试脚本链式触发。
真正麻烦的从来不是怎么填那几个框，而是服务端对 client_authentication_method 的严格校验、scope 粒度控制、以及 Token 签名验证链路是否完整——这些没法靠 Postman 界面解决，得看日志、抓包、比对 JWT payload。
