@John-Garland thank you so much for catching this -I can reproduce it. I feel like instead of using.GetNameIdentifierId() for retrievingsub, we can be more explicit with something like.FindFirstValue(ClaimConstants.Sub);. In that case we would also need to set theJwtSecurityTokenHandler.DefaultMapInboundClaims tofalse inStartup.cs though -happy to discuss!

Good question. My inclination would be to keep the sample as small/self-contained as possible. I worry that turning off claims mapping would imply it as a necessary step for using MSAL/MSIW with B2C. Perhaps, however we can achieve the goal of being explicit about the origin of the claim (I agree that sub-->nameidentifier is hardly obvious) with some strategic comments calling out the expected conversion and also suggesting the approach above as an alternative? (If that idea resonates, I can update the PR accordingly.)

Comments sound good to me! As long as we explain what we're after and what alternatives out there we're all good (I just came across a good discussion on this issuehere)

Good thread. I guess this takes me back to my original question - should these samples advocate for a "cleaner" approach to handling JWT token claims and recommend that claims mapping be disabled across the board? I could see using this as an opportunity to retrofit the other exercises in this sequence as well (though done as a separate PR...)

Thinking about it, I'm going to use the comment approach I mentioned, but I would love to have a broader conversation about disabling the mapping and if it should eb something we advocate across the samples (and elsewhere!)

Claims mapping usually functions well in AAD use cases, at least I don't remember an instance where it led us astray. But for B2C use cases it might be a good idea, since it has various idiosyncrasies like this. Let me bring this up with my team, at least for B2C samples cc@kalyankrishna1