Redirect to Login or Application After Activation

The fromURI query parameter does not work for me when using it like you recommend. My users just end up on the user home page instead of being redirected anywhere else. Did you have to do anything special to make it work for you?

You will also have to add the app’s url to trusted origins.
Go to security -> API -> Trusted Origin -> Add Origin enable redirect (and CORS if you need)

I will update the previous answer for completion.

@tom any updates on this feature in okta?


@tom, for those who have the appetite of creating their own UI for the flow, can you breakdown the calls that take place in the Welcome page? We have a use case where we want to replicate the Welcome flow in our UI and redirect to one of our pages at the end.

The email link has the activation token.
The next step I believe is to call Primary Authentication /api/v1/authn with the activation token.
That call will return a state token.
Documentation states that " the response will trigger the workflow to set the user’s password"
The documentation there does not have an example of using the state token to change the password.
What about the security question/answer? Does that need a separate call to change it, or can both security question/answer and password be changed in one call?

The Welcome page currently does it, so it’s just a matter of making the right calls and it’s not well documented.

I am posting a solution that was provided to us by Kam Ahuja, the Okta architect we work with. Many thanks to Kam.

  1. Create a bookmark app and point it to the page where you’d like users to land post activation (applications > add application and search for bookmark)
  2. Assign this app to “Everyone” group (or use group rules to ensure it gets assigned to any new users that you’d like to be redirected to this page after activation)
  3. Find the embed link for the bookmark (browse to the app config in Okta, under general tab, at the bottom you’ll find the embed link):
  4. Copy the /home/… portion of the url and encode it
    E.g. encode /home/bookmark/0oa8au0r9dzZUvgTf0h7/1280 >>>>> %2Fhome%2Fbookmark%2F0oa8au0r9dzZUvgTf0h7%2F1280
  5. Update the User Activation email template to include a new parameter called fromURI parameter that points to the encoded url above. E.g.
Activate Okta Account

Now if you inspect the activation URL in the activation email, you’ll notice the new fromURI parameter and when the user finishes the activation, they’ll be redirected to the url defined under the bookmark app.

1 Like

@ilako Thank you for the detailed steps. This worked exactly how you explained.

I also tried simply appending ?fromURI={my-uri-encoded-app-uri} and that also worked. So I don’t think the bookmark is absolutely necessary, at least not for my OIDC SPA Okta app.

1 Like

Hi, I’m new to oAuth world and I was able to take the okta-aspnet-mvc-example and apply your steps, but I noticed that once I activated the user, I was able to just login. So, how do I make sure the active user is not able to login without first confirming they received the email and clicking on the ‘Activate Account’ button?

Thanks in advance.


1 Like

Having a single activation/verification template across Okta doesn’t really make sense.
You should be able to configure multiple self service registration flows, and assign these to apps.

Its very possible a single customer has multiple apps that require different registration information and different re-directs

1 Like

Hi, all!

If anyone is interested into achieving this flow but for Redirect to Login after the Reset Password instead of Activation, this is possible.

It will not function work while having the flag for Self Service Registration, that is automatically enabled on most of the orgs. With that flag turned off, the actual approach of having href="${resetPasswordLink}?fromURI=" will actually function.

A needed step for this will also be to add the link to the Trusted Origins under Security > Trusted Origins and to have this function you will need to go to Admin Panel > Settings > Email > SMS & Email. On the Email tab you can modify the Forgot Password Email template and modify the bellow code as follows:


href="${resetPasswordLink}?fromURI=<Your link to be redirect to after password change"

After saving the new template, a user will be redirected to your specific link after changing their password.

About the flag that needs to be disabled: With Self Service Registration, you can configure an out of the box self service registration experience for your end users. A Registration Policy dictates what fields, password policy and email verification requirements you want to apply to your registration experience. Once enabled, a Registration UI is displayed in the Okta Sign-in Widget. Self Service Registration can be put in front of a custom application or portal, multiple apps, or even the Okta dashboard. If you don’t use this functionality and want to achieve the above flow, you can contact the Okta Support Team.

1 Like

Thanks for all the good tips in this topic… but unfortunately only Activation redirects works for my app when fromURI is specified… Password Reset even with fromURI still takes our users to OKTA’s app/userHome… Anybody seeing this? Thanks again!

This option is not seen for my application. It is and OIDC app. Is this option also seen for an OIDC app? I see it in WS-FEd and SAML apps only.

This works as expected on my okta test (r&d) instance. However the same does not work on our preview and production instance. I get a 404 on redirect.

  1. Is there any other setting that is to be done? Maybe not explicit but something which is there by default and I missed?

  2. Is the bookmark option present in your OIDC app? I do not even get that option.

Hi @swaroop.shekar

The embed URL appears if you have under General tab the option “Login initiated by” set to “Either Okta or App”.

If you enable the option above, do you still receive the 404?

Hi there,

I am posting this as of 6/15/2019, and I am about to implement one of these “workaround” solutions, but I just wanted to check with the developers whether the mentioned solution has been released?

I don’t want to go to the trouble of a custom workaround if this feature exists.

If not, I do have one question. In my Okta dashboard it says that editing the redirect email template will disable the automatic language translation. Would modifying the URI in the redirect disable the automatic translations too?


1 Like

Hi, I am attempting to implement the fromURI solution with the bookmark but am unable to make it work. The activation email I receive has the ‘fromURI’ query string appended but it does not redirect. I am still taken to the okta homepage and the ‘fromURI’ query string never gets consumed. I can still see it in the address bar. Any suggestions?


I’m seeing the same as @dcourts.

I’d like our activation to redirect to our own site.

What is the expected behaviour of this now? Is it documented anywhere?


Hi Rikki,

I was able to solve this problem after contacting okta support. There was a global setting that was overriding the fromURI in the query string. In the okta portal check for your Global Default Redirect Setting. This is located in Settings > Features. Make sure this is turned off.

1 Like

Thanks @dcourts! Super helpful.

I can’t see Settings > Features, I’ve only got Settings > Account. Is Features a paid-only page? I’m on an * authorization server while we evaluate whether we can do what we need with Okta. (I recognise you’re a fellow user, not a Okta rep, but you might know, eh? ;-))

Okta hides some things behind feature flags so you may need to open a support ticket and ask them to enable it for you.

We silo our customers by creating an okta app for each one and associate it with an instance of our webapp that’s running on a separate subdomain for each customer

The current okta email workflows don’t really work because we need to redirect the users to their company’s subdomain landing page. The above solutions dont work either as we need to send the user back to the app/url they came from

The hack we’re using until okta provide a better workflow is to hijack one of the available user level properties (secondary email) when provisioning the user and put the URL in there

we then strip out the app@ when creating the fromURI value so that it points to the custom subdomain

Maybe this’ll help someone else