Identity Provider Discovery Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Identity Provider Discovery
Published: May 8, 2018   -   Updated: Jun 22, 2018




Identity Provider Discovery

This is an Early Access feature. To enable it, please contact Okta Support.

When configured, Identity Provider Discovery redirects users to different identity providers based on specified criteria. These criteria include location, device, the app or app instance being accessed, the user's domain, and specific user attributes. For organizations that have more than one Okta org, the separate orgs can use separate identity providers and keep groups of users separate.

End-user experience

When Identity Provider Discovery is configured to select a provider based on the end user's domain or attributes, the end-user sees a modified sign-in screen that only accepts the email, as shown below.


The sign in is evaluated against the set criteria and the user is redirected to the appropriate sign-in screen for the desired identity provider.


Identity Provider Discovery is useful in the following scenarios

  • On-network vs. off-network – you can maintain alternate or legacy authentication for off-network users and use Okta for on-network users
  • Mobile users – Mobile users, identified by device, can route authentication to a third-party identity provider with specific functionality.
  • Hub-and-spoke organizations – organizations that manage users, Active Directories, policies, apps, workflow management etc. in one of the "spoke" organizations, but require access to the central organization for certain apps, such as Workday, or other reasons. Using Identity Provider Discovery, uses can authenticate from an app using a SP-initiated flow to the "hub" organization which uses Identity Provider Discovery to authenticate into the "spoke" organization seamlessly.
  • Desktop SSO – You can route desktop users to Integrated Windows Authentication (IWA) and mobile users to Okta for authentication.
  • Multiple customer organizations – you can send users across multiple orgs to a different org for authentication, based on the email subdomain.
  • Required discovery by user attribute – in some B2B scenarios where the email domain does not necessarily correlate to the identity provider, you can direct authentication based on user attributes


Before using this feature, you must have an additional identity provider configured. For information on configuring an additional SAML identity provider, see Configure Inbound SAML. Identity Provider Discovery does not support Social Identity Providers.


To configure Identity Provider Discovery, navigate to Security > Identity Providers, and then, click the Routing Rules heading. The default rule is shown that specifies Okta as the default identity provider. To add an additional provider, click the Add Routing Rule button. The screen shown below opens.


You must name the rule. In addition to the name there are four types of routing specifications. Note that all specified conditions must be met to trigger the rule. After defining the conditions, you specify the identity provider to use.

  • User's IP Address – choices are Anywhere, In zone, and Not in zone. To specify a zone here, at least one network zone must already be defined. For information on zones, see IP Zones.
  • User's Device Platform – choices are Any device, any of these mobile devices: iOS, Android, Other mobile (e.g. BlackBerry), and any these desktop devices: Windows, macOS, Other desktop (e.g. Linux). You can select any desired combination of devices.
  • User is accessing – choices are Any application or to specify applications. To add an application or app instance, start typing the application name. A list of all matching apps appears from which you can choose. You can specify multiple applications.
  • User matches – choices are Anything, Regex on login, Domain list on login, and User attribute.

    Anything specifies any user. This is the default.

    Regex on login allows you to enter any valid regular expression based on the user login to use for matching. This is useful when specifying the domain or a user attribute is not sufficient for matching.

    For example, if an organization has the domains,,,, etc. and you want to match all users with a login that ends with, such as and In this case, you can use the regular expression test\.example\.com$. The $ is the regular expression operator for "ends with." Note that the periods in the URL are escaped.

    Domain list on login specifies a list of the domains to match; for example, Do not add the @ sign to the domain name. You can add multiple domains. Note that it is not necessary to escape any characters which is required when using a regular expression.

    User attribute specifies an attribute name, a type of comparison, and a value to match. After selecting User attribute, the item shown below appears.


    Choose an attribute from the list and choose the type of comparison to use from the second list. The expanded drop down lists are similar to the following example, varying by the user attributes in your org.


    After choosing from the drop down lists, enter the value to use for comparison. If you choose Regex for the type of comparison, enter a valid regular expression for the value.

  • Use this identity provider – choose the identity provider from the drop down list to use when all the criteria are met.

When done, click Create Rule. After creating a rule, the following prompt applies to activate the rule.

  • If you activate the rule, it is immediately in effect.
  • If you do not activate the rule, it is listed on the Routing Rules screen as inactive.


Maintaining Routing Rules

The Routing Rules screen shows all rules, active and active.



To activate, edit, deactivate, or delete a rule, click the rule name, and then click an action button on the right. You cannot modify the default rule.