第三方API访问的OAuth流程

Question

网络上有很多有关OAuth 2，其不同类型的流以及在何处/如何使用它们的信息。我发现这些资源中的大多数都讨论了对应用程序的用户进行身份验证，但是我在努力理解使用第三方API（即，当我们自己的API是用户与其用户之间的“中间人”时）最佳/正确的方法是什么。第三方API中的数据）。

在示例场景和一些图表的帮助下，我将非常感谢有关如何正确实现与第三方API集成以及每种方法的利弊的建议/意见。

起点

首先，假设我们有一个Web应用程序，其结构如下：

• 前端-SPA（Angular），由AWS S3 + Cloudfront托管
• 后端-节点，通过AWS API Gateway作为无状态AWS lambda函数运行
• 用于处理身份验证/登录等的Auth0。前端使用隐式OAuth2流获取access_token，这些令牌存储在本地存储中，并作为对后端的所有请求中的标头包含。
• 可能还使用相同的后端API的本地移动应用程序。

目标

现在假设我们希望添加与Google表格的集成。新功能将允许用户使用自己的Google表格（即存储在自己的Google帐户中）作为数据源，并且该应用程序具有对该表格的读写权限。将来可能还会有其他集成，所以我假设其他API需要类似的过程。

问题陈述

除了现有的OAuth流程（允许用户登录“ MyApp”前端并与“ MyApp API”进行通信）外，还需要其他OAuth流程，以便用户将MyApp连接到第三方Google Sheets API。

该文档有两个Quickstart示例，但似乎都不符合我的需求： 浏览器-https://developers.google.com/sheets/api/quickstart/js Node.js（控制台应用程序）-https://developers.google.com/sheets/api/quickstart/nodejs

来自第三方（Google）API的数据是潜在的几个集成点之一，因此从直观上看，与Google Sheets API的所有通信都应在MyApp API中进行，这似乎更加合乎逻辑（并且更安全）。 ，而不是在前端/客户端。 MyApp API将获取数据，以某种方式对其进行处理/操作/格式化，然后将其显示在前端或移动应用中。

我们需要访问每个用户自己的数据，因此Client Credentials流不适合。我专注于Implicit或Authorization Grant工作流程。

重要说明：棘手的问题似乎来自MyApp API是无状态的事实，因此没有存储令牌的长​​期会话。在此基础上，令牌似乎需要存储在前端（例如本地存储/ Cookie等）或后端数据库中。

以下是我对两种可能方法的解释。我将不胜感激。

选择1：隐式流-令牌存储的FE，传递给BE，BE随后向Google发出请求

优点：

• 允许访问用户自己的数据
• 流程更简单，access_token无需进行code步骤即可立即获得
• 在初始登录过程和实际获取数据之间执行较少的步骤
• 不需要后端数据库，可以在每次请求时重新发送令牌

缺点：

• 前端（浏览器）可以访问Google access_token，这似乎是不必要的，并且可能引起安全隐患
• 将access_token从FE传递到BE似乎是一个奇怪的过程，纯粹是为了让BE然后可以使用该令牌发出另一个请求
• 我不确定如何刷新/更新令牌，因为我知道在客户端上存储refresh_tokens是一种不好的做法。如果用户不得不频繁登录以重新连接其帐户，那将不是良好的用户体验

选项2：授权代码流程-通过BE与Google进行的所有通信，令牌存储在BE数据库中

优点：

• 允许访问用户自己的数据
• 除了代码请求/同意页面之外，与Google的所有通信都是在后端实施的，因此令牌无法在客户端上访问
• 可以从BE使用客户机密

缺点：

• 更复杂的流程，需要额外的步骤
• 鉴于BE是无状态的，尚不清楚如何最好地存储令牌。似乎需要将它们存储在数据库中，这非常复杂，并且似乎具有安全隐患-您如何正确保护/加密所述数据库中的access_token / refresh_tokens？

结论

鉴于数据处理将在后端进行，因此选项2似乎更合适，因为可以从前端应用程序中隐藏敏感令牌，并且几个客户端（Web前端，移动应用程序）的参与义务更少除初始登录/用户同意外，该过程均不适用。但是，我不确定拥有一个充满用户身份验证令牌的数据库是否是一个好主意，或者我如何才能适当地保护该数据库。

Answer 1

好消息是，这两个选项都完全有效且同样安全。担心浏览器中存在短暂的访问令牌不是问题。同样，如果仅将令牌保留在BE上，则需要实现自己的客户端身份验证/会话/ JWT等等，这会带来相同的攻击面。

我都做过，目前正从BE迁移到FE。就我而言，原因是我需要做的所有事情都可以在FE上完成，因此我最终根本没有BE。严格来说，这不是正确的，因为我使用BE进行了入职/付款，但仅此而已。

因此，最佳方法取决于您问题之外的因素，例如应用程序的性质，BE成本是多少以及它的重要性如何，您的devops技能集对于维护两个环境的表现如何，BE的程度无论如何都是必需的，而不是完全可选的。