Missing from the token response: Wrong Placeholder when changing the email address.

[rajeshjadi-encora]

Copilot Usage Confirmation

• I have tried using GitHub Copilot to resolve this issue.

MSAL Version

1.7.0

Description

When performing the Change Email & Password flow using the configured policy, the returned token response does not include the email claim.

This causes issues because the application expects the updated email address to be available in the token after the flow completes.

The problem occurs only during the Change Email policy execution, while other policies work as expected.
Policy Used:
{
"kEditProfilePolicy": "B2C_1A_ProfileEdit",
"kResetPasswordPolicy": "B2C_1A_PasswordChange",
"kChangeEmailPolicy": "B2C_1A_EmailChange"
}

Error Details

Missing from the token response in email address fields.

MSAL Logs

.

Reproduction Steps

1. Log in to the application via MSAL SDK triggered browser(SFSafariViewController) window.
2. Trigger the Change Email flow from app.
3. Redirect to MSAL SDK triggered browser(SFSafariViewController) window.
4. Check the Email address field which contains message(Missing from the token response) in email field instead original user email address.

Expected Behavior

The token response should include the updated email claim reflecting the new email address.

User must need to show its email address instead of Missing from the token response in email field.

Regression

No response

Screenshots & Screen Recordings

Additional context

This behaviour is working as expected in android app.

[github-actions]

Hello, thanks for reaching out.

Summary: You’re seeing the email claim missing in the token returned after running your Azure AD B2C “Change Email” policy via MSAL, while other policies return the expected claims.

A few clarifications to help us triage:

• Which token are you reading for the email (ID token vs access token), and which exact claim name does the app expect (“email”, “emails”, or “preferred_username”)?
• Can you share a sanitized token payload (header+claims only, no signature) from the Change Email flow versus a normal sign-in, inspected via https://jwt.ms?
• What authority and scopes are used for the Change Email flow (please confirm you include “openid profile”), and are you calling acquireTokenInteractive again after the email change completes?
• Please attach MSAL logs for the interactive call (timestamps, correlation ID) with PII disabled, plus iOS version/device and whether broker/Company Portal is involved.

Guidance and next steps:

