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.
Patrice Côté commented
Just for fun, how would you poke that "feature" if at least it was in your backlog? Not more than a 2 I guess. It seems like a "low hanging fruit" right there for you. Could even be implemented by the intern.
For a directory based on usernames, it beggars belief that username are not returned via JWT claims.
I like many other users here am beginning to regret turning to B2C. B2C has been such a hinderance to the development of our platform.
Oh Dear. I regret spending any time trying to implement B2C, I really do now.
There just isn't any way to use B2C meaningfully. Does anyone in MS realize that? I am not being sarcastic, it is just what it is.
Do you need OBO flow to call API? -> sorry, not implemented
Do you need username to actually know who logged in -> sorry, not implemented, nor planned.
This is embarrassment.
Its amazing to see some product owner guy has so much guts to give such an amazingly stupid reply that it is not even in the roadmap! If I wasn't forced by Fortune100 client to use ADB2C, I would have made a pass to use such ill-thought implementation
Wilson de Seabra commented
How many votes does this need to get to be considered for implementation? Shouldn't be such a daunting task to begin with, and with benefits for a lot of users.
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!