AADB2C: include username in JWT claims
AADB2C supports either email addresses or usernames for accounts. If a directory uses usernames, you don't get that username as a claim in the JWT. This means an extra trip to Azure must be made to retrieve the username. Please consider including the username in the JWT.
This is currently not on our roadmap. You can retrieve this value by making a call through the Graph API. If this is needed for your scenarios, please continue voting and we will review at a later date.
Ioannis Angelakopoulos commented
Groups... username... the 2 most important claims missing. Crazy stuff... unbelievable!!!
Calling Graph is not an alternative...
Mikkel H. commented
Oh Lord! I thought I had made a mistake for not being able to get the username/email claim back when the user signs in.
You need to address this right now, Microsoft! I hate to mention it, but it's actually a bit embarrassing for you not to have resolved this years ago...
Artom Harchenko commented
If you use Identity Experience Framework (IEF) part of B2C, you can customize your policies to retrieve anything that you need and send it in the JWT.
Sujit Senapati commented
Yes. Please add username to the claims.
[Deleted User] commented
I can't stress enough how immature this thing is. It is useless for any serious development.
Yes. Please add username to the claims.
We added an extension attribute to the user to store the SignInName in order to avoid having to make another call to the Graph API.
Gaute Sanson commented
Please add. It seems strange that the user name that the end user inputs during the log-in should not be available further downstream in the same way as the other claims.
Thomas Nolan commented
Please add this. Spent hours wondering why username wasn't a returned value when retrieving a token. Did not even cross my mind that it wouldn't be included and another trip to get the username was needed.
James Griffin commented
Please please add this, so much unneccesary code in my application just to retrieve a username, and means making another unneccesary HTTP call for each time a user signs in. I'm shocked that this is unplanned and makes username based local accounts almost unusable
This is outrageous. Am I supposed to use the OID in in Applications to link users?!
Bill Noel commented
If you're set up to use email for the login AND you access that the first email in the EMAILS claim that comes back is probably their login name, then you can extract it on the client side.
And that's silly.
To do it right, there needs to be an actual claim that contains the login name. This would work for all scenarios.
I had to make a workaround for this - I access the graph during login. It works, but it adds an extra 500ms to each login and I have to do it server side if I want a solution that can choose either user name or email.
I know it's not planned, but it should be.
This is really surprising and not surprising at the same time with MS.
Who would have thought that it would be difficult in 2018 for an Enterprise ID Mgmt software to send back username in response to a successful request to create one!?
I was able to do hello <%username%> in 1998 without jumping hoops.
Amen to what Lucas said, please have this feature ASAP to return 'user name' in the token. It's part of the reason customers are opting for B2C, non managed ID and to have that credential passed to their apps.
This is such an obvious feature, can you please add ASAP! When you authenticate with a username you should have access to that value in the token!
God. Lacking this simple feature is insane. Literally why not
Chris Nott commented
What? I am flabbergasted that it is not available for inclusion....
This fields needs to be added ASAP
This fields needs to be added ASAP...
Yep, required. (This kind of thing seems fairly obvious, Microsoft - maybe you could do with some extra sanity-check steps during initial development where this type of thing is much cheaper to add?)