服务器到服务器集成的 Oauth2 授权类型答案

【问题标题】：Which Oauth2 grant type for server-to-server integration服务器到服务器集成的 Oauth2 授权类型
【发布时间】：2019-10-11 03:46:16
【问题描述】：

我们有一个代理层，可以将消息从渠道（想想 facebook messenger/twitter/sms/etc）传递到第 3 方全渠道联络中心平台。

平台 API 使用 OAuth2 的授权代码授予类型进行保护。我们在平台空间内创建一个“应用程序”，并使用提供的客户端 ID 和密码设置一个基本网页，其中包含一些 Javascript，以便在身份验证提供者重定向到此页面时接收访问代码。

使用此代码，我们能够生成输入到代理层的身份验证令牌。

反过来，我们的代理会为每个需要与平台交互的消息传递用户创建访问令牌。这在后端层中运行良好。

我的问题是 1）生成初始代码的方法是一个完整的hack 2) 我们的代理是纯后端服务，不能与用户代理交互，即：网络浏览器；因此无法通过来自 OAuth 提供程序的重定向从浏览器接收代码。

我也花了一些时间阅读 OAuth2 规范和一些博客文章，据我所知，client_credentials 是这种集成形式的正确授权类型。

但是，平台的开发团队坚持授权代码对我们有用。

我愿意犯错 - 但我的困惑在于我们应该如何为代理层创建初始令牌，因为代理层是一个纯后端服务。

我在这里错过了什么？

【问题讨论】：

【解决方案1】：

客户端凭据绝对正确。授权代码流应仅用于最终用户 UI。

但可能是您正在与不支持正确选项的非标准架构交互 - 或者在政治上您无法获得支持。

我的目标是赢得平台开发团队的支持。- 给他们买啤酒等

在最坏的情况下，您可以注册一个伪用户并编写一些基于 HttpClient 的后端代码，通过读取 302 位置标头等来执行 Auth 代码流，然后获取代码然后获取令牌。这将自动登录，但正如你所说的那样非常hacky。

我会尽我最大的努力避免它 - 并让我的利益相关者意识到我正在使用唯一可用的选项，它可能会在未来出现可靠性问题

【讨论】：

感谢您确认我对使用客户端凭据的怀疑。我很乐意尝试用汽水贿赂他们；但是飞往下一个大陆的成本可能会超过对我的好处。看来我现在会接受黑客攻击，并尝试为“正确”实施赢得他们的青睐。