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:
Is my interpretation of that wording correct? Can you pass in an “app context” that overrides the default redirect?
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.
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.
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.
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.
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., www.tigerstance.com, qa.tigerstance.com, staging.tigerstance.com, test-env-001.tigerstance.com) 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?
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.