Hi Rich,

Thank you for reaching out to Okta support today.

Can you please review the documentation we have in place for reset password: https://support.okta.com/help/s/article/End-User-FAQ

If you have further questions, please open a Support ticket with us.

Have a great day.

After going back and forth with support for a few days we determined that there is built-in way to customize the destination of the Reset Password button. Instead I had to put some custom javascript in the Okta log in page (from the Okta dashboard: Settings | Customization | Custom Sign In - then edit the HTML). I changed the success function provided in the original in-line Javascript on line 29 from just passing in the OktaUtil.completeLogin function to a new function that receives response as a parameter, calls OktaUtil.completeLogin passing response, and then, if the widget is currently in Reset Password mode and response.status is 'SUCCESS', it sets the window location href to the URL of our app that we need to redirect to.

Note that I tried to post my code here, but the page wouldn't allow it. It said I had some illegal html in my post.

Upside:

The okta sign in page now redirects to our app after resetting the password.

Downside:

The sign in page does not have time to start a user session after resetting the password. If I used a timeout or something the page would redirect to the okta dashboard again, so I couldn't wait for the session to start. Therefore, after redirecting to our app the user is sent to the sign in page again where they have to enter their username and - now for the third time - their password.

Another downside is that I could not find a documented way to determine what mode the sign in widget is in. There were several ways to tell based on the DOM, but in the end I just went with using the current path in window.location.href. None of these methods are documented though, so in theory any of them could break at any time.

Hopefully this solution helps someone. If you need this feature too, go to the feature request page and upvote:

https://support.okta.com/help/s/idea/0870Z000000JxZ5QAK/detail

Hi Rich, any chance you could send me your code snippet you mentioned above as I have the same scenario for our application. I can send you my email or other contact info for whatever works.

Cheers,

Simon

If I remember correctly we found that the okta account type made the difference here. The code that I refer to above was just not a satisfactory solution. It turned out that our okta account for our production environment had the ability to set a default application other than the okta dashboard, but as I was working in our lab account which was a less capable account type, I could not see that. In the end we took out and threw away the code that I refered to above. Our lab account still redirects to the okta dashboard, but in our production account I was able to configure it to redirect to our app. I don't know what the difference between the account types is because I was not the person at our company that set the accounts up originally.

Simon -- appreciate your quick response. I'm assuming that the password reset in your use case is being done in a non-Okta domain that you control and the password is being written back to Okta via API?

Or did you use the inline HTML editor to write custom code as described by OP