是否可以在.NET Core Web应用程序中使用Azure AD B2C索赔来授权？
使用Microsoft Identity平台设置Azure AD B2C身份验证时，可以选择为用户存储和返回自定义索赔。这个问题是关于开发.NET Core Web应用程序时使用应用程序注册来登录用户的
.em>编辑：在这种情况下，Web应用程序不调用下游API-有一个Web应用程序（MVC） ），用户对AAD B2C进行身份验证，他们使用Web应用程序，而后端上的控制器则使用授权属性
您可以定义自定义属性“ teamId”，并将该属性返回，以返回该应用程序。用户登录 - 在这种情况下，它将在称为“ Extension_TeamID”的索赔中，并在Simepsprincipal上可用。
使用该索赔中的值确定用户属于哪个租户是安全的吗，或者可能会被用户欺骗该值，使其看起来似乎在另一个租户内 - 我会将其归类为授权信息微软指出，您绝不应该从ID令牌中检索，只有一个访问令牌：
ID令牌由授权服务器发出，并包含携带有关用户信息的索赔。它们可以与访问令牌一起发送，也可以与访问令牌一起发送。 ID令牌中的信息允许客户端验证用户自称是谁。 ID令牌旨在通过第三方应用程序来理解。 ID令牌不应用于授权目的。访问令牌用于授权。 ID令牌提供的索赔可用于您的应用程序中的UX，作为数据库中的键，并提供对客户端应用程序的访问。
https://learn.microsoft US/Azure/Active-Directory/develop/id-tokens
替代方法是将数据存储在将用户链接到团队的表中，用户B2C ID（GUID）用于查找其分配的团队首先从数据库开始，而不是直接从他们的主张中获取有关该团队的信息。
我可能会在ID令牌和访问令牌之间感到困惑，并想了解Microsoft Identity平台在这种情况下返回的内容。令牌是否从.NET Core Web应用程序前端发送到后端ID令牌或访问令牌？
When setting up Azure AD B2C authentication using the Microsoft Identity Platform there is an option to store and return custom claims for a user. The question is specifically about when developing a .NET Core Web Application that uses an App Registration to log users in.
EDIT: In this scenario, the web app does not call a downstream API - There is a single web app (MVC), the user authenticates against AAD B2C, they use the web app and the controllers on the back-end use an Authorize attribute
You can define a custom attribute "TeamId" and return that as a claim to the application that a user logs into - It will be in a claim called "extension_TeamId" in this case and available on the ClaimsPrincipal.
Is it safe to use the value in that claim to determine which tenant a user belongs to, or is it possible for that value to be spoofed by the user, making them appear to be within another tenant - I would class this as authorization information which Microsoft states you should never retrieve from an ID token, only an Access Token:
ID tokens are issued by the authorization server and contain claims that carry information about the user. They can be sent alongside or instead of an access token. Information in ID Tokens allows the client to verify that a user is who they claim to be. ID tokens are intended to be understood by third-party applications. ID tokens should not be used for authorization purposes. Access tokens are used for authorization. The claims provided by ID tokens can be used for UX inside your application, as keys in a database, and providing access to the client application.
https://learn.microsoft.com/en-us/azure/active-directory/develop/id-tokens
The alternative is to store the data in a table that links a user to a team, where the users B2C ID (Guid) is used to lookup their assigned team from the DB first, rather than taking it straight from their claims and looking up info about that team.
I may be getting confused between ID Tokens and Access Tokens and want to understand what the Microsoft Identity platform is returning in this case. Is the token sent from the .NET Core Web Applications front-end to the backend an ID Token or Access Token?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
返回的ID令牌将为接收客户端申请的详细信息提供有关用户如何身份验证和他的身份的详细信息。从ID-Token中，创建本地的“会话/身份”。 ID令牌并不意味着要传递给其他服务，通常它的寿命很短。
接收客户端使用接收的访问令牌来访问API和资源。客户端应用程序不需要查看访问令牌内部。
ID-Token中的索赔（可选地使用UserInfo端点的索赔）最终出现在本地用户会话中，可用于授权客户端应用程序中的各种功能。
因此，可以使用提供商的索赔来授权用户，但是您需要了解ID和访问令牌的不同用例。
The ID Token returned informs the receiving client application details about how the user authenticated and who he is. From the ID-token, the local "session/identity" is then created. The ID token is not meant to be passed around to other services and typically it has a very short lifetime.
The received access token is used by the receiving client to get access to APIs and resources. The client application should not need to look inside the access token.
The claims in the ID-token (optionally with the claims from the UserInfo endpoint) ends up in the local user session and can be used to authorize various features in the client application.
So, yes claims from the provider can be used to authorize the users, but you need to understand the different use cases for the ID and access token.