Postman默认OAuth2流程无法用于PKCE，因其UI不支持自动生成code_verifier、code_challenge及code_challenge_method三要素，也未开放授权请求URL拼接控制权，必须通过Pre-request Script手动生成并协同两个请求完成全流程。
Postman 本身不原生支持 PKCE 流程的自动 code_verifier/code_challenge 生成与校验，必须手动补全关键参数才能走通授权码 + PKCE 模式。直接点选 Authorization Code 类型、填完常规字段后点击 Request Token，一定会失败——因为 Postman 不会自动生成或携带 code_verifier，也不会在请求 /oauth/authorize 时自动计算并传入 code_challenge。
为什么Postman默认OAuth2流程无法用于PKCE
Postman 的 OAuth 2.0 授权类型界面只暴露了标准授权码模式（RFC 6749）所需的字段，比如 Auth URL、Access Token URL、Client ID 等，但完全缺失对 PKCE 扩展（RFC 7636）必需的三个核心控制点：
-
code_challenge_method（必须为S256，不支持plain） -
code_challenge（由客户端生成的code_verifier经 SHA-256 哈希后 base64url 编码） -
code_verifier（最终在换 token 阶段作为请求体参数提交）
这些字段不会出现在 Get New Access Token 弹窗中，也无法通过环境变量或预请求脚本自动注入到授权重定向环节——因为 Postman 在该流程中不开放对初始授权请求 URL 的拼接控制权。
手动补全PKCE三要素：用Pre-request Script + Tests模拟
要让 PKCE 流程在 Postman 中跑通，你得绕过 UI，改用两个请求协同完成：一个手动构造的授权请求（含 code_challenge），一个手动构造的令牌交换请求（含 code_verifier）。关键靠 Pre-request Script 生成随机 code_verifier 并存入环境变量，再靠 Tests 从重定向响应中提取 code。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 第一步：新建一个
GET请求，URL 设为你的Auth URL，例如https://auth.example.com/oauth2/authorize - 第二步：在
Params标签页手动添加以下查询参数：response_type=code、client_id=my-client-id、redirect_uri=https://oauth.pstmn.io/v1/callback、scope=read、code_challenge_method=S256，以及code_challenge——这个值需提前算好（见下一步） - 第三步：在
Pre-request Script中运行以下代码生成并保存code_verifier和对应的code_challenge：
const crypto = require('crypto');
const verifier = crypto.randomBytes(32).toString('base64url');
const challenge = crypto.createHash('sha256').update(verifier).digest('base64url');
pm.environment.set("pkce_code_verifier", verifier);
pm.environment.set("pkce_code_challenge", challenge);
- 第四步：把上一步生成的
challenge值复制粘贴到Params的code_challenge字段里 - 第五步：发送该请求，浏览器会跳转到授权页；同意后跳回
https://oauth.pstmn.io/v1/callback?code=xxx，Postman 会捕获该 URL —— 此时需在Tests里提取code并存为变量：
const url = pm.request.url.toString();
const codeMatch = url.match(/code=([^&]+)/);
if (codeMatch) {
pm.environment.set("auth_code", codeMatch[1]);
}
- 第六步：新建第二个
POST请求，URL 设为你的Access Token URL，Body 选x-www-form-urlencoded，填入：grant_type=authorization_code、code（值为{{auth_code}}）、redirect_uri、client_id，以及最关键的code_verifier（值为{{pkce_code_verifier}}）
client\_authentication方式必须匹配服务端要求
很多 Spring Authorization Server 或 Keycloak 实例在启用 PKCE 后，会强制要求客户端认证方式为 client_secret_post（即把 client_id 和 client_secret 放在请求体里），而不是默认的 client_secret_basic（放在 Authorization 头）。如果你看到 invalid_client 或 unauthorized_client 错误，先检查这点：
- 在令牌请求的 Body 中，除了
code_verifier，还必须显式带上client_id和client_secret - 不要勾选
Client Authentication下拉菜单里的任何选项——否则 Postman 会自动加Authorization: Basic ...头，导致服务端拒绝双重认证 - 确保服务端注册的 client 允许
client_secret_post，例如 Spring Auth Server 的client_authentication_methods表字段里包含client_secret_post
容易被忽略的 redirect\_uri 和 scope 细节
PKCE 不改变授权码模式对 redirect_uri 和 scope 的校验逻辑，但错误配置会导致静默失败或 400 响应：
-
redirect_uri必须和你在授权服务器注册 client 时填写的**完全一致**（包括末尾斜杠、协议、大小写），不能用localhost替代127.0.0.1 - Postman 内置回调地址是
https://oauth.pstmn.io/v1/callback，这是唯一被 Postman 官方信任的地址；若服务端未将其列入白名单，授权页会直接报错，不会跳转 -
scope值必须和服务端注册的scopes子集匹配；如果服务端只允许openid profile email，而你传了read write，即使 PKCE 参数全对，也会返回invalid_scope
真正卡住人的地方，往往不是 PKCE 本身，而是 redirect_uri 白名单没配对、client_authentication_methods 没开 client_secret_post、或者 code_challenge_method 错写成 plain —— 这些细节不报明确错误，只返回模糊的 invalid_request 或空页面。
