Providing an App Context in the Okta WIdget

Hey all,

Here is the problem I’m having:

We send email verification emails to user that sign up via self-service registration (Enable and configure a self-service registration policy | Okta). The issue we are seeing is that the “Default Redirect” is a per-org setting, not a per app setting. Thus, we can’t have a different “Default Redirect” per app. That I understand. However, the too-tip for the “Default Redirect” contains some interesting wording:

After registration, users will be redirected to the app that sent them to the registration form. In the event that no app context is provided, they will be redirected to the location selected here.

I bolded and italicized the wording I find interesting. If I am reading that correctly, it seems to imply that you can pass in an “app context” that contains the email verification link redirect.

My questions:

  1. Is my interpretation of that wording correct? Can you pass in an “app context” that overrides the default redirect?
  2. If #1 is correct, how do you pass in this “app context” from the OktaSignIn widget? I can’t seem to fined that information in the widget documentation (GitHub - okta/okta-signin-widget: Okta SignIn widget that renders the new login/auth/recovery flows). I am passing in the clientId of the application being used, but that doesn’t seem to be working and/or the wrong way to pass in the “app context”.

Thanks you!

This is actually a known issue that the Okta team is working to address. If you look at Okta ideas, you will see that some other customers have requested this feature.

Hi @erin.p,

Thank you for the response! So, if I understand you correctly, you can not pas in an “app context” to the widget to change the redirect? If so, I suggest that the Okta team remove/rephrase the " In the event that no app context is provided" in the “Default redirect” tool tip. That misleading wording sent me on a wild goose chase, costing me a non-trivial amount of time.

Thanks again!

The “Default App for Sign In Widget” is designed to redirect users to a specific application IF they are not in an SP-initiated flow (such as if the user is logging into Okta directly). That’s why there is a mention of there not being an application context as, in an SP-initiated flow, once the user has authenticated with Okta, they will be redirected back to the initiating application.

Thanks @andrea,

Our application uses OIDC, not SAML, so IIRC we’ll never be in a Service Provider initiated flow. Is there an OIDC equivalent of what you are referring to?


Redirecting to the /authorize url for OIDC is the equivalent.

In that flow, users are first sent to their IdP (Okta), logging in, and then being sent to the client that made the authorize request via the redirect_uri. OIDC does not support an equivalent to an IdP-initiated flow and all OIDC flows are considered akin to SP-initiated.

Hey @andrea,

Thanks for the response! However, I think we may have lost sight of the initial issue. We aren’t having an issue with customers logging into our web application via the Okta SPA widget. That is working fine.

The issue we are having is with self-registration (Enable and configure a self-service registration policy | Okta). When a user registers as a new customer via the Okta widget “Register” functionality, they receive a verification email. That email contains a verification link that, when clicked, can only redirect the to the dashboard or one predetermined URL that is set up via the Okta account admin page. We were hoping to be able to supply that redirect somehow, as we would like to use the same Okta account for different applications with different FQDNs (e.g.,,,, and have the verification email link redirect to the environment that the user registered with.

@erin.p said this is currently not possible, and that does seem to be the case given my testing. Do you have any additional insight into this self-registration email verification link redirect issue?

Thanks again!

1 Like

We have the same issues as the the topic.

Can’t find the feature request, would like to +1 it.


A workaround is attaching a fromURI query parameter to the end of the action links, this will redirect the user to the URI. In addition, a temporary workaround is to leverage the user’s locale to designate different templates fo apps, granted this is limited to number of locales supported.

User’s locale workaround: Okta Help Center (Lightning)

In addition, here’s a small write up I’ve done on this: Redirect to Application Post Account Operations (Unlock, Activation, Forgot Password) | CIAM Cookbook