0

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?

Dan Harris
  • 1,336
  • 1
  • 21
  • 44

1 Answers1

1

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.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • Thanks, so just to clarify - In the .NET Core web app scenario: once the user is authenticated, each subsequent request that they make (to the web app backend nowhere else) exposes the User object, this is a ClaimsPrincipal and has all the claims returned from the provider (Azure AD B2C in this case) - Are those claims returned in an ID Token or Access Token? And is there any risk of a user manipulating those? – Dan Harris Jun 30 '22 at 15:01
  • no, the User Object is only scoped to the client application where the user is logged in. The access token and its content it passed to the backend APIs that you might talk to. Where the claims are included (ID or Access token) you need to configure in Azure, some user claims is needed in the access token and some in the ID-token, but it all depends on your needs. The user can't tamper with the tokens, so its safe. – Tore Nestenius Jul 01 '22 at 07:37