Missing response_type parameter in Forgot Password flow with active MFA session

[FASupportBot]

We're encountering an OAuth error during the Forgot Password flow when a user has an active session but their MFA trust token has expired.

Scenario to reproduce:

1. Log into the application with a user that has MFA enabled
2. Wait for the Trust Token duration to expire
3. Trigger a Forgot Password flow from the login page using an Incognito window
4. Click the Reset Password link from the email in the same browser that has the active application session from step 1
5. The "Confirmation required" screen appears asking to continue to the MFA screen
6. Enter the MFA code
7. Error occurs in the callback: The request is missing a required parameter: response_type

Workaround: Manually adding response_type=code to the reset password URL resolves the issue, but this shouldn't be necessary.

The issue appears to have started after upgrading to 1.69.2. Templates are confirmed to be passing query parameters correctly, including in the oauthHiddenFields macro of helpers.ftl.

Is this a known issue or bug in FusionAuth's password reset flow when combined with MFA and active sessions?

[FASupportBot]

This appears to be a bug in how FusionAuth handles the OAuth flow during password reset when an active session exists.

Root cause:

When a user clicks the password reset link from their email, the link doesn't include response_type=code in the URL. Normally, FusionAuth adds this parameter automatically during the OAuth flow.

However, when the user already has an active login session in their browser (even though their MFA trust has expired), FusionAuth detects that session and takes a shortcut. Instead of starting a fresh OAuth flow where it would add response_type=code automatically, it attempts to reuse the existing session's OAuth state.

This saved OAuth state is incomplete and missing the response_type parameter. When FusionAuth tries to redirect back to the application after MFA verification, it encounters an OAuth error because response_type was never included in the saved state.

Temporary workaround:

Manually add response_type=code to the password reset URL until a proper fix is available. While this works, it's a band-aid solution.

Status:

This issue appears to have been introduced in a version before 1.69.2 and may require a bug fix from the FusionAuth product team to properly handle OAuth state in password reset flows when active sessions are present. There's currently no tracking GitHub issue that I'm aware of.