Redirect federated users to IdPs for re-authentication

Early Access release

When an app sign-in policy or Okta account management policy requires a user to re-authenticate, Okta prompts them to re-authenticate with local authenticators in your org.

However, federated users whose Okta sessions were established through a third-party identity provider (IdP) or Okta Org2Org IdP often don't have local Okta authenticators enrolled. This causes error messages and creates a disruptive user experience when your federated users need to re-authenticate.

To improve this experience for your federated users, you can configure your org to redirect them to the OIDC, SAML, or Org2Org IdP that last established their Okta session when they need to re-authenticate. After they authenticate with the IdP, they're returned to Okta with fresh authentication claims.

Before you begin

• You have at least one third-party IdP (OIDC or SAML) or Org2Org IdP configured and active in your org. See Identity Providers.
• You have re-authentication requirements configured in your app sign-in policy or Okta account management policy rules. Re-authentication frequency is set in the When to prompt for authentication section of the rule. See Add an app sign-in policy rule and Edit the Okta account management policy.

Configure re-authentication to IdP

1. In the Admin Console, go to SecurityIdentity Providers.

2. On the Identity Providers page, go to the Identity claims sourcing tab.
3. In the Re-authentication to IdP section, click Edit.
4. Set Re-authentication routing to Most recent active SSO IdP. Okta redirects the user to the third-party or Org2Org IdP that last established their Okta session.
5. Set Eligible IdPs for re-authentication to one of the following options:
   • All IdPs that meet the requirements: All active SSO only identity providers will redirect users to the most recent active IdPs for authentication.
   • Specific IdPs that meet the requirements: Choose which IdPs are eligible for this redirect. If the user's IdP isn't in the filter list (and the list isn't empty), the policy behaves as None.
6. Click Save.

Understand re-authentication outcomes

The re-authentication outcome for your users depends on the following factors:

• The Re-authentication routing setting on the Identity claims sourcing tab (see Configure re-authentication to IdP)
• Whether claims sharing is enabled in the IdP configuration (see Configure claims sharing)
• Whether password re-authentication and other factor re-authentication is currently required, as defined in the When to prompt for authentication section of your authentication policy rule (see Add an app sign-in policy rule and Edit the Okta account management policy)

The following outcomes apply whether re-authentication is triggered by a third-party app sign-in policy, an Okta account management policy, or an Org2Org app sign-on policy, except where noted.

The Password re-authentication required and Other factor re-authentication required columns only apply when a rule uses Password + Another factor assurance, which sets separate re-authentication frequencies for each factor. All other assurance levels (1FA, any 2FA, password/IdP) use a single re-authentication frequency.

Re-authentication routing	Claims sharing	Password re-authentication required	Other factor re-authentication required	Outcome
Most recent active SSO IdP	Enabled	Yes or No	Yes or No	Redirect to IdP at earliest frequency
Most recent active SSO IdP	Disabled	Yes	Yes or No	Redirect to IdP at password frequency
Most recent active SSO IdP	Disabled	No	Yes	Local factor prompt
None	Enabled or Disabled	No	Yes	Local factor prompt
None	Enabled or Disabled	Yes	Yes or No	Error for federated users

Error for federated users

Federated users see an error and can't re-authenticate. This occurs when Re-authentication routing is set to None and password re-authentication is required, regardless of whether claims sharing is enabled.

This prevents federated users from bypassing password frequency requirements.

Local users with federated login are prompted for their password locally instead of seeing an error.

Local factor prompt

Okta prompts the user for locally configured factors, and they are not sent to the IdP to re-authenticate. This outcome occurs in two situations:

• Re-authentication routing is set to None and only non-password factors are required
• Re-authentication routing is set to Most recent active SSO IdP, claims sharing is disabled, and the password frequency hasn't expired

Redirect to IdP at earliest frequency

Okta redirects the user to the IdP that last established their Okta session. Re-authentication occurs at the earliest expiring frequency across all required factors. For example, if password frequency is every two hours and factor frequency is every one hour, re-authentication occurs at one hour.

After re-authentication at the IdP, Okta may prompt for additional local factors based on the Authentication Method Reference (AMR) claims received from the IdP. If the IdP doesn't trigger re-authentication, Okta prompts for local factors every time.

This outcome requires claims sharing to be enabled on the IdP configuration.

Redirect to IdP at password frequency

Okta redirects the user to the IdP that last established their Okta session. Re-authentication occurs based on password frequency only. Okta prompts for all other factors locally.

This outcome applies when claims sharing is disabled (Honor password reauthentication frequency only is selected). Use this option only to maintain existing legacy re-authentication behavior for third-party IdPs with claims sharing disabled.

Okta prompts for other factors locally only if the factor frequency has also expired, rather than every time.