OAuth2 用于 REST API，紧耦合 SPA 作为唯一客户端

Posted 2023-02-27

【中文标题】OAuth2 用于 REST API，紧耦合 SPA 作为唯一客户端

【英文标题】：OAuth2 for REST API with tightly coupled SPA as only client

【发布时间】：2019-07-31 12:02:25

【问题描述】：

我正在开发一个带有紧密耦合 SPA 的 REST API，作为上述 REST API 的唯一客户端。

假设 SPA 在myservice.com 上可用，而 api 在myservice.com/api 下。它们基本上是一个服务，只是在代码级别拆分，并部署在不同的根路径。

我现在使用的是具有 ROPC（用户名/密码）授权类型的 OAuth2。

问题来了。我一直在读到 ROPC 不安全，不应该使用。那我应该用什么？

我的 REST API 充当授权服务器，但它本身没有任何 Web 界面。因此，任何涉及重定向的流程都没有真正意义。 SPA 和 API 是如此紧密耦合，以至于对于最终用户来说，它们基本上是一个应用程序。没有第三者。

我可以将简单的登录表单添加到 API 中，比如说myservice.com/login。但我很难看出这会带来什么不同。

此应用程序的安全性非常重要。

这是我的问题：

在这种情况下使用 ROPC 真的很危险吗？

什么是身份验证和授权的完美方式？

或者如果没有第三方，OAuth2 可能完全是多余的？

使用的技术：

服务器：Spring Boot

【参考方案1】：

在这种情况下使用 ROPC 真的很危险吗？

不，没有真正提供：

a) 您不存储用户的密码 - 可能只使用它来获取初始访问和刷新令牌 - 尽管这对于 SPA 可能会很棘手。

b) 您的 SPA 客户端和资源 API 归您所有，因此您不需要用户同意 SPA 的特定范围访问。

什么是身份验证和授权的完美方式？

这取决于很多事情。没有足够的信息来尝试回答这个问题。 OAuth2.0（可能实现了授权服务器）对于您在此处的示例来说是一个很好的方法。

或者如果没有第三方，OAuth2 可能完全是多余的？

如果其他应用程序会及时使用您的 API，那么 OAuth2.0 可能是一个不错的选择。否则，您可能会使用更简单的解决方案，例如所有会话 cookie 都位于同一个域中。

【参考方案2】：

这个问题的答案可以从OAuth 2.0 specification (RFC6749) 本身中得到。它定义了 ROPC 授权何时适合，

4.3. Resource Owner Password Credentials Grant

资源所有者密码凭据授予类型适用于 资源所有者与 客户端，例如设备操作系统或具有高权限的 应用。授权服务器应特别注意 启用此授权类型，并且仅在其他流未启用时才允许 vibl.

根据您的解释，您与 SPA 和后端紧密耦合。此外，您将授权服务器和资源服务器构建为一体。这完全是acceptable implementation。

授权服务器 可以是与资源服务器相同的服务器，也可以是单独的实体。

所以现在重要的是弄清楚为什么在你的场景中使用 OAuth 2.0。

如果您使用 OAuth 2.0 来获取令牌，请按照 OAuth 2.0 规范的定义来维护它们，那么这完全是老生常谈。但如果您这样做是为了顺应潮流，请三思。

OAuth 2.0 实施具有其自身的复杂性。您必须维护用户身份、维护令牌并更新它们。您正在自己构建一个完整的授权服务器。但这也有一些优点。

例如，相同的授权服务器可用于为未来的集成/辅助应用程序颁发令牌。 IMO，OAuth 2.0 的使用使集成变得容易，因为它定义了用于发布令牌、更新和撤销令牌的协议。！ 但在这种集成方案中，您可能需要使用不同的授权。尽管如此，您的 API 在令牌上被授权，您只需要担心新的集成/应用程序如何获取令牌。这比使用经过身份验证的会话更好

回到你的问题，

问：在这种情况下使用 ROPC 真的很危险吗？

如上所述，如果客户端和授权服务器之间存在正确的信任关系，则可以。但请注意，拥有授权服务器会带来复杂性。

问：身份验证和授权的最佳方式是什么？

OAuth 2.0 用于授权。您获取访问令牌并使用它们对您受保护的 API 进行授权。您可以通过 API 进行令牌验证以检测正确的访问级别/权限。

如果你想要authenticaiton，那么你必须使用OpenID Connect。它是从 OAuth 2.0 扩展而来的协议。并允许您的应用程序根据 ID Token 对最终用户进行身份验证。您可以使用 ROPC 授权来获取 ID 令牌。！

问：或者 OAuth2 在没有第三方的情况下完全是多余的？

不一定。它允许您以现代、标准的方式设计您的 API。谁知道未来会怎样（同样是集成场景）。遵循协议可以轻松实现。

仅提供建议，严格遵循规范。不要发明自己的协议/适配。它使事情更难维护。

【讨论】：

@dur IMO 规范中突出显示的要点是资源所有者与客户端建立信任关系的行。设备操作系统或特权应用程序就是一些例子。在 OP 的场景中，SPA 由后端 API（相同的组织）拥有。正如我强调的那样，这完全是关于信任关系

关于第二点，使用 OAuth 令牌与 API 进行通信比使用基本身份验证更好。当然可以使用 Session 代替，它会在登录后进行身份验证。但正如我强调的那样，它可能会使未来的集成变得困难。因此，如果 OP 想要灵活性，并且 OP 不试图追随趋势（仅仅因为一个流行词而使用 OAuth），那么 ROPC 就适用于这种特定场景。

谢谢。我有一个后续问题。如果我想为令牌获取添加一些其他安全措施，例如重新验证。那会与协议兼容吗？还是在这种情况下我应该放弃 OAuth 并创建自己的令牌获取解决方案？似乎找不到答案。

@TuanPham 好吧，这是您从 OAuth 获得的另一个好处。由于您在授权服务器上对最终用户进行身份验证，因此您的两因素身份验证在授权服务器上实现。您的应用程序不必担心这样的实现。这与协议无关，但与您选择最终用户身份验证的方式有关

是的，但正如我所说的，在授权服务器上，我使用 OAuth 协议来获取令牌。请记住，我的应用程序和我的应用程序服务器基本上是一体的。这里的 OAuth 只是一个令牌获取协议。我能否以某种方式在该令牌获取过程中添加一些额外的安全层，例如验证码？