I've written an AAD B2C custom policy which allows the user to update their sign-in email. There are examples of how to do this on GitHub (e.g. https://github.com/azure-ad-b2c/samples/tree/master/policies/change-sign-in-name). The policy works fine, but there is a problem. After the sign-in email has been changed and the user is returned to the application with updated "email" and "signInName" claims in the JWT, the AAD B2C session, for some reason, still holds the old sign-in email as the value of the "signInName" claim. I've tested this by using jwt.ms as a test application to see the contents of the JWT.
First I changed the sign-in email by running the change email custom policy.
JWT returned by the change email policy:
{
"alg": "RS256",
"kid": "...",
"typ": "JWT"
}.{
"ver": "1.0",
"iss": ".../v2.0/",
"sub": "...",
"aud": "...",
"exp": 1684332014,
"acr": "b2c_1a_change-email",
"nonce": "defaultNonce",
"iat": 1684328414,
"auth_time": 1684328414,
"email": "newSignInName@email.com",
"signInName": "newSignInName@email.com",
"tid": "...",
"nbf": 1684328414
}.[Signature]
Then I ran the sign-up/sign-in policy having a signed-in active session (the token is displayed immediately).
JWT returned by the sign-up/sign-in policy after SSO:
{
"alg": "RS256",
"kid": "...",
"typ": "JWT"
}.{
"ver": "1.0",
"iss": ".../v2.0/",
"sub": "...",
"aud": "...",
"exp": 1684332014,
"acr": "b2c_1a_signup-signin-sspr",
"nonce": "defaultNonce",
"iat": 1684328414,
"auth_time": 1684328414,
"signInName": "oldSignInName@email.com",
"tid": "...",
"nbf": 1684328414
}.[Signature]
As you can see, I have also returned the "signInName" claim at the end of the change email policy to make sure that it had been updated, however this doesn't get reflected in the session. This leads to strange behaviour if the user calls another custom policy from the same session after having changed the sign-in email. For example, any CIAM journey that would require an email verification would fail, because the old email would be used instead of the new.
I would like to know whether it's possible to update the session after having modified the sign-in email. This problem goes away if the user signs out and signs back in again with the new email address. I hope this makes sense.