I was able to trigger a password reset email with the following
PUT call as per the documentation here:
with the payload of:
The user then receives an email with a link to perform said actions.
So far so good.
The issue is: once the user has completed updating their password on keycloak, and click go back to app, they have to log in again. Is there a way to auto login the user after setting their password via this workflow?
If using the standard forgot password workflow, the user is automatically logged in after changing their password. How is it possible to achieve the same behaviour where the user don’t have to log in right after they updated their password - when triggered from the execute-actions-email endpoint?
This seems to be a shortcoming of keycloak.
Upon further research it seems that when one triggers reset-password action via the above endpoint - after the user resets their password they are redirected to the login page.
Which is not intuitive and goes against expected user behaviour and is not even consistent with keycloak’s own reset-password flow triggered from the login page (forgot password link).
If anyone has come across the same challenge and have any advice how to get around it I would be eternally grateful and buy you a cup of coffee. Super annoying to send a user to the login page right after they reset their password. Please point me in the right direction on this. or where can I make a feature suggestion to the core team?
It is correct that this is the default behavior, and that it is not currently possible to override it with configuration.
However, in working on my own ActionToken handler, I did find out that the reason Keycloak does this is that an auth note gets stored in their execute actions handler that tells the session to be terminated after all required actions are executed.
Here’s my post on where it is in the code: Logging a user in directly from an ActionToken - #7 by xgp
Now, this is probably more work than you wanted to take on, but if you were to make your own ActionToken and handler, create a new resource method like
execute-actions-email that created your action token type, you could just override the
startFreshAuthenticationSession method in your handler and omit setting the auth note.
Thanks @xgp - that clarifies it and actually makes sense - I’ll dive into creating our own ActionToken handler in the new year and for now we’ll just work around that.
I owe you a cup of coffee