Postman无法自动完成授权码模式全流程,必须手动获取code并构造token请求。需拼对授权URL、确保redirect_uri完全匹配、在Body中明文传client_id/client_secret,用环境变量管理access_token以避免重复粘贴。

Postman 本身不直接“执行”授权码模式的完整流程,它无法自动打开浏览器、跳转登录页、捕获重定向 URL 中的 code。你必须手动介入关键一步:获取并粘贴授权码。这是最容易卡住的地方,也是所有教程没说清的核心事实。
为什么 Postman 的 OAuth 2.0 面板不能全自动走完授权码流程
Postman 的 Get New Access Token 按钮在选择 Authorization Code 类型后,会尝试发起一个带 response_type=code 的请求,但它默认用的是内部回调地址(如 https://www.getpostman.com/oauth2/callback),而你的认证服务通常只允许白名单内的 redirect_uri(比如 http://localhost:8080/callback)。一旦不匹配,授权页直接报错或静默失败。
更关键的是:Postman 不接管浏览器上下文,它不会监听重定向、提取 URL 中的 code 参数、再自动拿去换 token。这步必须你来干。
所以正确做法是分两步手动操作:
- 用浏览器访问授权 URL,完成登录和同意,拿到
code=xxx参数 - 在 Postman 中手动构造
/oauth/token请求,填入该code、client_id、client_secret、redirect_uri
手动获取 code:拼对授权 URL 是第一道坎
授权 URL 格式固定:https://your-auth-server/oauth/authorize?response_type=code&client_id=xxx&redirect_uri=xxx&scope=xxx。漏掉任意一个必需参数,都会失败。
常见错误现象:
Postman 12.27.7 Windows x64 官方安装包,适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力,以及接口规范标签管理改进,适合受限网络测试与规范资源组织场景。
-
{"error":"invalid_request","error_description":"Missing parameter: response_type"}→ 忘写response_type=code -
{"error":"invalid_client","error_description":"Bad client credentials"}→client_id错,或服务端配置里没启用authorization_code授权类型 - 页面空白 / 404 →
/oauth/authorize路径不对,Spring Security OAuth2 默认是/oauth/authorize,但 Spring Authorization Server 2.x 已改为/oauth2/authorize - 跳转后提示 “redirect_uri mismatch” →
redirect_uri值必须和服务端白名单**完全一致**(协议、域名、端口、路径,甚至末尾斜杠)
注意:如果你用的是 Spring Authorization Server 1.x 或旧版 Spring Security OAuth,redirect_uri 必须提前注册;新版支持动态注册,但需开启对应配置。
手动换 token:POST 到 /oauth/token 必须带全四个参数
拿到 code 后,在 Postman 新建一个 POST 请求,目标是 /oauth/token(不是 /oauth/authorize),Body 选 x-www-form-urlencoded,填以下字段:
-
grant_type=authorization_code -
code= 你从浏览器 URL 里复制的值(例如demkHP) -
redirect_uri= 和上一步授权 URL 中一模一样的值 -
client_id和client_secret= 服务端注册时分配的凭据(明文传,不 Base64)
容易踩的坑:
- 把
client_secret错当成 Bearer Token 放 Header 里 → 它必须放在 Body 中 - 误用
Basic Auth方式传 client_id/client_secret → 这是客户端凭证模式的做法,授权码模式要求明文放 Body - 忽略 TLS:生产环境必须用 HTTPS,否则多数认证服务会拒绝
client_secret明文传输 - scope 范围不一致:如果授权 URL 里带了
&scope=read_profile,换 token 时 scope 参数可选,但若服务端校验严格,也得带上且一致
拿到 token 后怎么用:别再手填 Authorization Header
成功响应返回 JSON,含 access_token、token_type(通常是 bearer)、expires_in 等字段。下一步不是手动复制粘贴到每个请求 Header 里。
正确做法是:
- 在 Postman 环境变量中定义
access_token变量 - 在请求的
Authorization选项卡中选Bearer Token,Token 字段填{{access_token}} - 后续所有资源接口都继承这个设置,token 过期后只需重新跑一次换 token 请求,改下环境变量即可
复杂点在于刷新:如果响应里有 refresh_token,它只能用于再次调用 /oauth/token,但 grant_type 要换成 refresh_token,且 body 中不能带 code 和 redirect_uri,只传 refresh_token、client_id、client_secret。这个流程同样不能自动,得你手动维护。

















