This article provides details on how Okta will let users access their cloud apps without signing in to Okta first. This is called a service provider-initiated flow or SP-initiated.

• Enrollment policy
• Sign-in to Cloud Applications
• Okta Classic Engine
• Okta Identity Engine (OIE)

Many users access cloud apps by logging in to their Okta Dashboard and clicking an app tile. However, Okta also allows direct access to cloud apps without the initial Okta sign-in. This type of access is known as a service provider-initiated flow or SP-initiated flow. The technical process behind this flow varies depending on the specific Okta edition in use.
 

Consider an example where an Identity Engine user finds themselves on the sign-in page of a cloud app with no active Okta session. Upon signing in to the cloud app, a pop-up from Okta appears, offering assistance with completing the sign-in process. Upon clicking the button, Okta loads the cloud app without signing the user into the Okta Dashboard. Identity Engine's function is to load the cloud app directly.
 

Now, in the same scenario but for Classic Engine users, the Classic Engine attempts first to sign the user into the Okta Dashboard and then proceeds to load the cloud app.
 

Both editions of Okta assess the relevant policies: Okta sign-on policy (Classic Engine) or Global Session Policy (Identity Engine); application sign-on policy (Classic Engine) or authentication policy (Identity Engine); and MFA enrollment policy (Classic Engine) or authenticator enrollment policy (Identity Engine). This prompts the question: Why does Classic Engine prioritize signing into the Okta Dashboard, even when the user intends to directly access a cloud app?
 

In Classic Engine, if only the Okta option is in the MFA enrollment policy rule, Classic Engine's response will include an initial attempt to sign the user into the Okta Dashboard, followed by signing in to the cloud app. This behavior holds true even for an SP-initiated flow:

This is not the intended outcome; if a user wants to sign directly into a cloud app, Okta should bypass the Okta Dashboard.

In Identity Engine, this issue has been fixed, and the SP-initiated flow works as intended; Identity Engine bypasses the Okta Dashboard and just loads the cloud app.

How does an admin get their Classic Engine org to stop trying to sign the user into the Okta Dashboard and just bring the user to the cloud app?
 

When adding a rule to a multifactor enrollment policy, select the Okta and Applications checkboxes, and then select either Any application that supports MFA enrollment or Specific applications options:

This will help reduce the time it takes for users to load their cloud apps and prevent the infrastructure from performing unnecessary sign-in attempts to the Okta Dashboard.
 

If help is needed setting this up, contact Okta Support.