Issue propagating MFA context (AMR/ACR) in Azure AD B2C custom policies with multiple federated IdPs - Salesforce

Question

Issue propagating MFA context (AMR/ACR) in Azure AD B2C custom policies with multiple federated IdPs - Salesforce

Patnala, Ramesh (Consultant) 0

We are implementing Azure AD B2C custom policies with two federated custom Identity Providers. After authentication, we need to ensure MFA context is correctly represented in the token issued by B2C and consumed by Salesforce.

We want to ensure that after authentication:

MFA completion is consistently represented in the issued token
Salesforce receives a reliable MFA indicator (AMR/ACR or equivalent)
No additional MFA prompt is triggered downstream

What is the recommended pattern for handling AMR/ACR in B2C custom policies when multiple IdPs are involved? Is AMR preserved automatically or must it be explicitly set via claims transformation or OutputClaims?

Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-04-28T19:48:18.54+00:00
Hello Patnala, Ramesh (Consultant),

Azure AD B2C does not preserve AMR/ACR from federated Identity Providers automatically in a reliable way. When using multiple custom IdPs, the recommended approach is to capture the MFA information explicitly and include it in the token issued to Salesforce.

In each federated IdP technical profile (OIDC or SAML), check whether the IdP sends claims such as amr, acr, or any custom MFA indicator.

Map those values using OutputClaims to internal B2C claims such as amr, acr, or a custom claim like mfaSatisfied.

Example:

<OutputClaims> <OutputClaim ClaimTypeReferenceId="amr" PartnerClaimType="amr" /> <OutputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr" /> </OutputClaims>

Since different IdPs may return MFA details in different formats, use claims transformation to normalize them into one consistent claim such as:

mfaSatisfied = true

This provides Salesforce with a single trusted MFA indicator instead of handling different claim formats from each IdP.

If the external IdP does not provide a reliable MFA claim, enforce MFA directly in Azure AD B2C using the MFA orchestration step.

In the Relying Party policy, include the final MFA-related claims in the issued token:

<OutputClaim ClaimTypeReferenceId="amr" /> <OutputClaim ClaimTypeReferenceId="acr" /> <OutputClaim ClaimTypeReferenceId="mfaSatisfied" />

This ensures Salesforce receives the MFA context and helps prevent additional MFA prompts.

AMR should not be expected to flow automatically from the external IdP through B2C. It should be explicitly mapped, normalized, and included in the final token.

For multiple federated IdPs with Salesforce as the relying party, the best practice is to let B2C act as the trusted MFA authority by validating upstream MFA or performing MFA itself, then issuing a clear and consistent MFA claim to Salesforce.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-04-30T01:22:44.8466667+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.

Patnala, Ramesh (Consultant) 0

