APIs for identity management

[mkArtakMSFT]

• Add API endpoints for generating identity tokens #47227
• Add token refresh endpoints to identity #47228
• Support changing username and email using identity endpoints #47229
• Add 2fa support to token identity endpoints #47230
• Add reset password support to identity endpoints #47231
• Support account lockout with identity endpoints #47232

[fmendez89]

Hi, regarding the phone number confirmation, as Identity supports it, will an endpoint be included or it should be handled by the application itself?

Thanks, nice work here :)

[famda]

@mkArtakMSFT @danroth27
I don't know who to mark on this comment.

The new MapIdentityApi will accept any kind of configuration for disabling some endpoints?

Simple use case would be, not having the Register endpoint but having the rest of it.

Thanks in advance.

[ejsmith]

What is the easiest way to make the returned tokens be JWT tokens instead of whatever format they are now? Also, is there some reason why your team has decided to not use JWT as the format for the tokens?

[danroth27]

@JeremyLikness

[JeremyLikness]

What is the easiest way to make the returned tokens be JWT tokens instead of whatever format they are now? Also, is there some reason why your team has decided to not use JWT as the format for the tokens?

Hi @ejsmith @davidfowl can probably explain this best. The primary scenario we are focused on is cookie-based auth. The token isn't intended to be used across apps or domains, so it is intentionally opaque and functionally is encrypted like and contains the same payload as the cookie. The only reason we added token support was for exceptional edge cases when cookies absolutely won't work, such as a mobile client that for some reason can't use a cookie container/manager or open a web page for authentication. We want to avoid any confusion that we're providing an OIDC server or even a replacement for one (we're not), and also don't expect the token to be used outside of the application it is generated for. If that scenario is needed, then a service like Microsoft Entra or a full OIDC server are the recommended solutions.

Can you share more details around your scenario and requirements and the need for JWT?

[ejsmith]

What is the easiest way to make the returned tokens be JWT tokens instead of whatever format they are now? Also, is there some reason why your team has decided to not use JWT as the format for the tokens?

We want to avoid any confusion that we're providing an OIDC server or even a replacement for one (we're not), and also don't expect the token to be used outside of the application it is generated for.

I would suggest not using OIDC terminology on the endpoints then like access_token.

Can you share more details around your scenario and requirements and the need for JWT?

I was just hoping that I could decode the token in the client in order to get info about the user like you can with a normal JWT like their name and claims. Claims would allow enabling and disabling features client side as well is knowing when the token expires. Since the token is stored as a cookie and we are using the token with a SPA application, we don't know when the users session has expired until we make an API request which isn't ideal. Couldn't the token be in JWT format and still stored in a cookie so that it works for both cookie mode as well as pure SPA JWT mode where the token is stored and passed as an auth header? I know you can pass the token as an auth header now, but again, it's just not ideal IMO that we aren't able to decode the token and get the info out of it client side and instead we would need to make a separate API request to get the info like what roles the user belongs to. Does that make sense?

[m-meier]

I would suggest not using OIDC terminology on the endpoints then like access_token.

I think the term access token predates JWTs or OIDC. Many platforms use access token that are not JWTs.

I was just hoping that I could decode the token in the client in order to get info about the user like you can with a normal JWT like their name and claims. Claims would allow enabling and disabling features client side as well is knowing when the token expires. Since the token is stored as a cookie and we are using the token with a SPA application, we don't know when the users session has expired until we make an API request which isn't ideal. Couldn't the token be in JWT format and still stored in a cookie so that it works for both cookie mode as well as pure SPA JWT mode where the token is stored and passed as an auth header? I know you can pass the token as an auth header now, but again, it's just not ideal IMO that we aren't able to decode the token and get the info out of it client side and instead we would need to make a separate API request to get the info like what roles the user belongs to. Does that make sense?

Your use case makes a lot of sense, I'm in the same boat in that I need to immediately need to do a /info lookup after login. But I'd like to present a different view which makes a case for the current implementation I think:
JWTs are (by nature) large since they need to store all information. This is great for distributed systems where auth and services are decoupled. This size however can present a problem when attempting to store it in a cookie. Also, on every request you need to send all that user info along in the http request although the server already has the information. I think after a couple of requests this additional bandwidth quickly outweights the initial info request (from a mobile application perspective). Also I usually don't want to expose all my claims to the user so you'd need to be able to configure which claims you want to include.
Something I haven't tried, therefore I don't know if it applies: Sliding Expiration. Since JWTs have a fixed expiration you wouldn't be able to use that feature (altough tbh I don't know if it works with the current bearer token).