• MSAL surfaces whatever the server issues—claim presence is controlled by your B2C user flow/custom policy. For a Change Email policy, ensure the Token Issuance technical profile includes the desired claim as an OutputClaim (e.g., “emails” or “preferred_username”; “email” is optional and often not emitted by default). Docs: Azure AD B2C tokens and claims (https://learn.microsoft.com/azure/active-directory-b2c/tokens-overview) and customizing token claims (https://learn.microsoft.com/azure/active-directory-b2c/custom-policy-token-format).
• Many B2C apps use “preferred_username” or the “emails” array rather than “email”. If your app expects “email”, consider mapping the updated attribute to that claim in your policy.
• After changing the email, you may need to acquire a fresh token under your sign-in policy (interactive, with prompt=login) to see updated claims; avoid relying on a previously cached token.
• If this is a custom policy, please share the relevant Token Issuer/Technical Profile OutputClaims snippet (redacted) or try the “change sign-in name” sample to compare behavior (https://github.com/azure-ad-b2c/samples).

If you provide the above details and logs, we can confirm whether anything on the MSAL side needs attention; otherwise this is likely a policy/token issuance configuration issue in B2C rather than an MSAL SDK bug.

This comment was generated by an automated assistant to help with initial triage. A maintainer will follow up as needed.

[rajeshjadi-encora]

Hello Juan Arias (@juan-arias), Is there any update on this?

[juan-arias]

rajeshjadi-encora we are waiting for your answers to the questions and logs the AI requested.

[rajeshjadi-encora]

HI Juan Arias (@juan-arias) ,

Please have a look at the request information.

Which token are you reading for the email (ID token vs access token), and which exact claim name does the app expect (“email”, “emails”, or “preferred_username”)?
=> We are using ID token

Can you share a sanitized token payload (header+claims only, no signature) from the Change Email flow versus a normal sign-in, inspected via https://jwt.ms/?

Simple Sign-In
{
"alg": "RS256",
"kid": "REDACTED",
"typ": "JWT"
}
{
"exp": 1775656381,
"nbf": 1775569981,
"ver": "1.0",
"iss": "https://tenant-domain/tenant-id/v2.0/",
"sub": "00000000-0000-0000-0000-000000000000",
"aud": "client-id",
"acr": "b2c_1a_signup_signin",
"iat": 1775569981,
"auth_time": 1775569980,
"email": "user@domain.com",
"name": "REDACTED",
"given_name": "REDACTED",
"family_name": "REDACTED",
"tid": "tenant-id",
"at_hash": "REDACTED"
}

Change Email Flow
{
"alg": "RS256",
"kid": "REDACTED",
"typ": "JWT"
}
{
"exp": 1775657528,
"nbf": 1775571128,
"ver": "1.0",
"iss": "https://tenant-domain/tenant-id/v2.0/",
"sub": "00000000-0000-0000-0000-000000000000",
"aud": "client-id",
"acr": "b2c_1a_emailchange",
"iat": 1775571128,
"auth_time": 1775571127,
"name": "REDACTED",
"given_name": "REDACTED",
"family_name": "REDACTED",
"email": "user@domain.com",
"mfa": "1",
"mfaTime": 1775571057,
"tid": "tenant-id",
"at_hash": "REDACTED"
}

What authority and scopes are used for the Change Email flow (please confirm you include “openid profile”), and are you calling acquireTokenInteractive again after the email change completes?

Authority:
https:///tfp//B2C_1A_EmailChange

Scopes:
openid profile offline_access

acquireTokenInteractive after email change:
No — acquireTokenInteractive is NOT called again after the email change completes.

Please attach MSAL logs for the interactive call (timestamps, correlation ID) with PII disabled, plus iOS version/device and whether broker/Company Portal is involved.
=> result?.correlationId: 6443B670-E764-4372-9EC9-28C4D29E94BE

Please let me know if any additional information, just for info this flow is working fine in android application with same configufation.

[juan-arias]

Thanks for the token payloads rajeshjadi-encora they're very helpful.

Both your sign-in and change-email tokens lack the preferred_username claim, so MSAL sets account.username
to a placeholder (the error message you see). The email claim is present in both tokens.

To get the email, don't use account.username. Instead, read it from the ID token claims directly:

NSString *email = result.account.accountClaims[@"email"];

Or in Swift:

let email = result.account.accountClaims?["email"] as? String

Alternatively, configure your B2C custom policy to emit a preferred_username output claim in the token issuer technical profile.

[rajeshjadidminc]

Hello,

Thanks for the response, and apologies for the delay in getting back to you. Since multiple applications are connected through SO, we needed to proceed carefully before applying changes to any environment.

We have now applied the suggested changes and verified the flows. Below is a summary along with the requested token logs.

Simple Sign-In

Token Response:

{
  "alg": "RS256",
  "kid": "REDACTED",
  "typ": "JWT"
}
{
  "exp": 1779289604,
  "nbf": 1779203204,
  "ver": "1.0",
  "iss": "https://tenant-domain/tenant-id/v2.0/",
  "sub": "00000000-0000-0000-0000-000000000000",
  "aud": "client-id",
  "acr": "b2c_1a_signup_signin",
  "iat": 1779203204,
  "auth_time": 1779203202,
  "email": "user@domain.com",
  "preferred_username": "user@domain.com",
  "name": "REDACTED",
  "given_name": "REDACTED",
  "family_name": "REDACTED",
  "tid": "tenant-id",
  "at_hash": "REDACTED"
}

Observation:
preferred_username is now present in the token.

---

Change Email Flow

Token Response:

{
  "alg": "RS256",
  "kid": "REDACTED",
  "typ": "JWT"
}
{
  "exp": 1779291323,
  "nbf": 1779204923,
  "ver": "1.0",
  "iss": "https://tenant-domain/tenant-id/v2.0/",
  "sub": "00000000-0000-0000-0000-000000000000",
  "aud": "client-id",
  "acr": "b2c_1a_emailchange",
  "iat": 1779204923,
  "auth_time": 1779204921,
  "email": "user@domain.com",
  "preferred_username": "user@domain.com",
  "name": "REDACTED",
  "given_name": "REDACTED",
  "family_name": "REDACTED",
  "mfa": "1",
  "mfaTime": 1779204904,
  "tid": "tenant-id",
  "at_hash": "REDACTED"
}

Observation:
preferred_username is also present in the Change Email flow token.

Screenshot / Evidence:

Please let us know if any additional validation or changes are required from our side.

[rajeshjadidminc]

Kai (@kaisong1990) Is there any update on this ?

[agubuzomaximus]

Hi rajeshjadidminc, thanks for confirming the policy update and providing the new token payloads. Both flows now return preferred_username, so MSAL should populate account.username instead of the "Missing from the token response" placeholder. This confirms the original behavior was caused by the B2C policy not emitting preferred_username, rather than an MSAL token-processing issue.

No additional validation is required from your side. When the application specifically needs the email address, we recommend reading the email claim from result.account.accountClaims rather than relying on account.username, since the username is not guaranteed to represent an email address. Based on the updated token payloads, the reported issue is resolved. Please let us know if the placeholder still appears with the updated token.