I’m using the management api to generate reset-password tickets (/api/v2/tickets/password-change). When I send these tickets to users, they should be able to click on the link, reset their password and be redirected to a specific application.
With the classic login experience, I can accomplish this with the result_url parameter. The new universal login experience does not respect this but instead relies on the login route defined for the application or tenant. I cannot define a default login route for the tenant because I have multiple applications. Defining a default login route for an application has no effect though because I ticket I generated via /api/v2/tickets/password-change has no connection the any application. This results in no redirect option whatsoever after the user changed his password, no a good experience.
Is there a way to achieve this with the new universal login experience?
Thanks,
Fabio
Hi @fnberta,
I think this thread covers the issue. Can you check and confirm that it does/does not?
Thanks,
Dan
Hi Dan,
Thanks for your response. Unfortunately this thread does not cover the issue. When I request a reset-ticket via the management API, there is no notion of an application. Hence setting a default login URI for any application has no effect on the link the API generates. The default login URI only works when a user enters the password reset flow by clicking on forgot password on the login screen (to which he was re-directed from a specific app). Somehow the token that is generated in this scenario does contain the information to what application it belongs.
Thanks,
Fabio
Hi @fnberta
You can try specifying the default tenant Configure Default Login Routes, this will work whenever there’s no Application context.
Let me know how that works.
Andres
Hi Andres
Thanks for the suggestion. The problem is that I can only specify one default for the tenant and we have several applications for which I would like to issue password reset tickets via the Management API. It seems like there is no way to do this currently with the new universal login experience?
OK, makes sense.
If we provided you a way to specify the client_id when creating the password reset ticket, would that work?
Thanks,
Andres