MFA with an SSO Identity Provider

Say that you use Okta as your identity provider. By using Okta's MFA service, you can offer users an experience like this:

• (1) The user goes to Salesforce and clicks a button to log in with Okta.
• (2) The browser redirects to Okta. The user enters their Okta username and password, and then completes MFA using the Okta Verify app.
• (3) Behind the scenes, Okta sends an authentication signal to Salesforce. The authentication signal tells Salesforce what MFA method the user used to log in.
• (4) Salesforce verifies that the authentication signal meets security requirements. The browser redirects back to Salesforce, where the user is now logged in.

The authentication signal in steps 3 and 4 is key. Salesforce uses this signal to confirm that the user completed MFA. If it isn't included, Salesforce requires the user to verify their identity using Salesforce MFA functionality. So even if your users log in with the identity provider's MFA service, they can be prompted to complete MFA again when they log in to Salesforce. As an admin, you probably want to avoid this outcome. For a seamless login experience, work with your identity provider to send the right signals.

How Do Identity Providers Send Authentication Signals to Salesforce?

The short answer is that identity providers can send Authentication Methods References (AMR) or Authentication Context Class Reference (ACR) values to Salesforce. SAML identity providers send these signals in the SAML response. OpenID Connect providers send them in the ID token.

If you're still learning about SSO, this statement can sound like a bunch of jargon. Here are the main points to know.

• There are two ways to set up SSO: SAML and OpenID Connect. SAML is older, while OpenID Connect is a more modern replacement. But they do the same thing: they enable you to outsource user authentication to a third-party identity provider.
  

  Note In Salesforce, you set up OpenID Connect using the authentication provider framework.
• Both SAML and OpenID Connect flows include a step where the identity provider tells Salesforce, "You can log this user in. I confirmed that they are who they claim to be." SAML identity providers complete this step by sending Salesforce a SAML response. OpenID Connect providers send an ID token. The format is different, but the purpose is the same: both are messages that contain information about the user and the login.
• AMR and ACR values are pieces of information that are included in the SAML response or ID token. Their purpose is to communicate what authentication method the user used to log in. This makes them a good way for the identity provider to tell Salesforce about the user's MFA method.

Authentication Signals in SAML Responses

SAML responses are long blocks of Extensible Markup Language (XML) with specific elements for different pieces of information.

Per the SAML standard, ACR values are included in the AuthnContextClassRef element, nested within the Authentication Statement (AuthnStatement). Here's an example excerpt from a SAML response. In this example, the value of the AuthnContextClassRef is urn:oasis:names:tc:SAML:2.0:ac:classes:hwk. The most important part of this value is hwk, which stands for hardware key. This value tells us that the user logged in to the identity provider and completed MFA using a hardware security key.

<saml2:AuthnStatement AuthnInstant="<timestamp>" SessionIndex="XYZ...">
  <saml2:AuthnContext>
    <saml2:AuthnContextClassRef>
      urn:oasis:names:tc:SAML:2.0:ac:classes:hwk
    </saml2:AuthnContextClassRef>
  </saml2:AuthnContext>
</saml2:AuthnStatement>

AMR values are less common in SAML, but some providers use them. There isn't a dedicated XML element for AMR values, so SAML providers typically send them as custom attributes in an AttributeStatement element. Here's an example SAML response excerpt with the same hwk value sent as an AMR signal.

<saml:AttributeStatement>
    <saml:Attribute Name="amr">
      <saml:AttributeValue>hwk</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>

Authentication Signals in ID Tokens

ID tokens are formatted as sets of JSON claims. Each claim contains a specific piece of information, such as the user's name (in this case, Admin User). Identity providers can send ACR values an acr claim.

{
  "sub": "XYZ...",
  "name": "Admin User",
  "email": "companyemail@example.com",
  "ver": 1,
  "iss": "https://MyIdentityProvider.com",
  "aud": "XYZ...",
  "iat": 1775666586,
  "exp": 1775670186,
  "acr": "hwk",
  "..."//additional claims omitted
}

Similarly, providers can send AMR values as an amr claim.

{
  "sub": "XYZ...",
  "name": "Admin User",
  "email": "companyemail@example.com",
  "ver": 1,
  "iss": "https://MyIdentityProvider.com",
  "aud": "XYZ...",
  "iat": 1775666586,
  "exp": 1775670186,
  "amr": [
    "hwk"
   ]
  "..."//additional claims omitted
}

What AMR and ACR values does Salesforce support?

Salesforce supports a variety of AMR and ACR values for both standard and phishing-resistant MFA. For a list, go to this knowledge artice and search for Authentication Strength Tiers.

How do I set up MFA with my identity provider?

See Set Up MFA with an SSO Identity Provider for high-level steps.

Note Salesforce can tell you what signals we support and how to check whether the identity provider is sending them correctly. But the steps to send MFA signals depend on your identity provider.