我将通过MSAL.js将我们的安全体系结构从ASP.NET Core Identity迁移到Azure AD V2。我们在ASP.NET Core Identity实现中使用了很多角色，并且使用Web应用程序在数据库中管理信息。我放弃的模式与此类似。
https://www.dotnetcurry.com/aspnet-core/role-based-security
带有MSAL的Azure AD正在运行。令牌将被创建和传递，并且如预期的那样，将兑现装饰有通用[Authorize]属性的本地Web API端点。用[Authorize(Roles= "Fee, Foo, Fi, Fum")]装饰的Web API端点将引发401未经授权的错误。
我不确定从这里去哪里。是否为Web API编写CustomAuthorize属性覆盖，然后返回数据库并获取角色。 （可能根据电子邮件地址将数据库定义的角色与用户匹配）
OR
是否可以通过Azure AD V2本地实现角色？
我不确定从这里开始的最佳做法是什么。文档和代码示例似乎很有限。只需将AD用户放入组中并让该组在Web API中得到尊重就可以了。另一方面，最好在Web应用程序范围内处理角色委托。
任何建议，经验或兴趣都将不胜感激。
答案
关注我的问题。 @Marc，您是正确的，在查看了令牌后，角色不存在。将角色添加到令牌中似乎很简单。您需要修补图形架构以包括它们，配置角色并根据需要通过AAD将其分配给用户。
或者乍一看就是这样。深入研究之后，它需要一个P1或P2 Enterprise许可证，该许可证 only 仅需每个用户每月额外支付6美元。实际上，这将使我们在云中托管电子邮件的成本增加一倍。
或者，我为WebAPI编写了CustomAuthAttribute，并在服务器后端将“用户和角色”绑定在一起。仍然可以通过Web应用程序管理角色，用户仍然可以使用Active Directory凭据登录。
答案 0 :(得分：0)
我还记得隐式流（与JS一起使用）返回的id令牌不包含应用程序角色（或组）。我找不到任何文档来确认这一点，但是see others的人通过使用Graph获取角色（或组）来解决问题（因此问题一定在那儿）。
您可以捕获从AAD收到的令牌，并使用https://jwt.ms查看它，以查看其中是否包含角色。