使用Azure AD保护共享的API

时间:2019-05-02 15:49:39

标签: azure azure-active-directory

我正在与客户一起定义安全策略,并且在尝试使某些东西正常工作时陷入困境。我是Azure AD的新手,所以实际上可能无法实现。

请考虑以下应用程序环境。 我有4个“ API”应用程序:

  • API-A,需要基于交互用户和角色的权限
  • API-B,通过服务守护程序访问,client_credential授予
  • API-C,不得直接通过身份验证
  • API-D,通过服务守护程序访问,client_credential授予

通过API-A或API-B认证的用户/恶魔也应该能够访问API-C。但是,根据API-D身份验证的恶魔必须 不能访问API-C。

我希望能够使用App Registrations的“公开API”和“ API权限”来控制JWT中返回的“角色”,我似乎无法使其正常工作或找不到关于如何实现这一目标的任何体面指南。

编辑:为清楚起见,API应用程序未托管在Azure内,我只是想使用Azure AD提供身份验证

1 个答案:

答案 0 :(得分:0)

区分客户端应用程序和API应用程序(或OAuth2语言中的资源服务器)可能对您有所帮助。它们每个都必须单独注册。您上面的列表似乎将它们合并在一起,这可能会使您感到困惑。

前者(客户端应用)获取令牌,后者通过服务请求从客户端接收令牌。 身份验证仅在客户端应用获取令牌时才涉及。 API不进行身份验证-它们使用令牌来授权访问其服务。客户端代表用户获取令牌-用户作为过程的一部分,或者代表自己(客户端凭据)进行身份验证和同意。在AAD中,API应用程序可以公开/定义可能包含在这些令牌类型之一或两者中的范围/权限。 API可能会决定不要求任何令牌(类似于API-C之类的声音)。您在API应用程序上公开(可用)权限,在客户端应用程序上指定(必需) API 权限。在运行时(如果使用AAD V2端点),客户端所请求的范围可能少于其按要求配置的范围。仅当客户端使用委托令牌(基于用户)时才适用。 (请注意,一个API应用也可能是另一个API应用的客户端应用(在多层系统中很常见)。

在其中部署客户端或API的BTW与上述内容完全无关。在大多数情况下,部署都会影响您需要为某些客户端应用程序(而非API)指定的回复网址的值。