通过 OAuth 2.0 从受信任的 SPA 对用户进行身份验证？答案

【问题标题】：Authenticating users via OAuth 2.0 from a trusted SPA?通过 OAuth 2.0 从受信任的 SPA 对用户进行身份验证？
【发布时间】：2023-03-05 18:43:01
【问题描述】：

我有一个自定义 OAuth 2.0 身份验证服务器与我的安全 API 一起部署。我还有一个由 nginx 部署作为静态内容交付的单页应用程序。我现在面临的问题是如何在没有活动后端来代理密码授权的情况下对该 SPA 的用户进行身份验证——我显然无法在 SPA 中嵌入客户端密码。

此类问题有哪些解决方案？

我发现资源所有者密码凭据授予可能正是我想要的。通过使用它，我将能够使用已建立的客户端 ID 直接从我信任的 SPA 发送用户名和密码凭据。如果我将此授权限制为仅对该特定客户端有效并验证请求的来源，我可以认为这是一个合理的折衷方案。

然后我的问题就变成了，我如何创建这个客户端和必要的关联用户？这是否意味着我的系统中有一些特殊的用户帐户与这个关联的特权客户端有关？ OAuth 2.0 似乎暗示客户端必须与某种用户相关联。在部署我的应用程序时，我是否会为这些特殊的用户和客户端对象播种？那安全吗？

【问题讨论】：

你检查过隐式流吗？这是通常用于 SPA 的一种。
@JánHalaša，我有。这是我最初的假设，但我相信这仍然需要对最终用户进行重定向，这不正确吗？
是的，首先您将用户转发到 OAuth2 服务器，然后它会返回您提供的 redirectUrl。您会在重定向 URL 的哈希部分获得访问令牌。重定向有问题吗？
@JánHalaša，不，我想我没有更多的想法。我的主要困惑更多是如何独立部署这两个应用程序，同时确保客户端始终知道其客户端 ID 应该是什么。我应该只使用我的 SPA 将使用的预先建立的客户端来为我的授权服务器播种吗？

【解决方案1】：

我认为隐式流程可以很好地使用。

对于服务器端 API，您需要决定是要使用访问令牌还是 ID 令牌（OpenID Connect - OAuth2 扩展）。

如果用户对 API 的权限存储在 OAuth2 服务器上，SPA 可能会要求用户提供将包含在访问令牌中的某些权限。这是一个权限委托，如果有更多的应用程序需要不同的权限，它会很方便。

如果 OAuth2 服务器不持有权限并且 API 自己管理它们，则使用 ID 令牌可能更适合，因为它们代表调用者的身份，并且无需在每次访问时访问 OAuth2 服务器即可进行验证。

API 可能不需要其 client_id，因为它只接受令牌 - 它不请求它们 - 它检查访问令牌是否包含用户调用或验证 ID 令牌的操作权限。

SPA 需要有它的 client_id 和注册的 redirect_uri-s。不需要客户机密，因为 SPA-s 无法保证它们的安全。它必须使用 HTTPS 进行部署以保护传输的令牌。

【讨论】：