Okta Step Up Authentication Integration Guide

Last updated: January 29, 2026

Step Up Authentication enhances your approval workflows' security by requiring additional authentication for sensitive approvals. Rather than relying solely on a user's initial session, this feature forces a stronger authentication challenge at the time of approval, creating a clear security boundary and audit trail for critical actions.

Recommended Use Cases

Consider implementing Step Up Authentication for these approval scenarios:

  • Administrative access approvals (system admin, database admin)

  • Production environment access

  • Customer data access

  • Financial systems access

  • Critical infrastructure changes

  • Privileged role assignments

Known Limitations (early access feature)

  • Slack: Approval via Step Up is not supported at this time

  • cone CLI: Approval via Step Up is not supported at this time

  • Access Reviews: Approval via Step Up can work, but the UX is not yet optimized for this case

Creating an Okta Application

  1. Log in to your Okta Admin Dashboard

  2. Navigate to Applications → Applications

  3. Click Create App Integration

  4. Select OIDC - OpenID Connect and Web Application

  5. Click Next

  6. Configure the application:

  7. Click Save

  8. Note the Client ID and Client Secret for use in ConductorOne

Configuring Okta Authentication Policies

For granular control:

  1. Navigate to Security → Authentication Policies

  2. Create a policy specifically for ConductorOne Step Up Authentication

  3. Define rules that require stronger authentication methods (e.g., MFA)

  4. Assign the policy to your ConductorOne Step Up application

Adding Okta as a Step Up Provider

  1. In ConductorOne, navigate to Integrations → Step Up Providers

  2. Click Add Step Up Provider

  3. Select OAuth2 (RFC 9470 compliant)

  4. Enter the following details:

    • Provider Name: Okta Step Up

    • Issuer URL: Your Okta domain (e.g., https://your-company.okta.com)

    • Client ID: The Client ID from your Okta application

    • Client Secret: The Client Secret from your Okta application

    • ACR Values: Select appropriate values based on your security requirements

Okta ACR Values Reference

ACR Value

Description

Security Level

Typical Use Case

urn:okta:loa:1fa:any

Any single-factor authentication

Low

Non-sensitive approvals

urn:okta:loa:1fa:pwd

Password authentication

Low

Password reverification

urn:okta:loa:2fa:any

Any multi-factor authentication

Medium

Sensitive resource approvals

urn:okta:loa:2fa:any:ifpossible

MFA if possible

Medium

Balanced security/usability

phr

Phishing-resistant authentication

High

High-value resource approvals

phrh

Phishing-resistant hardware

Very High

Critical system access

ACR Value Selection Guidance

  • For general approvals with moderate sensitivity: urn:okta:loa:2fa:any

  • For highly sensitive approvals (admin rights): phr or phrh

  • For testing or gradual rollout: urn:okta:loa:2fa:any:ifpossible

End-User Experience

When a task requires Step Up Authentication for approval:

  1. The task will be marked with a distinct "Requires Step Up Authentication" indicator

  2. Instead of a standard "Approve" button, users will see "Approve with Step Up"

  3. Clicking this button redirects the user to the configured identity provider

  4. The user completes the required authentication steps

  5. Upon successful authentication, the user is returned to ConductorOne

  6. The approval is processed and an audit trail is created

Example approval flow with Okta:

User clicks "Approve with Step Up" 

  ↓

Redirect to Okta

  ↓

Okta checks authentication context

  ↓

Okta prompts for additional factors based on ACR value

  ↓

User completes authentication challenge

  ↓

Redirect back to ConductorOne

  ↓

Approval processed with verification details

  ↓

Success message displayed to user

Frequently Asked Questions

Q: How does Step Up Authentication affect automated approvals?
A: When Step Up Authentication is enabled for an approval step, automated approvals are automatically disabled since there's no user to perform the additional authentication.

Q: What happens if a user doesn't have MFA enabled in the identity provider?
A: The behavior depends on the ACR values and provider policies. For example in Okta, if the ACR value is urn:okta:loa:2fa:any:ifpossible, the system will use MFA if available, but proceed without it if not. With strict MFA requirements, users without MFA would be unable to complete the approval.

Q: Can different policies use different Step Up providers?
A: Yes, each approval step can be configured with a different Step Up provider, allowing you to require different authentication strengths for different types of approvals.

Q: How does this work with SSO?
A: Step Up Authentication works outside of the SSO flow. Users will still initially authenticate via SSO, but will be prompted for additional verification when performing sensitive approvals based on the configured policy.

Q: What happens during identity provider outages?
A: If the identity provider is unavailable, users won't be able to complete the Step Up Authentication flow.

Q: Does this feature support mobile applications or just web browsers?
A: The feature is designed to work on both web browsers and mobile devices, using standard OAuth 2.0 redirect flows.

Additional Resources