This article describes the behavior an end user can encounter when logging in to an OpenID Connect service via an external Identity Provider, where they must click a button on the Okta login page to be redirected to their Identity Provider.
- External Identity Provider (IdP)
- OpenID Connect (OIDC) application
- Okta Identity Engine (OIE)
In Okta Identity Engine, if an OpenID Connect app includes a login_hint in its /authorize request to Okta, and the user should be routed to an external Identity Provider based on a Routing Rule with a User matches condition, the user must click the Next button on the Okta-hosted login page to submit their pre-populated username before they can be automatically redirected to their Identity Provider.
There are different ways to make this log in experience more seamless, so users do not need to click the Next button on the Okta login page before being redirected to the Identity Provider.
- Instruct the OIDC application to directly redirect the user to a specific Identity Provider for authentication
- Modify the routing rules so that the user does not need to submit the form for the rules to be evaluated.
- Add custom code to the Okta Sign In page to simulate a click of the Next button automatically.
Include the IdP parameter in the /authorize request
When the OpenID Connect application forms the /authorize request, it can include an additional `idp` parameter, with its value set to the ID of the desired Identity Provider, so that users will be routed directly to that Identity Provider. A routing rule is not required or evaluated for this option.
Limitation: The application must know or have a way to determine the correct IdP ID for a given user. Either the application can keep track of the IdP for each user, it can make an API call to Okta (or another source) to determine the right Identity Provider for the user, or users coming from different IdPs can be provided different URLs to the app, which the application can then use to determine the appropriate IdP ID to include in the /authorize call.
Ensure the Routing Rule does not have a User matches condition
Instead of having a Routing Rule based on User matches conditions as in the screenshot above (which can only be evaluated after Username is submitted on the login page), have the Routing Rules route to a single specific IdP based on either the user's IP (based on Network Zones), their device platform, or the target application. Configuring the Routing Rule without this condition will ensure that, with or without a login_hint provided, Okta will immediately redirect the user to the target IdP, without them needing to click the Next button on the Okta login page.
Limitation: It might not be viable to configure Routing Rules this way in all orgs. This option is a better fit if all users of a specific application, on a specific network or device, will use the same IdP.
Customize widget code to automatically submit the form if a login_hint was provided
Limitation: The org must have, and the application must use, a custom domain in order to add this customization.
Example code:
function getLoginHint(){
if (!OktaUtil) return undefined;
var requestContext = OktaUtil.getRequestContext();
if (requestContext && requestContext.authentication && requestContext.authentication.request) {
return requestContext.authentication.request.login_hint;
}
}
var login_hint = getLoginHint()
oktaSignIn.on('afterRender', function (context) {
if (context.formName == 'identify'){
// if login_hint is included in authorize call, click Next button automatically
if (login_hint){
// click the button for the user
const next_button = document.querySelector('button[type="submit"]');
next_button.click()
// OR submit the form directly
//document.forms[0].submit();
}
}
});