@Anonymous I tried your suggestions, but it’s still not working. Please find the files below and advise how to pass the default amr values as ["pwd", "mfa"] to Salesforce (Referenece - https://help.salesforce.com/s/articleView?id=005237070&type=1)

Extension file
Signup file

1.Extension file

<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"

PolicySchemaVersion="0.3.0.0"

TenantId="mytenant.onmicrosoft.com"

PolicyId="B2C_1A_TRUSTFRAMEWORKEXTENSIONS"

PublicPolicyUri="http://mytenant.onmicrosoft.com/"

TenantObjectId="xxxx">

<TenantId>mytenant.onmicrosoft.com</TenantId>

<PolicyId>B2C_1A_TRUSTFRAMEWORKBASE</PolicyId>

</BasePolicy>

<ClaimsSchema>

  <ClaimType Id="sub">

    <DisplayName>Subject</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="email">

    <DisplayName>Email Address</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="givenName">

    <DisplayName>Given Name</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="surname">

    <DisplayName>Surname</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="objectId">

    <DisplayName>Object Id</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="identityProvider">

    <DisplayName>Identity Provider</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="identityProviderAccessToken">

    <DisplayName>Identity Provider Access Token</DisplayName>

    <DataType>string</DataType>

  </ClaimType>

  <ClaimType Id="extension_Agency"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretQuestion1"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretAnswer1"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretQuestion2"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretAnswer2"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretQuestion3"><DataType>string</DataType></ClaimType>

  <ClaimType Id="extension_SecretAnswer3"><DataType>string</DataType></ClaimType>

  

  <ClaimType Id="acr">

<DisplayName>Authentication Context Class Reference</DisplayName>

<DataType>string</DataType>

</ClaimType>

  <!-- AMR claim -->

<DataType>stringCollection</DataType>

<Protocol Name="OAuth2" PartnerClaimType="amr" />

</DefaultPartnerClaimTypes>

</ClaimType>

  <ClaimType Id="mfaItem">

<DataType>string</DataType>

</ClaimType>

<DisplayName>MFA Method</DisplayName>

<DataType>string</DataType>

</ClaimType>

<DataType>string</DataType>

</ClaimType>

<DisplayName>Password Item</DisplayName>

<DataType>string</DataType>

</ClaimType>

</ClaimsSchema>



<ClaimsTransformations>

<ClaimsTransformation Id="AddPwdToAmr"

TransformationMethod="AddItemToStringCollection">

<!-- collection -->

<InputClaim ClaimTypeReferenceId="amr"

  TransformationClaimType="collection" />

<!-- item (THIS WAS MISSING) -->

<InputClaim ClaimTypeReferenceId="pwdItem"

  TransformationClaimType="item" />

</InputClaims>

<OutputClaim ClaimTypeReferenceId="amr"

  TransformationClaimType="collection" />

</OutputClaims>

</ClaimsTransformation>

<ClaimsTransformation Id="AddMfaToAmr"

TransformationMethod="AddItemToStringCollection">

<InputClaim ClaimTypeReferenceId="amr"

  TransformationClaimType="collection" />

<InputClaim ClaimTypeReferenceId="mfaItem"

  TransformationClaimType="item" />

</InputClaims>

<OutputClaim ClaimTypeReferenceId="amr"

  TransformationClaimType="collection" />

</OutputClaims>

</ClaimsTransformation>

</ClaimsTransformations>

  <ContentDefinitions>

<ContentDefinition Id="api.signinandsignupwithpassword1.1">

<LoadUri>https://login.microsoftonline.com/static/tenant/templates/AzureBlue/unified.cshtml</LoadUri>

<RecoveryUri>~/common/default_page_error.html</RecoveryUri>

<DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0</DataUri>

<Item Key="DisplayName">Unified sign-in or sign-up page</Item>

<Item Key="language.intro">Sign in to continue</Item>

</Metadata>

</ContentDefinition>

  <ContentDefinition Id="api.signuporsignin">

    <LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>

    <RecoveryUri>~/common/default_page_error.html</RecoveryUri>

    <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0</DataUri>

    <Metadata>

      <Item Key="DisplayName">Sign up or sign in</Item>

    </Metadata>

  </ContentDefinition>

</ContentDefinitions>

</BuildingBlocks>

<DisplayName>Init AMR Items</DisplayName>

<!-- ADD MFA -->

<TechnicalProfile Id="AddMfaAmr">

<DisplayName>AddMfaAmr</DisplayName>

  <Protocol Name="Proprietary"

    Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine" />

  <OutputClaims>

    <OutputClaim ClaimTypeReferenceId="amr" />

  </OutputClaims>

  <OutputClaimsTransformations>

    <OutputClaimsTransformation ReferenceId="AddMfaToAmr" />

  </OutputClaimsTransformations>

  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />

</TechnicalProfile>

<Protocol Name="Proprietary"

Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine" />

<OutputClaim ClaimTypeReferenceId="amr"

             DefaultValue="[]"

             AlwaysUseDefaultValue="true" />

</OutputClaims>

</TechnicalProfile>

</TechnicalProfiles>

</ClaimsProvider>

<DisplayName>Set AMR for Salesforce</DisplayName>

<DisplayName>Set AMR for Salesforce</DisplayName>

<Protocol Name="Proprietary"

Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine" />

<OutputClaim ClaimTypeReferenceId="amr"

DefaultValue="[]"

AlwaysUseDefaultValue="true" />

<OutputClaim ClaimTypeReferenceId="pwdItem"

DefaultValue="pwd"

AlwaysUseDefaultValue="true" />

<OutputClaim ClaimTypeReferenceId="mfaItem"

DefaultValue="mfa"

AlwaysUseDefaultValue="true" />

</OutputClaims>

<OutputClaimsTransformation ReferenceId="AddPwdToAmr" />

<OutputClaimsTransformation ReferenceId="AddMfaToAmr" />

</OutputClaimsTransformations>

</TechnicalProfile>

</TechnicalProfiles>

</ClaimsProvider>

  <DisplayName>Azure Active Directory</DisplayName>

  <TechnicalProfiles>

    <TechnicalProfile Id="AAD-Common">

      <DisplayName>Azure AD Common</DisplayName>

      <Protocol Name="Proprietary"

        Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine" />

      <Metadata>

        <Item Key="TenantId">mytenant.onmicrosoft.com</Item>

      </Metadata>

    </TechnicalProfile>

    <!-- READ USER -->

    <TechnicalProfile Id="AAD-UserReadUsingObjectId">

      <DisplayName>Read user</DisplayName>

      <Protocol Name="Proprietary"

        Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine" />

      <Metadata>

        <Item Key="Operation">Read</Item>

        <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

      </Metadata>

      <InputClaims>

        <InputClaim ClaimTypeReferenceId="objectId" Required="true" />

      </InputClaims>

      <OutputClaims>

        <OutputClaim ClaimTypeReferenceId="objectId" />

        <OutputClaim ClaimTypeReferenceId="email" />

        <OutputClaim ClaimTypeReferenceId="givenName" />

        <OutputClaim ClaimTypeReferenceId="surname" />

      </OutputClaims>

      <IncludeTechnicalProfile ReferenceId="AAD-Common" />

    </TechnicalProfile>

  </TechnicalProfiles>

</ClaimsProvider>

<!-- ================= JWT ISSUER ================= -->

<!-- <ClaimsProvider>

  <DisplayName>Token Issuer</DisplayName>

  <TechnicalProfiles>

    <TechnicalProfile Id="JwtIssuer">

<DisplayName>JWT Issuer</DisplayName>

<Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>

<Item Key="token_lifetime_secs">3600</Item>

</Metadata>

<Key Id="issuer_secret"

  StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />

</CryptographicKeys>

</TechnicalProfile>

  </TechnicalProfiles>

</ClaimsProvider> -->



<!-- SESSION -->

<ClaimsProvider>

  <DisplayName>Session Management</DisplayName>

  <TechnicalProfiles>

    <TechnicalProfile Id="SM-AAD">

      <DisplayName>Session Management</DisplayName>

      <Protocol Name="Proprietary"

        Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine" />

      <PersistedClaims>

        <PersistedClaim ClaimTypeReferenceId="objectId" />

      </PersistedClaims>

      <OutputClaims>

        <OutputClaim ClaimTypeReferenceId="objectId" />

      </OutputClaims>

    </TechnicalProfile>

    <TechnicalProfile Id="SM-Noop">

      <DisplayName>Noop</DisplayName>

      <Protocol Name="Proprietary"

        Handler="Web.TPEngine.SSO.NoopSSOSessionProvider, Web.TPEngine" />

    </TechnicalProfile>

  </TechnicalProfiles>

</ClaimsProvider>

<!-- DOHMH -->

<ClaimsProvider>

  <DisplayName>DOHMH</DisplayName>

  <TechnicalProfiles>

    <TechnicalProfile Id="OIDC-DOHMH">

      <DisplayName>DOHMH</DisplayName>

      <Protocol Name="OpenIdConnect" />

      <Metadata>

        <Item Key="METADATA">https://login.microsoftonline.com/xxxx/v2.0/.well-known/openid-configuration</Item>

        <Item Key="client_id">xxxx</Item>

        <Item Key="response_types">code</Item>

        <Item Key="scope">openid profile email</Item>

        <Item Key="response_mode">form_post</Item>

        <Item Key="UsePolicyInRedirectUri">false</Item>

      </Metadata>

      <CryptographicKeys>

        <Key Id="client_secret" StorageReferenceId="B2C_1A_DOHMH" />

      </CryptographicKeys>

	   

	   <OutputClaims>

        <OutputClaim ClaimTypeReferenceId="sub" PartnerClaimType="sub" />

        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />

        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" />

        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />

        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />

        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />

        <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />

        <!-- <OutputClaim ClaimTypeReferenceId="amr" DefaultValue="pwd mfa" PartnerClaimType="authnmethodsreferences"/> -->

          <!--  <OutputClaim ClaimTypeReferenceId="amr" DefaultValue="pwd mfa" PartnerClaimType="authnmethodsreferences"/>-->

		<OutputClaim ClaimTypeReferenceId="extension_Agency" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer1" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer2" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer3" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion1" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion2" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion3" />

      </OutputClaims>

	

   		  

    </TechnicalProfile>

  </TechnicalProfiles>

</ClaimsProvider>

 <!-- DOTB2B -->

<ClaimsProvider>

  <DisplayName>DOTB2B</DisplayName>

  <TechnicalProfiles>

  <TechnicalProfile Id="SM-jwt-issuer">

<DisplayName>Session Management Provider</DisplayName>

</TechnicalProfile>

<DisplayName>JWT Issuer</DisplayName>

<Item Key="client_id">xxxx</Item>

<Item Key="issuer_refresh_token_user_identity_claim_type">objectId</Item>

<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item>

</Metadata>

<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />

<Key Id="issuer_refresh_token_key" StorageReferenceId="B2C_1A_TokenEncryptionKeyContainer" />

</CryptographicKeys>

        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>		

        <OutputClaim ClaimTypeReferenceId="amr" PartnerClaimType="amr" />			

      </OutputClaims>

</TechnicalProfile>

    <TechnicalProfile Id="OIDC-DOTB2B">

      <DisplayName>DOTB2B-Ganesh4</DisplayName>

      <Protocol Name="OpenIdConnect" />

      <Metadata>

        <Item Key="METADATA">https://login.microsoftonline.com/xxxx/v2.0/.well-known/openid-configuration</Item>

        <Item Key="client_id">xxxxx</Item>

        <Item Key="response_types">code</Item>

        <Item Key="scope">openid profile email</Item>

        <Item Key="response_mode">form_post</Item>

        <Item Key="HttpBinding">POST</Item>

        <Item Key="UsePolicyInRedirectUri">false</Item>

      </Metadata>

      <CryptographicKeys>

        <Key Id="client_secret" StorageReferenceId="B2C_1A_DOTB2B" />

      </CryptographicKeys>

      <OutputClaims>

        <OutputClaim ClaimTypeReferenceId="sub" PartnerClaimType="sub" />

        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />

        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" />

        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />

        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />

        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />

        <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />

       <!-- <OutputClaim ClaimTypeReferenceId="amr" DefaultValue="pwd mfa" PartnerClaimType="authnmethodsreferences"/> -->

         <!--   <OutputClaim ClaimTypeReferenceId="amr" DefaultValue="pwd mfa" PartnerClaimType="authnmethodsreferences"/>-->

        <OutputClaim ClaimTypeReferenceId="extension_Agency" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer1" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer2" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretAnswer3" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion1" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion2" />

        <OutputClaim ClaimTypeReferenceId="extension_SecretQuestion3" />

      </OutputClaims>

    </TechnicalProfile>

  </TechnicalProfiles>

</ClaimsProvider>

</ClaimsProviders>

<OrchestrationStep Order="1"

Type="CombinedSignInAndSignUp"

ContentDefinitionReferenceId="api.signuporsignin">

<ClaimsProviderSelection TargetClaimsExchangeId="DOHMH" />

<ClaimsProviderSelection TargetClaimsExchangeId="DOTB2B" />

</ClaimsProviderSelections>

</OrchestrationStep>

<ClaimsExchanges>

  <ClaimsExchange Id="DOHMH"

    TechnicalProfileReferenceId="OIDC-DOHMH" />

  <ClaimsExchange Id="DOTB2B"

    TechnicalProfileReferenceId="OIDC-DOTB2B" />

</ClaimsExchanges>

</OrchestrationStep>

<ClaimsExchange Id="SetAmr"

  TechnicalProfileReferenceId="SetAmrForSalesforce" />

</ClaimsExchanges>

</OrchestrationStep>

<OrchestrationStep Order="4" Type="SendClaims"

CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

</OrchestrationSteps>

</UserJourney>

</UserJourneys>

</TrustFrameworkPolicy>

signupsign file

<ClaimsSchema>

<DisplayName>MFA Satisfied</DisplayName>

<DataType>boolean</DataType>

</ClaimType>

<DisplayName>Authentication Context Class Reference</DisplayName>

<DataType>string</DataType>

</ClaimType>

</ClaimsSchema>

</BuildingBlocks>

<DefaultUserJourney ReferenceId="B2CSignUpOrSignInWithPassword_V3" />

<UserJourneyBehaviors>

  <SessionExpiryType>Rolling</SessionExpiryType>

  <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>

</UserJourneyBehaviors>





<TechnicalProfile Id="PolicyProfile">

  <DisplayName>PolicyProfile</DisplayName>

  <Protocol Name="OpenIdConnect"/>

  <OutputClaims>

    <!-- MUST match exactly one OutputClaim for SubjectNamingInfo -->

    <OutputClaim ClaimTypeReferenceId="objectId"/>

    <!-- Optional additional claims -->

    <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>

    <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>

    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="emails"/>

    <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="idp"/>

    <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="idp_access_token"/>

    <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" PartnerClaimType="tfp" DefaultValue="{policy}"/>

    <OutputClaim ClaimTypeReferenceId="amr" PartnerClaimType="amr"/>

  </OutputClaims>

  <!-- SubjectNamingInfo must reference the claim without PartnerClaimType -->

  <SubjectNamingInfo ClaimType="objectId"/>

</TechnicalProfile>

</RelyingParty>

</TrustFrameworkPolicy>

Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-04-30T17:12:25.6866667+00:00
Hello Patnala, Ramesh (Consultant),

Thanks for sharing the policy files. I reviewed your configuration and the issue is with how amr is being initialized and then overwritten.

Using DefaultValue="[]" treats it as a string, not a collection, so the transformations don’t build ["pwd","mfa"] correctly. Also, reinitializing amr later clears any values added earlier.

Please remove DefaultValue="[]" wherever it is used for amr and do not initialize it manually. Let the transformations create and populate the collection.

Update the transformations like below so they don’t depend on an existing collection:

<ClaimsTransformation Id="AddPwdToAmr" TransformationMethod="AddItemToStringCollection"> <InputClaims> <InputClaim ClaimTypeReferenceId="pwdItem" TransformationClaimType="item" /> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="amr" TransformationClaimType="collection" /> </OutputClaims> </ClaimsTransformation> <ClaimsTransformation Id="AddMfaToAmr" TransformationMethod="AddItemToStringCollection"> <InputClaims> <InputClaim ClaimTypeReferenceId="mfaItem" TransformationClaimType="item" /> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="amr" TransformationClaimType="collection" /> </OutputClaims> </ClaimsTransformation>

In SetAmrForSalesforce, keep it simple and do not initialize amr:

<OutputClaims> <OutputClaim ClaimTypeReferenceId="pwdItem" DefaultValue="pwd" AlwaysUseDefaultValue="true" /> <OutputClaim ClaimTypeReferenceId="mfaItem" DefaultValue="mfa" AlwaysUseDefaultValue="true" /> <OutputClaim ClaimTypeReferenceId="amr" /> </OutputClaims>

Your orchestration step is already in the correct place, so after this change the token will include:

"amr": ["pwd","mfa"]

which is what Salesforce expects.

One thing to note: this always sends "mfa". That’s fine if MFA is guaranteed (either at the IdP or enforced in B2C). Otherwise, you may want to make it conditional.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-01T22:12:21.1166667+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.
Patnala, Ramesh (Consultant) 0 Reputation points

2026-05-01T23:12:42.0866667+00:00

@Sridevi Machavarapu We are encountering an issue with the amr claim in the IDP token for our Azure AD B2C integration with Entra ID (OIDC).

Current Behavior

The token currently returns:

"amr": ["pwd"]

Even though we are passing acr_values=mfa, the MFA authentication is not being reflected in the token.

Expected Behavior

After successful MFA, the token should include:

"amr": ["pwd", "mfa"]
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-04T22:19:48.82+00:00
Hello Patnala, Ramesh (Consultant),

This is expected behavior.

When you send acr_values=mfa, it only asks for MFA. It does not guarantee that "mfa" will be added to the amr claim. The IdP decides what to include in the token.

In Microsoft Entra ID, even if MFA happens, the token can still return:

"amr": ["pwd"]

In Azure AD B2C, the final token is created based on your policy. Claims from the IdP are not always carried over, so you should not rely on amr coming from the IdP.

What you should do instead:

don’t depend on amr from the IdP

set the amr value in your B2C policy before issuing the token

Sending:

"amr": ["pwd","mfa"]

to Salesforce is the correct way when you need a consistent MFA indicator.

Just note, this always includes "mfa". If MFA is not always performed, you may want to make it conditional.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-05T23:46:18.96+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.

1 answer

Your answer

Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-04-28T19:48:18.54+00:00

Hello Patnala, Ramesh (Consultant),

Azure AD B2C does not preserve AMR/ACR from federated Identity Providers automatically in a reliable way. When using multiple custom IdPs, the recommended approach is to capture the MFA information explicitly and include it in the token issued to Salesforce.

In each federated IdP technical profile (OIDC or SAML), check whether the IdP sends claims such as amr, acr, or any custom MFA indicator.

Map those values using OutputClaims to internal B2C claims such as amr, acr, or a custom claim like mfaSatisfied.

Example:

<OutputClaims> <OutputClaim ClaimTypeReferenceId="amr" PartnerClaimType="amr" /> <OutputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr" /> </OutputClaims>

Since different IdPs may return MFA details in different formats, use claims transformation to normalize them into one consistent claim such as:

mfaSatisfied = true

This provides Salesforce with a single trusted MFA indicator instead of handling different claim formats from each IdP.

If the external IdP does not provide a reliable MFA claim, enforce MFA directly in Azure AD B2C using the MFA orchestration step.

In the Relying Party policy, include the final MFA-related claims in the issued token:

<OutputClaim ClaimTypeReferenceId="amr" /> <OutputClaim ClaimTypeReferenceId="acr" /> <OutputClaim ClaimTypeReferenceId="mfaSatisfied" />

This ensures Salesforce receives the MFA context and helps prevent additional MFA prompts.

AMR should not be expected to flow automatically from the external IdP through B2C. It should be explicitly mapped, normalized, and included in the final token.

For multiple federated IdPs with Salesforce as the relying party, the best practice is to let B2C act as the trusted MFA authority by validating upstream MFA or performing MFA itself, then issuing a clear and consistent MFA claim to Salesforce.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-04-30T01:22:44.8466667+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-01T22:12:21.1166667+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.
Patnala, Ramesh (Consultant) 0 Reputation points

2026-05-01T23:12:42.0866667+00:00

@Sridevi Machavarapu We are encountering an issue with the amr claim in the IDP token for our Azure AD B2C integration with Entra ID (OIDC).

Current Behavior

The token currently returns:

"amr": ["pwd"]

Even though we are passing acr_values=mfa, the MFA authentication is not being reflected in the token.

Expected Behavior

After successful MFA, the token should include:

"amr": ["pwd", "mfa"]
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-04T22:19:48.82+00:00

Hello Patnala, Ramesh (Consultant),

This is expected behavior.

When you send acr_values=mfa, it only asks for MFA. It does not guarantee that "mfa" will be added to the amr claim. The IdP decides what to include in the token.

In Microsoft Entra ID, even if MFA happens, the token can still return:

"amr": ["pwd"]

In Azure AD B2C, the final token is created based on your policy. Claims from the IdP are not always carried over, so you should not rely on amr coming from the IdP.

What you should do instead:

don’t depend on amr from the IdP

set the amr value in your B2C policy before issuing the token

Sending:

"amr": ["pwd","mfa"]

to Salesforce is the correct way when you need a consistent MFA indicator.

Just note, this always includes "mfa". If MFA is not always performed, you may want to make it conditional.
Sridevi Machavarapu 29,290 Reputation points Microsoft External Staff Moderator

2026-05-05T23:46:18.96+00:00

Hello Patnala, Ramesh (Consultant),

Please confirm here if any further queries on this.

Answer 1

In Azure AD B2C custom policies, MFA context (AMR/ACR) is not automatically normalized or propagated across multiple IdPs in a way that downstream apps like Salesforce can reliably consume. The recommended pattern is to explicitly control and emit the MFA indicator in the B2C-issued token, independent of how each upstream IdP represents MFA.

Key points based on the provided material:

B2C MFA is its own step and protocol handler
When MFA is performed by Azure AD B2C itself (SMS/TOTP), it is implemented via a dedicated technical profile using the proprietary Azure MFA protocol handler:
```
   <TechnicalProfile Id="AzureMfa-SendSms">
       <DisplayName>Send Sms</DisplayName>
       <Protocol Name="Proprietary" 
                 Handler="Web.TPEngine.Providers.AzureMfaProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
       ...
   </TechnicalProfile>
```
This means that when B2C performs MFA, the fact that MFA occurred is known inside the user journey and can be surfaced as claims in later steps and in the final token.

External MFA providers and AMR/ACR expectations
For external providers (including external MFA providers or federated IdPs), Microsoft Entra ID expects:

The provider posts back an id_token to the redirect_uri.
The id_token contains standard claims including acr and amr:

	Claim	Description
	`acr`	Authentication context class reference – must match one of the requested values and only one `acr` claim should be returned.
	`amr`	Authentication methods reference – array with the method used.

Microsoft Entra ID validates these claims against the OIDC metadata and the requested acr values. This is the pattern for integrating an external MFA provider and having Entra/B2C understand which authentication method was used. Reference: "Use Microsoft Entra MFA with an external MFA provider" shows the required id_token and acr/amr behavior.

Multiple IdPs: do not rely on automatic AMR/ACR preservation
With multiple federated IdPs, each IdP may:
- Use different acr values.
- Use different amr semantics or omit them.
B2C does not automatically normalize these into a single, consistent MFA indicator for downstream apps. Instead, the recommended pattern is:
- Treat the upstream IdP’s acr/amr as input claims in the relevant technical profile.
- Use claims transformations and/or orchestration logic to map those into a single, B2C-controlled claim (for example, mfa_done = true or a normalized acr value) that is then emitted in the relying party (RP) policy.
This way, Salesforce only needs to look at the B2C-issued claim, not at each IdP’s native amr/acr format.
Recommended pattern for B2C → Salesforce MFA signaling For a reliable MFA indicator and to avoid extra prompts in Salesforce:
1. Perform or validate MFA in B2C
  - Either use B2C’s own MFA technical profiles (SMS/TOTP) as part of the user journey, or
  - Integrate an external MFA provider that returns acr/amr in its id_token as described in the Entra external MFA documentation.
2. Normalize MFA into a dedicated claim
  - In the custom policy’s orchestration steps, after the MFA step (B2C or external), use a claims transformation to set a normalized claim, for example:
    - authentication_methods_reference (string/array) with a value like mfa, or
    - mfa_completed = true, or
    - a normalized acr value such as urn:microsoft:entra:mfa.
3. Emit the normalized claim in the RP policy
  - In the relying party file (for the Salesforce SAML/OIDC integration), include this normalized claim in OutputClaims so it appears in the token sent to Salesforce.
  - Configure Salesforce to treat that claim as the MFA indicator and to suppress additional MFA prompts when it is present and has the expected value.
4. Do not depend on raw upstream AMR/ACR
  - Because different IdPs may send different amr/acr values, always map them to the B2C-controlled claim before sending to Salesforce.
Is AMR preserved automatically or must it be explicitly set?
- For external MFA providers integrated via OIDC, Entra/B2C validates acr/amr from the provider’s id_token, but does not guarantee that these raw values will be emitted unchanged to downstream apps.
- For B2C-native MFA (AzureMfaProtocolProvider), MFA is known to the policy engine but again must be explicitly surfaced as an output claim.
- Therefore, for a multi-IdP scenario and for Salesforce integration, the MFA context must be explicitly set and emitted via claims transformations and OutputClaims. Do not rely on automatic AMR/ACR preservation.

Summary:

Use B2C’s MFA technical profiles or an external MFA provider that returns acr/amr in its id_token.
Normalize MFA into a single B2C-controlled claim via claims transformations.
Emit that claim in the RP policy so Salesforce receives a consistent MFA indicator and can skip additional MFA.
AMR/ACR from upstream IdPs are not a reliable, automatically preserved signal; they should be explicitly mapped and output.

References:

Share via

Issue propagating MFA context (AMR/ACR) in Azure AD B2C custom policies with multiple federated IdPs - Salesforce

1 answer

Your answer