Pass Dynamic Authentication Context to SAML Apps

You can pass Dynamic Authentication Context to your SAML apps through the SAML assertion during application authentication. The app can then use the information to limit access to certain app-specific behaviors and calculate the risk profile for the logged-in user.

The feature works with both custom and OIN-sourced SAML app integrations. It is exposed via an Okta Expression Language claim and can be configured as a custom SAML attribute. Depending on the number of factors used during authentication, the attribute can generate one or multiple values in the assertion (see Assertion examples).

Developers can also use the Okta Apps API to configure the custom attribute. The process of passing authentication contexts is similar to using claims containing authentication method references (amr) in OIDC Apps.

Enable Dynamic Authentication Method References

  1. If you have not done so already, create a custom app integration or add an OIN app integration through the Okta Admin Console.
  2. Add an Attribute Statement to the app integration (for more details, see Define Attribute Statements):

    You can add the statement while creating a new app integration or as an edit to an existing app integration.

  3. When creating the app integration:

    In Step 2: Configure SAML, scroll to the section Attribute Statements (Optional).

    – or –

    To edit an existing app integration:

    The procedure varies depending on whether you are editing a custom app integration or an OIN app integration.

    If editing a custom app integration:

    1. In the Okta Admin Console, go to Applications > Applications.
    2. Click the custom SAML app.
    3. Go to the General tab, scroll to the section SAML Settings, and then click Edit.
    4. Click Next.
    5. Scroll to the section Attribute Statements (Optional).
    6. Continue to Step 4 below.

    If editing an OIN app

    1. In the Okta Admin Console, go to Applications > Applications.
    2. Click the OIN SAML app integration.
    3. Go to the Sign On tab, scroll to the section Attribute Statements (Optional), and then click Edit.
    4. Continue to Step 4 below.

  4. In Name, enter a name for the attribute you want to add.
  5. The maximum length for this field is 512 characters. The Name attribute must be unique across all of the user and group attribute statements.

  6. In Name format, select Unspecified.
  1. In Value, enter session.amr.
  2. Click Next.
  3. Click Finish when done.

Assertion examples

The following assertion excerpts show examples of single-value versus multi-value authentication-context attributes for the amr attribute statement.

When just a password is used:

<saml:Attribute Name="amr" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

<saml:AttributeValue xsi:type="xs:string">pwd</saml:AttributeValue


When a password is used with Okta Verify as a second factor:

<saml:Attribute Name="amr" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

<saml:AttributeValue xsi:type="xs:string">pwd</saml:AttributeValue>

<saml:AttributeValue xsi:type="xs:string">mfa</saml:AttributeValue>

<saml:AttributeValue xsi:type="xs:string">swk</saml:AttributeValue>




Currently, Okta supports only Dynamic SAML Authentication Context and Smart card for primary Identity Provider (IdP) authentication. For example, if you use a federated IdP to sign in to your application and use Dynamic SAML, the assertion only contains pwd as a default value. Similarly, if you use Smart card, the assertion only contains sc as the default value.

Related topics

The Applications Page

Create SAML app integrations using AIW

Create custom app integrations

Expression Language