Open LucasPMorris opened 5 months ago
@LucasPMorris can you provide some additional context here and a use case that we are missing?
For example, the Authorization Code Grant and the Implicit Grant are browser based workflows. If someone were to use these browser workflows but not be in a browser then it would be expected that not everything will work as expected and this would be the intended design.
If someone were to use these browser workflows but not be in a browser then it would be expected that not everything will work as expected and this would be the intended design.
Exactly! So now it is:
Change Password->Authenticate User
The Authenticate User step above is forced, it isn't someone "choosing" to use a browser based workflow. So of course it doesn't work as expected leading to the ask for an alternative:
Change Password->Dead end or send user to a destination the developer wants (without an automatic login).
That way the end user doesn't HAVE to use the browser based workflows for authentication after a password reset (but are using an email/browser based password reset). In most cases, automatically logging a user in after a password reset is fine, but not something everyone wants.
Password Reset Workflow after Reset
Problem FusionAuth hosted pages automatically log a user in after a forgot password workflow. For apps which do not run in a browser the OAuth2 authentication workflow and redirect yield unexpected results.
Solution Provide alternative behaviours that can occur after a forgot password workflow. Such as:
Internal Ticket Numbers: 73983, 74034