We have a custom user activation flow in our stack: our backend calls Okta to create the users via the API, and send the activation email with the same request. The users receives the email, is redirected to our frontend with the token, which is sent to our backend for validation (and to continue the reset password process). The issue is that often, the activation token sent via email is expired before the user can use it for the first time. It is quite frustrating, as its the first interaction with our app, and users often need us to send back an activation link for a second time so they can set their passwords.
The most plausible theory I have at the moment is that an update on the user’s profile invalidates already issued activation token. We create the user and send the link directly, but we trigger an event that updates one of the user’s fields asynchronously. Could that update invalidate the activation token somehow? This would also explain why the process is flaky, as sometimes the activation works directly, which would mean that our even updates the profile before the activation email.
We are experiencing this issue as well. I wouldn’t say often, but about 5 out of 50 users. Did you find a resolution? I’m not sure your theory would hold because then you would experience this issue every time, not just sometimes.
I haven’t found the resolution yet. I have an open case with Okta support, but they haven’t been able to reproduce the issue. As you said, they tested my theory and it wasn’t the case. However the issue could have been flaky because of the asynchronous nature of our activation process.
The issue is that the System Log isn’t really helping (it’s been a while since I tested, not sure if it doesn’t show up or if it doesn’t give enough information). I really wish there was a way to have some kind of developer-oriented logging that would give helpful information.
Thanks for the follow up. Yeah, we are unable to reproduce on-demand and logging isn’t really helping. I suspect it does have something to do the custom implementation using api calls that somehow get hung up on the outgoing or incoming end which breaks the string of processes that has to happen for it to work. I’m curious do know if this every happens using the OKTA widget instead of custom api calls.
Wow, we thought we were going crazy. Experiencing the exact same issue in the exact same scenario you described. We tried so many different approaches, forcefully regenerating activation tokens just before performing activation but the setup is flakey as hell and would constantly experience activation errors. We literally started reworking our entire flow so that account creation and activation happens on the backend as a single call instead, very frustrating!
One possible cause for the activation token being invalid before the user has even followed the link in their email could be that an email scanner (such as Outlooks’s Safe Links functionality) is “clicking” on the link. You may want to investigate to determine if such a scanner is in place on the affected user’s inboxes and, if applicable, see if there is an option in the email scanner to prevent this from occurring with links to *.okta.com (Safe Links seem to offer policies to do so, for example).
I’m a bit late reading this message, but we came to the same conclusion. In our logs, we log a message when we do the request in the frontend, as well as when we receive it in the back. We noticed that there was one log in the frontend, but two calls in the back. Something is calling our endpoint other than our frontend.
We’re changing the activation flow such that the activation request is actually made on the first password submit, this way any uncalled visit will not use up the activation token.
Thanks for the help and hope this will help others as well!