OktaIndranil JhaExplainer
Step
Summary
Step-up authentication lets an application permit access to non-critical resources with basic authentication while requiring additional authentication for sensitive resources. The post describes how Okta Workforce Identity Cloud supports this pattern across modern OIDC applications and legacy integrations. For OIDC, applications use the /authorize endpoint’s acr_values and max_age parameters to request a mapped higher assurance level for a limited period, or prompt=login to force re-authentication each time. For non-OIDC applications, privileged Factor API operations can issue and verify challenges through a protected middleware layer using an Okta API token, while Okta Access Gateway can enforce step-up through advanced policies. Transactional MFA is presented as an alternative using OIDC CIBA, but the source defers its detailed treatment.
Context
The subject is balancing frictionless access with stronger protection for sensitive resources. The source covers OIDC applications, non-OIDC applications using Factor APIs, legacy applications behind Okta Access Gateway, and transactional MFA as a related pattern.
Approach / What changed
For OIDC, initiate a new authorization request with acr_values and max_age for temporary higher assurance, or prompt=login for forced re-authentication. For non-OIDC applications, use Factor API endpoints through a secure middleware or business layer, protecting the required static Okta API token. Okta Access Gateway can apply advanced policies to legacy header-authenticated applications.
Takeaways
OIDC step-up uses predefined acr_values mapped to Workforce Identity Cloud assurance levels; custom acr_values cannot currently be defined.
Factor APIs can issue and verify challenges for non-OIDC applications, but privileged calls require protected server-side processing and a properly secured static Okta API token.
Okta Access Gateway can enforce step-up for legacy web applications through advanced policies, while transactional MFA can use OIDC CIBA for approval-based access.
FAQ
How can an OIDC application avoid repeated step-up challenges?
The application can request a higher assurance level with acr_values and specify max_age. After successful step-up, the session remains at that assurance level for the stipulated duration, so later access within that period does not require another challenge.
What is the difference between step-up and re-authentication-only?
Step-up requests additional authentication for a higher assurance level, potentially valid for a specified period. Re-authentication-only uses prompt=login in a new OIDC authorization request to force authentication even when an existing session is present.
How do non-OIDC applications implement step-up authentication?
They can use Workforce Identity Cloud Factor APIs to find an enrolled factor, issue a challenge, and verify the response. A secure middleware or business layer must perform these privileged operations and protect the static Okta API token.
Source and freshness
- Source
- developer.okta.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.