I'm integrating an OIDC client with Okta and would like to dynamically control the level of authentication assurance (1FA vs 2FA) based on the context of the request, using the acr_values parameter.

Use Case:

• On initial login, users should be required to perform MFA (e.g., password + OTP).
• On re-authentication requests triggered by sensitive actions, I want to allow password-only authentication (i.e., urn:okta:loa:1fa:pwd) — essentially skipping MFA if the session is fresh and low-risk.

I’m using:

prompt=login

max_age=0

acr_values=urn:okta:loa:1fa:pwd

Despite this, Okta still prompts for MFA, and the resulting ID token shows:

"acr": "urn:okta:loa:1fa:pwd",

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

My questions:

• How can I configure Okta’s authentication/sign-on policies to dynamically honor the requested acr_values, based on the current OIDC request, not static user attributes (like groups)?
• Is there a way to define policy rules that respond to re-authentication context (e.g., detecting prompt=login or max_age=0 with a specific ACR) and downgrade the required assurance level appropriately?
• If this isn't natively supported, are there alternative Okta-supported strategies?

To clarify: I do not want to segment users into different groups for 1FA vs 2FA. The same user should experience MFA at login, and password-only on sensitive re-authentication flows, as controlled by the app via acr_values.

Any guidance or best practices would be greatly appreciated — especially from those who’ve implemented fine-grained assurance handling with Okta and OIDC.

Thanks!