For applications implementing Single Sign-On (SSO), Okta can support both SP-initiated (where the application/Service Provider makes a request to the Identity Provider, in this case, Okta) and IdP-initiated (where the Identity Provider makes a request to the application) for Single Sign-On.

For SAML applications, the Idp-initiated flow seamlessly allows users to log in to the target application without any interaction from the user (short of any additional authenticator requirements) beyond clicking on the application tiles from the Okta End-User Dashboard.

For OpenID Connect (OIDC) applications, the application developer must design their application to handle the IdP-initiated login. This article guides how to configure on the Okta side and on the application side to have a similarly frictionless experience.

• custom OpenID Connect application
• [optional] Auth JS SDK

While the OpenID Connect standard does not support Idp-initiated login in quite the same way, Okta does support Third Party Initiated Login, as described in the OIDC Spec.

When a user tries to launch the OpenID Connect application from the End-User Dashboard, Okta will initiate a redirect to the application via the Initiate Login URI configured for the application. See How to make the OIDC/OAuth App visible in Okta dashboard for more information on how to have the option to set this URI in the custom OpenID Connect application.

Although Okta supports initiating the Authorize request itself using the Okta Simplified Send ID Token directly to app option mentioned in the aforementioned article, only Implicit flow is supported. Authorization Code flow (with PKCE) is the recommended OAuth flow for most browser or Native applications, but to complete this three-legged flow, the application must be the one to initiate both the /authorize request and the /token request to Okta due to its security features. As such, if the application is using Authorization Code flow, please set the application within Okta to use the OIDC Compliant option to Redirect app to initiate login.

As per the OIDC spec referenced earlier, in this flow, Okta will redirect the user to the application via the provided Initiate Login URI and will include a `iss` query parameter in the request that will be equal to the Okta domain where this application resides. No /authorize request will be made by Okta, so once the user winds up on the application, please ensure that the application can make this request automatically. When using the OIDC Compliant option, it is not recommended to set this Initiate Login URI to the same route as the callback/sign-in redirect URI.

Okta Hosted Login

If the application is designed to redirect to Okta to log users in, the work might already be done.

As long as the Initiate Login URI is a route in the application that is designed to immediately check if the user is authorized (for example, if using one of our SDKs and set this URI to a Protected/Secure route within the application that requires auth), the application will make the /authorize request and, since the user has an active Okta session, they should be logged in automatically.

If not seeing this behavior, ensure that users log into Okta via the same Okta domain (either the default *.okta.com domain or a custom domain configured for the Okta tenant) as the application uses for its Issuer. Hint: the value for the `iss` query parameter sent to the app via the Initiate Login URI indicates the domain where the user has an active session.

Self-hosted/Embedded Login

If the application has a built-in login page, there are a couple of options. If the login page is already designed to check if a user already has an active Okta session, such as by checking /api/v1/sessions/me (caveat) or by checking if the user is authorized similar to the example above, where the application can make an /authorize request automatically, the work may already be done. Simply set the Initiate Login URI to the login route and test it out!

If the login page (built using the Widget, one of our SDKs, or our direct authentication APIs) does not already have this functionality, either add this automatic request directly to the login page (Displaying the Okta-hosted login page might occur, so consider this if the goal is to keep users within the application. Detecting an existing Okta session, as previously mentioned, could potentially prevent this.) or create/use a designated route in the application to initiate this request. From there, either designate this route as a Protected/Secure route (as described above), which requires that the user be authorized and is thus capable of initiating the /authorize requested or the application can simply initiate an /authorize request whenever a user hits this specific route. Ensure that the Initiate Login URI for the application in Okta is configured to match the implementation.

Auth JS

If using the Auth JS SDK, the simplest way to initiate this authorize request, without deliberately prompting the user for a password, would be to use the getWithRedirect() method to make the /authorize request to Okta once it has been determined that the user does not already have valid tokens using isAuthenticated()