I think a better solution would be if we'd have an alternative to PasswordSignInAsync which does not automatically fill the response but instead returns the Bearer authentication data. It would then be easy to create your own login endpoint which can augment the response with custom data (user name, display name, roles, ...). This would be the best of both worlds.. having an easy way to return user info without additional requests but at the same time keep the access token small und compact.

[ejsmith]

I would suggest not using OIDC terminology on the endpoints then like access_token.

I think the term access token predates JWTs or OIDC. Many platforms use access token that are not JWTs.

Maybe the term is older than OIDC, but OIDC is pretty much the industry standard and is very well known at this point. If the stated goal is to not cause confusion then why use the term at all? Call it a ticket or something else because it has already caused me and I'm sure others confusion.

You make a good point about the token size, but I think that should be a choice / trade off you leave to the developers. I think ideally we could choose between normal JWT and reference token / ticket mode. As well as having an endpoint to easily get full claim details about the reference token.

[ajay-managaon]

Is this only for Minimal API's or extended to classic controller API's?

[davidfowl]

@famda Currently not, but I agree that it should have the ability to disable endpoints or groups of endpoints based on what features you want exposed.

@ejsmith First, JWTs can be encrypted as well so using a JWT doesn't mean you can decode the user information client side.

We didn't do JWT because we have a ticket format with that supports key rotation based on data protection already, it was most expedient to reuse that format, rather than trying to add support for producing a JWT from the DP APIs (which was looked into).

@ajay-managaon These are endpoints that are exposed when you call an API, they are implemented using minimal APIs and no there are no plans to make their implementation controller based (though you can easily copy the source if you want to do that).

[ejsmith]

Thanks for the response @davidfowl.

What about the problem of using these endpoints in a SPA and wanting to know user info client side like what roles they belong to and when their auth expires? Also, there are no endpoints to manage users / roles. I know you guys are adding these endpoints specifically to support SPA scenarios, but it seems like there are some holes in the feature set to support that scenario easily out of the box. I know we can build those ourselves and I guess these APIs get us a little closer, but IMO they are not complete.

[davidfowl]

I don't think we have this functionality in any form today AFAIK. These endpoints cover what we have in the existing identity UI. I'm sure people will come up with infinity more special cases for missing endpoints for their apps, but this is the first release. Once people start using them, we'll be able to learn from a broader set of feedback what the most important things are to add.

[ejsmith]

I was thinking that the identity razor UI had ability to manage users / roles? Anyway, we can build these things ourselves. Just giving some feedback that it feels like there are some missing features to cover the general use cases. I understand that there will always be extra things people want that are impossible to cover them all, but IMO the things I'm pointing out are core use cases and almost required to say that ASPNET Core has an out of the box auth story.

[jacobvisick]

Are there any plans to extend registration using these APIs? A common use case, I'd imagine, is collecting a user's first/last name during registration.

In the existing Identity UI, it's a fairly straightforward process of scaffolding the registration page, adding those inputs to the page, and assigning those properties on the code behind. From what I can tell with the new Identity APIs, you're currently stuck with only accepting an email & password on registration or rolling your own registration endpoint. At the very least, it would be nice to be able to easily configure some custom logic for some subset of the Identity endpoints.

It would be really great if it would look TUser provided and automatically configure some behavior based on the required properties, but I recognize that may be a pipe dream.

[augustevn]

I don't know where to ask this question but, I'm getting bad confirmation links from the Identity endpoints.
I must be missing the configuration to add the base url? This is formed in the htmlMessage coming from the IEmailSender.

http://auth/confirmEmail?userId=6338db8a-02d0-4a48-9d32-fc18f20fb45a&code=Q2ZESjhBSEFKN1NWdWVGRnNBL1JDLzY4YitnaVcrdk91aGJyVFpqYTR5dy9PUFZhOW1ZbUpmalo3MWplVXZRYjNaK0ZqYnA5d0xveDk4a1hsbWFraHR1Ym9CYTZVZXdzZzVZQnFCbWpIYk9LaE5raWVGR2xYczBsSEdHYzFUVTZQaTRUVXp1ZExRRnNSSUhVYkV5RSsrUXgvWGR2T1hGclFCRTZoLzBaV0JxbDd1bFBZVDZNNFFiaGN1b0d1ZElEZFl3M0ZlUmZ6NklmL3FiaEo4VjJWZENhT29Fa1RrbEJrRlRqRS9UNk8vRTJMRjdNVjljU0grZk5tWU5Hc0p5UlIzd0xCQT09

Using Identity version 8.0.0-rc.1.23421.29