我们正在使用Angular，.Net WebApi和Azure构建多个应用程序。我们一直在做的是通过隐式oAuth2 / OIDC授权流程通过Azure AD保护应用程序。
事情进展顺利，但到目前为止我们已经有了一个简单的架构。 IE＆＃39;前端App1＆＃39; - ＆GT; ＆＃39; WebApi App1＆＃39;
当我们向AAD请求令牌时，我们在令牌请求中发送资源（＆＃39; WebApi App1＆＃39;的应用ID）。看来这是令牌请求中的必需属性。这是如何扩大的？
假设我们遇到的情况是＆＃39;前端App1＆＃39;需要与WebApi App1＆＃39;和#Att; WebApi App2＆＃39;。我们需要发出多个令牌请求吗？在Azure中，人们在这些情况下做了什么？将承载令牌紧密地耦合到一个资源似乎很不可靠。
似乎另一种方法是我可以将api应用程序配置为验证相同Azure租户和应用程序ID的令牌。这样，令牌对任何一个应用程序都有好处，但这并不是非常灵活，因为这意味着任何一个应用程序的所有令牌都对另一个应用程序有利...
答案 0 :(得分：1)
您有两种选择：
获取每个API的令牌是正常的方法。
Azure AD中的承载令牌始终仅对一个API有效。 它可以包含该API上的调用用户/应用程序的范围/角色，并且这些值是在应用程序清单中定义的简单字符串，例如， User.Read。 这些值可以在API之间重叠，因此我们不能拥有对两个API有效的令牌。
答案 1 :(得分：1)
问题陈述：如何使用UI应用程序中的相同令牌调用多个WebApi。
我的解决方案：
让有两个Web-Api，WebApi01和WebApi02。 在Azure AD中，我没有注册两个应用程序，而是注册了一个应用程序，例如MasterAPI。 此外，必须照常注册客户端应用程序（即UI应用程序）。
MasterAPI不是实际的应用程序。因此，可能没有任何重定向URL，我们也不需要任何重定向URL。在此API中，我们为每个WebAPI（WebAPI01和WebAPI02）声明两个范围。我通常会遵循App.Feature.Verb等命名法。因此，作用域名称将类似于 Master.WebAPI01.Read 和 Master.WebAPI02.Read 。
它们将像 api：//MasterAPI-Application-Id//Master.WebAPI01.Read 和 api：//MasterAPI-Application-Id//Master.WebAPI02一样公开。在天蓝色的应用程序注册页面中阅读。
在访问令牌请求期间，我将这两个范围传递给Azure AD终结点。我得到的响应包含范围声明（scp），其值为“ Master.WebAPI01.Read Master.WebAPI02.Read”。
“ scp”：“ Master.WebAPI01.Read Master.WebAPI02.Read”
这样，我告诉系统受信任的Client-UI应用程序具有一个令牌，该令牌可访问两个功能。 简而言之，无论谁可以登录到客户端应用程序，都将有权使用这两种功能。 现在，已通过身份验证的用户有权使用两个功能。
这可以进一步限制。说，我（管理员）应该控制谁可以访问什么。 为此，我必须实现基于角色的访问控制（RBAC）。我在MasterAPI中定义了定制应用程序角色。 这可以通过操作清单来完成。
现在，当我收到访问令牌时，我将获得具有设置值的角色声明。该值取决于分配给用户的角色。
“角色”：[ “ Access_WebAPI01”， “ Access_WebAPI02” ]
令牌通过标头传递到资源WebAPI（在本例中为WebAPI01或WebAPI02）。接收方WebAPI然后解析标头令牌以检查所需角色是否存在。
因此，简而言之，Scope和RBAC的组合对我有用。而且我不必点击数据库即可进行身份验证和授权。
如果添加了新功能，例如WebAPI03。我需要做的就是在MasterAPI中设置作用域。或使用现有角色或为用户分配新角色。
PS：为什么选择MasterAPI？在Azure AD中，所有范围都必须仅来自一种资源。