Postman 报 invalid_grant 主因是 OAuth 2.0 凭据或流程配置与服务端校验不匹配，需重点检查 redirect_uri（严格匹配注册值）、grant_type（须服务端支持）和 client_secret（服务端存密文、Postman 传明文）。
Postman 报 invalid_grant，基本不是网络或界面问题，而是 OAuth 2.0 授权凭据或流程配置与服务端校验逻辑不匹配。直接查 redirect_uri、grant_type、client_secret 这三项，90% 能定位。
检查 redirect_uri 是否严格匹配授权服务器注册值
这个错误最常出现在授权码模式（authorization_code）中。服务端会校验你传的 redirect_uri 参数是否和客户端在 OAuth 服务里预注册的一模一样——包括协议（http vs https）、端口、路径结尾斜杠、大小写。
- 在 Postman 的 OAuth 2.0 配置面板里，
Callback URL字段必须和后端ClientDetailsService中redirectUris("...")设置的值完全一致 - 如果服务端注册的是
https://myapp.com/callback/，你就不能填https://myapp.com/callback（少斜杠）或http://myapp.com/callback/（协议错） - 本地调试时常用
http://localhost:3000/callback，但 Spring Security OAuth2 默认禁止非 HTTPS 的redirect_uri；若没配allowUnsecuredRedirectUris(true)，就会返回invalid_grant - Postman Console（
View > Show Postman Console）里能看到完整请求 URL，复制其中的redirect_uri参数，和服务器注册值逐字符比对
确认 grant_type 和服务端支持的授权类型一致
服务端不会接受未声明的 grant_type。比如你在 Postman 选了 Authorization Code 流程，但后端只配置了 password 和 refresh_token，调用 /oauth/token 换 Token 时就会报 invalid_grant。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 检查服务端
ClientDetails配置中的authorizedGrantTypes(...)，确认包含你正在使用的类型，例如："authorization_code", "password", "refresh_token" - Postman 中选择的流程类型（如 “Authorization Code”、“Password Credentials”）必须和服务端允许的类型对得上，不能靠猜测
- 如果是密码模式（
password），确保请求体里带了username和password，且用户账号在服务端有效、未被禁用 - 某些云平台（如 Azure AD）默认关闭
password模式，只允许authorization_code或client_credentials，需在控制台显式开启
验证 client_secret 是否经过正确编码（尤其 Spring Cloud OAuth2）
Spring Security OAuth2（特别是旧版 Spring Cloud）要求 client_secret 必须是 BCrypt 加密后的字符串，而非明文。如果你在 application.yml 里直接写 secret: mysecret123，启动时日志会出现 Encoded password does not look like BCrypt，后续所有凭据校验都会失败，返回 invalid_client 或间接触发 invalid_grant。
- 用 Spring 的
BCryptPasswordEncoder.encode("mysecret123")生成密文，填入配置（如secret: $2a$10$abc...） - Postman 中填写的
Client Secret必须是明文原始值（即你加密前的字符串），不是 BCrypt 密文 —— 这个容易混淆：服务端存密文，Postman 传明文 - 如果服务端用了其他编码器（如
NoOpPasswordEncoder），虽能绕过校验，但不安全，且新版 Spring Boot 已弃用 - 用 curl 手动测试可快速验证：发起
POST /oauth/token，带上client_id、client_secret、grant_type等参数，看响应是否一致
Postman 自身缓存和变量干扰不可忽视
Postman 有时会复用旧的 Token 或环境变量，导致请求携带了已失效或格式错误的凭据，而错误仍显示为 invalid_grant。
- 在 Authorization 标签页，点击 “Remove auth from request”，再重新配置 OAuth 流程，避免残留 header
- 清空当前环境变量中可能存在的
access_token、refresh_token等手动设置的值 - 如果用了 Collection 变量或 Pre-request Script 动态注入 Token，先临时禁用，改用 Postman 原生 OAuth 流程跑通再逐步加逻辑
- 关闭 Postman 再重启，可清除部分内存级缓存；极端情况下可导出收藏夹后重装
真正卡住的时候，往往不是某个配置错了，而是多个条件叠加失效：比如 redirect_uri 少了个斜杠 + grant_type 服务端没开 + client_secret 明文硬编码。建议打开 Postman Console，盯着每一条请求的完整 URL 和响应体，把服务端返回的真实错误描述（不只是 invalid_grant）当作第一线索。
