使用Doorkeeper向OAuth2提供商发POST请求时遇invalid_grant错误

我来帮你排查这个困扰的invalid_grant问题，这个错误基本都和授权码的有效性、跳转URI匹配度或者客户端信息有关，咱们一步步来拆解：

1. 先确认授权码（code）没失效 #

授权码是一次性使用的，只要你用它成功请求过一次token，这个code就会被作废，必须重新走授权流程（跳转到/authorize页面）获取新的code。
另外，Doorkeeper默认授权码的过期时间是10分钟，如果拿到code之后隔了太久才请求token，也会触发这个错误。要是测试需要，可以在Doorkeeper配置里调整过期时长：

Doorkeeper.configure do
  # 保留你原有的其他配置
  authorization_code_expires_in 30.minutes # 改成你需要的时长
end

2. 严格匹配redirect_uri（最常见原因！） #

你请求token时用的redirect_uri=urn:ietf:wg:oauth:2.0:oob，必须和你获取授权码时使用的redirect_uri完全一致——大小写、字符、甚至有没有末尾斜杠都不能差！
举个例子：如果当初你跳转到授权页面的URL是http://localhost:3000/oauth/authorize?client_id=xxx&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code，那请求token时的redirect_uri必须和这个一模一样。
另外，还要确认你的Doorkeeper客户端（数据库oauth_applications表中对应的记录）已经配置了这个redirect_uri。如果是测试环境想临时跳过校验，可以加这个配置（生产环境绝对别用）：

Doorkeeper.configure do
  # 保留其他配置
  allow_blank_redirect_uri true
end

3. 核对client_id和client_secret的准确性 #

检查你请求里的这两个参数，是不是和Doorkeeper后台创建的OAuth应用完全一致——有没有复制时漏了字符、打错字母？直接去数据库的oauth_applications表核对这两个字段的值最稳妥。

4. 确认请求的Content-Type正确 #

发送POST请求时，必须把Content-Type设为application/x-www-form-urlencoded，Doorkeeper默认只解析表单格式的参数。如果用curl测试，命令应该是这样的：

curl -X POST http://localhost:3000/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=c094523a20444ee3362e8eb33e08b5266cfb6486babe9f918c0c88104e67f6c0&client_secret=d6cebe57e475e685beb2401108438991e94f0078152d52a2da4d5f1307a4729c&code=c2f56975ba6970634deef1e256faa5de5b146f794f37b3c59f3b5111d6810ef6&grant_type=authorization_code&redirect_uri=urn:ietf:wg:oauth:2.0:oob"

5. 检查Doorkeeper的授权模式配置 #

你的当前配置没问题，但可以显式确认下开启了授权码模式，避免意外禁用：

Doorkeeper.configure do
  # 保留其他配置
  grant_flows %w[authorization_code] # 明确声明支持授权码模式
end

先从redirect_uri匹配和授权码有效性这两个点入手排查，大概率能解决问题！

内容的提问来源于stack exchange，提问作者Georgiy Melnikov