更具体一点：
我实际上正在尝试使用他们支持 OAuth 2.0 的新 Basecamp api 集成到 Baseacamp。并且感谢他们糟糕的资源和文档，我被困在这个documentation 的#4，它说我必须发出反向通道请求才能获得访问令牌（我已经成功完成了 1-3 个步骤，这意味着我有验证码和状态）。
所以如果有人对这只野兽有任何想法，请帮助我解决这个问题；）
我使用了 jso OAuth 2.0 库，它帮助我完成了 1-3 个步骤，但这个库使用了隐式身份验证授权，而 basecamp 使用了授权码授权。所以我想我必须做一些手动的客户端-服务器舞蹈，这就是为什么我需要知道这个反向通道请求意味着什么以及如何制作一个？
【问题讨论】：
什么是反向渠道？
简单地说，反向通道是到 Internet 上服务器的出站连接，由运行防火墙后的 PC 的客户端软件自动建立。它也可以像留在客户端桌面上易于访问的位置的一些小信息（“cookies”）一样无害。反向渠道连接和信息收集 cookie 的用途很多，可以分为有用、可疑和邪恶。
【讨论】：
如果您正在开发 javascript 客户端应用程序，那么您使用的是错误的 OAuth 2 场景。链接文档中使用的场景称为“授权码授予”，适用于部署到远程服务器的 Web 应用程序。反向通道用于在不涉及用户的情况下，在应用程序和身份验证服务器之间在后台获取令牌，因此令牌甚至不会暴露给用户。由于嵌入式客户端（javascript、移动应用程序等）没有很好分离的远程环境，因此无论如何它们都很容易受到攻击，因此有一个简化的“隐式授权”场景，其中不包括此反向通道查询。您应该使用隐式授权流程。
根据您链接的文档，Basecamp 使用非常过时的 OAuth2 草案，即版本 5，规范是在版本 31 之后发布的。在那个旧版本中，第一个场景由“type=web_server”标识（更改为规范中的“response_type=code”），而您需要“type=user_agent”（目前规范中的“response_type=token”）来使用隐式授权方案。我不知道 Basecamp 是否有适当的文档，链接的文档说它受支持，但没有别的。
【讨论】：
忽略“反向通道”。这只是一个 POST 请求。
在第三步中，您将获得临时验证码。在第 4 步中，发送一个带有临时验证码的 POST 请求，该验证码被交换为一个半永久的身份验证令牌。
这是我用于 basecamp 的 OAuth2 库。相关的第 4 步，“反向通道请求”发生在 getOAuthAccessToken 函数中：https://github.com/ciaranj/node-oauth/blob/master/lib/oauth2.js#L153
【讨论】：
Front Channel 是浏览器（用户代理）。 Back Channel 是授权服务器，例如运行 Linux 的服务器。前通道不太安全。反向通道更加安全。由于这种配置，通信可能会受到 CSRF 的影响。
为了规避任何邪恶意图，建立了多个连接。第一个是授权服务器在客户端将授权类型指定为“代码”的情况下发回代码的地方。客户端还可以在查询字符串中使用状态参数。该代码实际上并没有授予权限，它说明了客户端将拥有的权限。
然后客户端请求将代码交换为访问令牌，该令牌授予对资源的访问权限。
这些多个请求背后的想法是承认浏览器（前端通道）可能不安全。
【讨论】：