Pass Dynamic Authentication Context
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's exposed through an Okta Expression Language claim and you can configure it 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
- If you haven't done so already, create a custom app integration or add an OIN app integration through the Okta Admin Console.
- To create a custom SAML app integration, see Create SAML app integrations.
- To add an OIN app integration, see Add existing app integrations. Your external application must support SAML.
- Add an Attribute Statement to the app integration (for more details, see Define group attribute statements):
You can add the statement while creating a new app integration or edit an existing app integration.
- In the Admin Console, go to .
- Click the custom SAML app.
- Go to the General tab, scroll to the section SAML Settings, and then click Edit.
- Click Next.
- Scroll to the section Attribute Statements (Optional).
- In the Admin Console, go to .
- Click the OIN SAML app integration.
- Go to the Sign On tab, then click Edit.
- Scroll to the section Attribute Statements (Optional).
- In Name, enter a name for the attribute you want to add.
- In Name format, select Unspecified.
For a new app integration:
In Step 2: Configure SAML, scroll to the section Attribute Statements (Optional).
For an existing app integration:
This procedure varies depending on whether you are editing a custom app integration or an OIN app integration.
If editing a custom app integration:
If editing an OIN app integration:
The maximum length for this field is 512 characters. The Name attribute must be unique across all of the user and group attribute statements.
- In Value, enter session.amr
- Click Next.
- Click Finish.
Assertion examples
The following assertion excerpts show examples of single-value versus multi-value authentication-context attributes for the amr attribute statement.
When using just a password:
<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:Attribute>When using a password 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> </saml:Attribute>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.