多站点WordPress插件OAuth2 PKCE流适配方案及安全性问询

问题核心 #

你遇到的是分布式开源插件的OAuth2典型痛点：无法预先注册所有WordPress站点的redirect_uri，现有临时方案通过替换URI绕过校验，确实会削弱OAuth2的安全机制——恶意攻击者可能构造虚假跳转地址诱导用户，窃取授权码或token。

更优且安全的实现方案 #

1. 利用Doorkeeper的动态redirect_uri校验 #

Doorkeeper原生支持动态校验redirect_uri，不用逐个注册站点地址：

• 修改Doorkeeper初始化文件（config/initializers/doorkeeper.rb），配置正则白名单规则：

  Doorkeeper.configure do
    # 启用正则校验策略
    redirect_uri_validation_strategy :regexp
    # 匹配WordPress常见的回调路径，可根据插件实际路径调整
    allowed_redirect_uri_regexes [
      /^https?:\/\/.*\/wp-admin\/admin-ajax.php$/,
      /^https?:\/\/.*\/wp-content\/plugins\/your-plugin\/oauth-callback.php$/
    ]
  end
  

• 插件发起授权请求时，直接携带当前站点的真实redirect_uri，Doorkeeper会自动校验是否符合正则规则，完全遵循OAuth2规范，无需任何URI替换操作。

2. 额外强化安全校验 #

如果担心正则范围太宽，可叠加以下措施：

• 要求所有redirect_uri必须使用HTTPS，在Doorkeeper配置中开启：force_ssl_in_redirect_uri true；
• 插件发起请求时，携带站点唯一标识（比如home_url的SHA256哈希），在Doorkeeper的before_successful_authorization钩子中校验该标识与redirect_uri的域名一致性；
• 严格校验state参数：插件生成随机唯一的state并存储在WP会话中，授权回调时比对服务器返回的state，防止CSRF攻击。

3. 优化现有代理回调方案（兼容旧架构） #

如果暂时无法修改Doorkeeper配置，可以重构现有方案，消除安全漏洞：

• 插件发起授权请求时，将真实redirect_uri编码后放入state参数（同时保留随机防CSRF的部分）；
• 服务器的/oauth/callback接收授权码后，先校验state的防CSRF部分（比如和会话存储的随机值比对），再从state中解析出真实跳转地址；
• 跳转前校验该地址是否符合预设的白名单规则（比如域名后缀、路径规则），通过后再重定向到WordPress站点。
• 这种方式不再直接替换注册的redirect_uri，而是通过state安全传递真实地址，完全符合OAuth2的安全要求。

安全风险对比 #

• 原方案：直接替换redirect_uri会绕过OAuth2的核心校验逻辑，攻击者可轻易构造虚假跳转地址实施钓鱼，风险极高；
• 优化方案：无论采用动态正则校验还是state代理模式，都保留了OAuth2的安全校验机制，同时适配分布式部署的需求，安全性和合规性更有保障。

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