用于 Rest API 的 Openid 连接/Oauth2答案

【问题标题】：Openid connect/ Oauth2 for Rest APIs用于 Rest API 的 Openid 连接/Oauth2
【发布时间】：2021-09-03 03:54:21
【问题描述】：

我在 IDM (vmware IDM https://github.com/vmware/idm/wiki/Integrating-Webapp-with-OAuth2#authentication-response) 上注册了不同的 Web 应用程序

很明显，所有应用程序都使用自己的客户端 ID 和客户端密码进行注册。当用户尝试访问 webapp “A” (webappa.com) 时，它会重定向到我的 IDM 登录页面，并在身份验证后返回可与访问和刷新令牌交换的代码。 webapp“B”等也会发生类似的事情。这很好用。现在我对以下 2 个用例感到困惑？

一个。我想使用 webapp“A”中的一些 API (webappa.com/api/v1/get_user_projects) 用于某些脚本目的。所以我的问题是如何针对用户对这些 API 进行身份验证？我可以通过传递他的凭据（使用一些 API 吗？）从 IDM 提供者那里获取用户的令牌。如果答案是否定的，那么通常如何处理？

b. webapp A 和 webaap B 是否可以一次针对用户拥有相同的访问/刷新令牌？

【问题讨论】：

标签： oauth-2.0 single-sign-on openid-connect access-token refresh-token

【解决方案1】：

一个。当用户进行身份验证时，它具有一定的权限和一定的时间。 OAuth 旨在让您可以只在微服务之间转发令牌 - 但您不能提升用户令牌的权限或时间。根据您的用例，您可能需要考虑使用具有不同权限的不同令牌来执行后台任务。

b. 可以但不建议通过 cookie 来遵循 Google 模型，该 cookie 范围为托管多个应用程序的 Web 域，这就是 Google 的做法 (mail.google.com / drive.google.com)。所以对托管和域有依赖性

首选选项是用户在 App A 上进行身份验证，然后单点登录到 App B。然后不同的应用程序会获得具有不同权限的单独令牌，并且可以更轻松地单独发展。

这还取决于应用的实现方式和您的技术选择：

使用服务器端技术的“旧式”网络应用预计会为每个应用发出单独的身份验证 cookie
遵循智能 Back End for Front End 设计的 SPA 可以通过 SameSite cookie 支持此模型，前提是它对一组相关的微 UI 有意义

在后一种情况下，您需要使用具有多个重定向 URI 的单个 OAuth 客户端 - 例如用于邮件和驱动器 - 因为用户可以先登录其中任何一个。

对于复杂的答案深表歉意 - 但这是一个非常具有架构性的主题，可能会产生隐藏成本。从利益相关者的角度来看，这非常简单——让它像谷歌一样工作。希望这个答案对您的对话有所帮助...

【讨论】：