Enforce step-up Multi-Factor Authentication (MFA) for secure applications without prompting users for a password. By utilizing two separate OpenID Connect applications and Authentication Policies, Okta prompts users for a possession factor at the secure application while bypassing the password requirement. This architecture relies on the fact that two separate sets of tokens are generated and must be managed independently by the client application.

• Okta Identity Engine (OIE)
• OpenID Connect/OAuth 2.0 application
• Authentication Policies
• Multi-Factor Authentication (MFA)
• Step-up Authentication

Applications often require step-up authentication for sensitive actions while forcing the user to re-enter a password. Using a single Authentication Policy causes Okta to prompt for the last-used factor when passing specific authorization parameters, resulting in a password prompt for users who only authenticate with a password.

How are the applications and policies configured for step-up authentication without password prompts in Okta?

Configure the environment by creating two separate applications, defining distinct Authentication Policies for standard and secure access, and explicitly excluding passwords from the step-up policy.

1. Create a main application in Okta for standard user access.
2. Create a second step-up application for sensitive operations requiring stricter access controls.
3. Create two Authentication Policies in the Admin Console.
4. Configure the first policy with standard access requirements and assign the main application to it.
5. Configure the second policy to explicitly exclude the password as an authenticator and require a possession factor (such as phone or email).
6. Assign the step-up application to the second policy.

The step-up authentication flow utilizes specific authorization parameters.

Enforce the step-up authentication requirement and control session intervals by appending specific parameters to the step-up application's authorization URL.

• Use the acr_values parameter to specify the required authenticator class (for example, urn:okta:loa:1fa:any). Because the second application explicitly excludes passwords in its Authentication Policy, passing this parameter forces Okta to challenge only for the configured possession factors.
• Use the max_age parameter to control how often Okta prompts for the factor.
• Set max_age=0 to force Okta to prompt for the required factor immediately. This ensures that the step-up application always prompts the user, even if an active session exists or the factor has already been fulfilled.
• Set max_age to a specific interval in seconds (for example, max_age=300) to force Okta to re-prompt the user only after that time expires.

How does the client application manage two sets of tokens?

Manage the distinct standard and step-up sessions by configuring the client application to handle two separate sets of tokens independently.

• Because this configuration requires a main application and a step-up application, Okta issues two distinct sets of tokens.
• The main application tokens govern the standard user session.
• The step-up application tokens govern access to the secure resources and enforce the possession factor requirement without prompting for a password.
• Configure the storageKey as detailed in the Okta AuthJS documentation, to avoid overwriting tokens when managing multiple sets.

What security enhancements apply to the step-up transaction?

Implement additional security measures for the step-up transaction by verifying token identifiers, binding tokens to devices, and customizing the sign-in widget.

• Compare the user identifiers (sub claim) between the main application token and the step-up application token to ensure the user who logged in is the same user performing the step-up transaction.
• Set a custom code challenge identifier to include the transaction details, ensuring the binding is pinned to the specific transaction.
• Add Demonstrating Proof-of-Possession (DPoP) to ensure the token is bound to the device.
• Hide the "back to Sign-in" link on the Okta-hosted sign-in widget during the MFA challenge based on the application ID by injecting the following code:

config.features.hideSignOutLinkInMFA = true;

Related References

• Okta AuthJS Documentation
• Hide the "Back to Sign In" Link on the Okta Hosted Sign-In Widget During MFA Challenge