使用 OAuth2.0 或 Azure Active Directory 保护 REST API

Posted 2023-03-10

【中文标题】使用 OAuth2.0 或 Azure Active Directory 保护 REST API

【英文标题】：Securing REST API with OAuth2.0 or Azure Active Directory

【发布时间】：2017-08-29 07:41:26

【问题描述】：

我有一个 REST API，我从我的 Web 应用程序中调用它以获得结果。我有一个客户端，它只要求我的 API，但我不能在没有任何安全性的情况下公开我的 API。显然我也必须在我的应用程序中使用它，到目前为止 API 并不安全，我希望我的客户端使用有效凭据使用我的 API，无论是 OAuth 2.0、JWT、证书还是一些额外的机制。我怎样才能实现这个目标，任何使用 Azure 的 Java 工作示例都可以，并且它不应该妨碍我预先存在的 WebApp，该 WebApp 将 API 用于自己的目的。提前感谢。

【问题讨论】：

您考虑过 API Geteway 吗？ azure.microsoft.com/en-gb/services/api-management

@MurrayFoxcroft 我无法使用它，因为他们没有启用此功能的新门户。

【参考方案1】：

使用 Azure Active Directory 可以轻松保护 Web API。 Microsoft 提供了大量代码示例来帮助开发人员入门。

您可以参考以下链接了解您的场景的代码示例：

Azure Active Directory Code Samples

【参考方案2】：

我试着去做，我什至完成了任务，但最终发现它在我的情况下没有多大价值。在我的例子中，API 是由长时间运行的后台任务访问的，而人工登录是不切实际的。现在，应用程序无法登录到 Azure，它必须由浏览器应用程序完成，该浏览器应用程序受到所有可能的自动登录方式的保护。除此之外，微软针对此类任务的解决方案是shared secret-protected token，这实质上意味着应用程序和 Azure 共享一个秘密（由 Azure 生成的密码）。这与您存储和检查密码的情况没有太大区别。

除此之外，还有 Azure Active Directory 和 Azure Active Directory v2.0 的问题。这有点令人困惑，因为这两种解决方案都基于 OAuth2.0 令牌，但 Azure AD v2.0 确实是一个非常不同的野兽。首先，在撰写此答案时，无法解码 Azure AD v2.0 令牌，它们只能由 Microsoft 服务使用。因此，如果您想知道谁是已登录的用户，您需要将令牌传递给 Graph API，并且假设您有一个已登录的用户。对于 Azure AD，令牌可以由您的应用程序解码和验证，see this demonstration application, how to do it

总而言之，我建议仅当您为其提供登录服务的应用程序是用户在登录后与之交互的面向用户的应用程序时，才使用 Azure 令牌保护您的 API。如果它是一个长时间运行的服务器类型任务，那么使用 Azure AD 保护它是毫无意义的。