o2q9u (o2q9u) asked a question.
Hello,
I have been running into a problem while trying to use the POST /api/v1/authn/recovery/password Okta API endpoint detailed on this documentation page:
https://developer.okta.com/docs/reference/api/authn/*recovery-operations
This endpoint is used to trigger an e-mail for performing a password reset flow.
The way I currently have it implemented:
1) the user submits a password reset request through my application
2) my application hits the password recovery Okta API endpoint above using a body object that looks like this:
{
factorType: 'EMAIL',
username: 'some.user@some.domain.com',
relayState: 'http://localhost:4700'
}
3) When I test the endpoint with this object using a debugging tool such as Postman, I can see the Okta API's response object confirms the relayState with a response that looks like this:
{
"status": "RECOVERY_CHALLENGE",
"factorResult": "WAITING",
"relayState": "http://localhost:4200",
"factorType": "EMAIL",
"recoveryType": "PASSWORD"
}
4) I have previously checked the Okta admin portal, under Security > API > Trusted Origins, to ensure that the 'http://localhost:4200' origin being used for the relayState parameter is marked for both Redirect and CORS.
5) The user receives the forgot password reset e-mail in their inbox
6) User clicks the link in the e-mail, bringing them to Okta. They fill out a security question and their new password in Okta
7) Once the new password is correctly set, instead of Okta redirecting the user to the desired URL specified by the relayState parameter, the user is instead redirected to <Okta server URL goes here>/user/notifications.
My question is: How can I make the relayState parameter work so that the user is directed to the relayState URL, instead of the <Okta server URL goes here>/user/notifications URL?
Thank you!
Just clarifying a typo in my question:
I accidentally did not use the same port number (4700 vs 4200) in all of the references for the custom redirect URL in my example, but you may assume the port number is correctly defined in all locations (and it matches the port number in the Trusted Origins configuration in the admin portal).
I'm still running into this problem, even without the typo. Sorry for the confusion.
Hi @o2q9u (o2q9u) , Thank you for reaching out to the Okta Community!
This seems to be a core limitation of the password reset flow.
Similar situations have been described here:
https://support.okta.com/help/s/question/0D50Z00008G7VYjSAN/redirect-to-external-app-after-password-reset?language=en_US
https://support.okta.com/help/s/question/0D51Y000091kpY4SAI/redirect-url-after-password-reset?language=en_US
https://support.okta.com/help/s/question/0D54z00007ZxhamCAB/redirect-urls-after-self-service-password-reset?language=en_US
See if any of the mentioned solutions help your use case.
Hope it helps!
Thank you very much for the information @Mihai Negoita - Okta (Okta, Inc.) , I will be sure to read through it and see if any of it can be leveraged for my use case. We are not presently allowing for self service registration in our system, so it seems that approach won't be viable for us. Maybe the 'fromUri' parameter in the password reset e-mail template might be something I can use.
Would you be able to tell me what is the purpose/use case of the 'relayState' parameter for the POST /api/v1/authn/recovery/password endpoint for my own understanding?
Thank you again!
Hi @o2q9u (o2q9u) ,
I've looked into this and if I understand it correctly, it should redirect the user to a different site after the password recovery.
I don't remember where I saw this being mentioned, but have you tried encoding your target URL when using it as relayState?
For example, something along the lines of :
http%3A%2F%2Flocalhost%3A4200
instead of
http://localhost:4200
Sorry if my answer did not inspire confidence. My advice would be to also reach out to the devforum.okta.com to take advantage of their expertise.
While we'll do our best to answer all of your questions, this medium is more inclined towards Okta core products.
Hope it helps!
Thanks a lot @Mihai Negoita - Okta (Okta, Inc.) ! Yes, I had actually tried using an encoded URI, though I did not seem to have better luck with using it. I will try out devforum.okta.com as you suggest; I did not even realize I was not in the proper place to bring this inquiry. My apologies, and thank you for pointing it out.