授权代码流，将代码从移动应用程序发送到 REST API

Question

我正在构建一个使用 REST API 来处理所有逻辑的移动应用（也可能是一个网站）。

话虽如此，REST api 本身应该调用第 3 方 REST API（Spotify 的 API）来处理应用程序/网站的逻辑。

所以基本上用户应该使用其 Spotify 帐户登录我的应用程序/网站，我的 API 应该调用 Spotify Web Api 以使用其访问令牌检索用户数据，然后将它们发送回应用程序/网站。

现在我花了相当长的时间研究有关身份验证 here 的 Spotify 指南，看起来 Authorization Code Flow 应该适合我的用例。

我肯定需要调用/authorize 端点来从我的应用程序中检索code，因为我需要用户交互。在那之后，我确实取回了**code**，我应该用access_token 和refresh_token 交换。

但正如我所说，调用 Spotify API 的不是应用程序本身，而是我的 API。所以理论上我应该将收到的code 发送到我的API，让他处理检索和刷新access_token 和refresh_token。

所以我的问题是这是否有意义？可以将code 从应用程序发送到我的 api 吗？ 不确定是否清楚，所以我将附上我打算做什么的图表。

也可能在收到代码后，我会将自己的令牌发送回应用程序，以用于以后的每个请求（在某种程度上类似于您在处理 Facebook 或其他社交网站的授权时所做的事情）

Answer 1

嗯 - 以下是一些假设，但我的目标是使用标准流程。不过，有些解决方案并不可行。

业务解决方案

您是否正在尝试构建一个将用户的 Spotify 数据与您自己的用户数据相结合的应用？

目标架构

您自己的 UI 和 API 应该使用您发行的令牌，而不是 Spotify。仅在需要访问 Spotify 资源时使用 Spotify 令牌。这会产生简单可靠的代码。

标准选项 1

这是基于您可以控制来自多个来源的数据：

• 您应该拥有自己的登录和令牌发行系统。 UI 首先登录到您的应用，这使它能够使用令牌调用您的 API。

• 当您想要访问 Spotify 时，您需要再次重定向用户。然后，用户可以同意您在您的应用中使用 Spotify 资源，之后您的网络/移动 UI 将获得 Spotify 令牌并可以调用 Spotify API。

标准选项 2

这是基于允许用户使用熟悉的凭据登录，该凭据通过联合登录工作：

• 用户需要登录
• 您的应用重定向到您的授权服务器
• 第二次重定向到 Spotify
• 用户在 Spotify 上登录
• Spotify 将令牌发布到您的授权服务器
• 您的授权服务器将自己的令牌发布到您的移动应用程序

同时，您的 Web API 与使用客户端凭据流的 Spotify 有自己的连接。

双跳码/令牌

这不是不安全的，但会增加很多复杂性并且不标准。您需要维护某种 API 会话，每个用户使用 2 种类型的令牌，访问令牌过期将是一个可怕的领域。

流动性

对于移动应用程序，您应该使用授权代码流 (PKCE) - 我的 blog posts 有一些关于消息和用户体验的内容。