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

时间:2017-04-04 08:04:18

标签: java azure oauth-2.0 active-directory jwt

我有一个REST API,我在我的Web应用程序中调用以获得结果。我有一个客户端只询问我的API,但我无法在没有任何安全性的情况下公开我的API。显然我必须将它与我的应用程序一起使用,到目前为止API并不安全,我希望我的客户端使用我的API以及有效的凭据,无论是OAuth 2.0,JWT,证书还是一些额外的机制。我如何实现这一目标,任何使用Azure的Java工作示例都可以做到,并且它不应该妨碍我为其自身目的使用API​​的预先存在的WebApp。提前谢谢。

2 个答案:

答案 0 :(得分:2)

我试图这样做,我甚至完成了任务,但最终发现它在我的案例中没有提供太多价值。在我的情况下,API由长时间运行的后台任务访问,其中人员登录不实用。现在,应用程序无法登录Azure,它必须由浏览器应用程序完成,该应用程序受到所有可能的自动登录方式的保护。除此之外,Microsoft针对这些类型任务的解决方案是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保护它是没有意义的。

答案 1 :(得分:0)

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

您可以参考以下链接,了解您的方案的代码示例:

Azure Active Directory Code Samples