<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Missing response_type parameter in Forgot Password flow with active MFA session]]></title><description><![CDATA[<p dir="auto">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.</p>
<p dir="auto"><strong>Scenario to reproduce:</strong></p>
<ol>
<li>Log into the application with a user that has MFA enabled</li>
<li>Wait for the Trust Token duration to expire</li>
<li>Trigger a Forgot Password flow from the login page using an Incognito window</li>
<li>Click the Reset Password link from the email in the same browser that has the active application session from step 1</li>
<li>The "Confirmation required" screen appears asking to continue to the MFA screen</li>
<li>Enter the MFA code</li>
<li>Error occurs in the callback: <code>The request is missing a required parameter: response_type</code></li>
</ol>
<p dir="auto"><strong>Workaround:</strong> Manually adding <code>response_type=code</code> to the reset password URL resolves the issue, but this shouldn't be necessary.</p>
<p dir="auto">The issue appears to have started after upgrading to 1.69.2. Templates are confirmed to be passing query parameters correctly, including in the <code>oauthHiddenFields</code> macro of helpers.ftl.</p>
<p dir="auto">Is this a known issue or bug in FusionAuth's password reset flow when combined with MFA and active sessions?</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3152/missing-response_type-parameter-in-forgot-password-flow-with-active-mfa-session</link><generator>RSS for Node</generator><lastBuildDate>Tue, 29 Sep 2026 01:30:37 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/3152.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 28 Sep 2026 06:24:10 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Missing response_type parameter in Forgot Password flow with active MFA session on Mon, 28 Sep 2026 17:00:58 GMT]]></title><description><![CDATA[<p dir="auto">This appears to be a bug in how FusionAuth handles the OAuth flow during password reset when an active session exists.</p>
<p dir="auto"><strong>Root cause:</strong></p>
<p dir="auto">When a user clicks the password reset link from their email, the link doesn't include <code>response_type=code</code> in the URL. Normally, FusionAuth adds this parameter automatically during the OAuth flow.</p>
<p dir="auto">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 <code>response_type=code</code> automatically, it attempts to reuse the existing session's OAuth state.</p>
<p dir="auto">This saved OAuth state is incomplete and missing the <code>response_type</code> parameter. When FusionAuth tries to redirect back to the application after MFA verification, it encounters an OAuth error because <code>response_type</code> was never included in the saved state.</p>
<p dir="auto"><strong>Temporary workaround:</strong></p>
<p dir="auto">Manually add <code>response_type=code</code> to the password reset URL until a proper fix is available. While this works, it's a band-aid solution.</p>
<p dir="auto"><strong>Status:</strong></p>
<p dir="auto">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.</p>
]]></description><link>https://fusionauth.io/community/forum/post/8643</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/8643</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Mon, 28 Sep 2026 17:00:58 GMT</pubDate></item></channel></rss>