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.

Having only one user be able to log in with username/password is relatively straightforward with FusionAuth. You could use a Login Validation Lambda or transactional user.login.success Webhook to check the authentication type on each login, which will tell you if they are logging in via a specific Identity Provider or with a password then stop users from logging in based on that criteria. Then set it up so that only the break glass user is able to login with a password.

The slightly trickier part here is only having the username/password field show up for that user. The only way to accomplish this with Simple Themes would be to have managed domains setup such that all normal users are directed to IdPs but the break glass user is on a separate domain so they get to see the login page. With managed domains, the login field changes just to email address for the first step. Then it will check the users email address against domains you have setup for specific IdPs and if they match a IdP then a user is directed straight to that IdP. Any user with a domain that does not match gets sent to the regular email/password login page.

https://fusionauth.io/docs/extend/code/lambdas/login-validation

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success

https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/#managed-domains

Your understanding is correct: in FusionAuth, a user account must have a password to exist, and the platform requires a password when creating a user. This means there’s currently no way to completely eliminate the password field from a registration form using Custom Registration Forms, nor is there a supported method to bypass the password requirement entirely.

However, there’s a workaround if you’d like to simulate a passwordless experience. Using the Advanced Theme Editor, you can hide and automatically populate the password field on the registration page via JavaScript. This way, users won’t see or interact with the password field, but FusionAuth still receives a valid (though randomly generated) password value behind the scenes. To users, the experience feels passwordless, even though a hidden dummy password exists for each account.

More details about customizing the registration page can be found here:
Advanced Theme Editor Documentation

Yes, exchanging a refresh token for a new access token (JWT) does count as a login event in the Login report.

Events That Count as a "Login":

A login is completed using any Login API (e.g., normal login, one-time login, passwordless login, Identity Provider login, or Connector-based login). A user is created with a password (whether through self-service registration or the Registration API). A refresh token is exchanged for a new JWT. A user successfully completes a 2FA login.

For more details, refer to:
What Makes a User Active?

Yes, you can manually construct a registration URL that includes PKCE values.

1. Understanding the Registration URL with PKCE

The /oauth2/register endpoint works similarly to the /oauth2/authorize endpoint but is used for user registration. Both support PKCE.
Example URLs:

Standard Authorization URL: https://your-fusionauth-instance/oauth2/authorize? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback Registration URL (Same Structure, Different Endpoint): https://your-fusionauth-instance/oauth2/register? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback

Since PKCE is enabled, you must append PKCE parameters:

code_challenge (derived from code_verifier) code_challenge_method=S256

2. Generating PKCE Parameters

Your application must generate a code_verifier and code_challenge before redirecting to FusionAuth’s registration page.

Node.js Example:

const crypto = require('crypto'); function base64URLEncode(str) { return str.toString("base64").replace(/\+/g, "-").replace(/\//g, "_").replace(/=/g, ""); } function sha256(buffer) { return crypto.createHash("sha256").update(buffer).digest(); } function generateVerifier() { return base64URLEncode(crypto.randomBytes(32)); } function generateChallenge(verifier) { return base64URLEncode(sha256(verifier)); } // Generate PKCE values const codeVerifier = generateVerifier(); const codeChallenge = generateChallenge(codeVerifier); console.log("Code Verifier:", codeVerifier); console.log("Code Challenge:", codeChallenge);

3. Constructing the Registration URL

Once you have the code challenge, construct the registration URL as follows:

https://your-fusionauth-instance/oauth2/register? client_id=yourClientId& response_type=code& redirect_uri=https://yourapp.com/oauth-callback& code_challenge=yourGeneratedCodeChallenge& code_challenge_method=S256

4. Completing the PKCE Flow After Registration

After the user completes registration, FusionAuth will redirect them to your app with an authorization code.
Your app must then exchange this code for an access token by sending the code_verifier to /oauth2/token.

For full details on the PKCE flow, see:

Using OAuth and PKCE with FusionAuth

Summary

There’s no auto-generated PKCE registration URL, but you can manually construct one. Generate the PKCE values before redirecting users to /oauth2/register. Complete the PKCE flow by exchanging the authorization code with the code_verifier.

Yes, exchanging a refresh token for a new access token (JWT) does count as a login event in the Login report.

Events That Count as a "Login":

A login is completed using any Login API (e.g., normal login, one-time login, passwordless login, Identity Provider login, or Connector-based login). A user is created with a password (whether through self-service registration or the Registration API). A refresh token is exchanged for a new JWT. A user successfully completes a 2FA login.

For more details, refer to:
What Makes a User Active?

Hi @vinicius-alfonso !

As documented here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo we don't provide the address info, even if you pass the address scope.

Per the OpenID spec, section 5.4, it appears that supporting the address scope is optional: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

If this is important to you, please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues with details about the use case.

We are guided by our customers and community when it comes to implementation of issues. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

Hi @chrissmueller328,

You will want to review our linking strategies. When this occurs, oftentimes, this is due to custom mapping needed (you can see this in our discord doc).

https://fusionauth.io/docs/v1/tech/identity-providers/#linking-strategy-examples

The event log is another great place to look to see how your user is or is not being linked/created.

You can also look at our doc for discord as an IDP

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/discord

Hope this helps!
Josh

@falk-jaeger
I figured out where to configure the 'Forgot Password Feature. You have to set a template to the 'Forgot Password' Field in the Email settings of the Tennant.

44545473-38b0-41a8-a6ab-e581c7bd04b2-image.png

@dan

I actually got the issue resolved, I had the PKCE configured as "Not Required". After I changed that to "Required" the flow worked as expected.

Thanks.

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

The only two grants that are relevant to an interactive flow are the authorization grant, and the implicit grant.

I don’t recommend you use the implicit grant at all, so that leaves only the authorization grant.

If the authorization grant is happening, response_type will be code.

If the authorization grant is occurring due to a device grant, the user_code variable will be set.

FusionAuth does not support mapping these URLs, you may be able to accomplish that through CloudFront or some other proxy configuration.

We'd recommend a redirect.

the difference between a JWT/access token and a refresh token is that a refresh token can be revoked. Every time you present it to the Identity Provider/OAuth server, the OAuth server can check to see if the user has been banned, signed out or otherwise invalidated that token. (You can revoke a JWT, but it's a pain, typically.)

A refresh token is an engineering tradeoff. Without refresh tokens, you would have two unappetizing alternatives:

an access token that lived for a long time. In this case, if the access token is stolen, the attacker has a lot of time to access systems (or you need to have some kind of access token revocation strategy, which degrades the value of stateless access tokens). requiring the user to sign in every time the token expires. That gets old if the lifetime of the access token is minutes or hours. I even get annoyed every time Google asks me to re-sign into gmail, which only happens every week or two.

The spec requires a client to explicitly request a refresh token. With FusionAuth you have to request the offline_access scope (which is common for other auth providers, but I wasn't able to find it in the RFC), so it's a way to offer more flexibility.

@dan said in Shopify integration:

Hmmm. That's a bummer that Shopify isn't being responsive. Here's what I have found:

Can Shopify Plus acts as an Identity Service provider (physically store the users without using 3r party ISP) and allow other applications (including ours) to authenticate via SAML?

Yes, documented here: https://help.shopify.com/en/manual/shopify-plus/security/saml

This looks like this only works with Shopify users who are in your organization. (Employee time tracking, not time recording.)

Can Shopify (Plus or Non-Plus) authenticate users using Shopify accounts.

I don't know. This https://shopify.dev/tutorials/authenticate-with-oauth sure looks like a OIDC flow, but I'm not sure how it works without setting it up. Have you tried to set up an OIDC identity provider? That's what I'd do.

Dan, You right
It`s works without setting it up, Thank You

@chirag have you seen these? https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

Reviewing them and mapping your use case on to them may be helpful.

There are two “worlds”, OAuth, and API only.

API world (JSON in body, proprietary to FusionAuth):

Application > Security > Login API Settings > Generate Refresh Tokens (Generate a a refresh token when using the Login API) Application > Security > Login API Settings > Enable JWT refresh (Allow a JWT to be refreshed using the /api/jwt/refresh API)

OAuth world (form params, in body and in request, standardized):

Application > OAuth > Generate Refresh Tokens (Generate a refresh token if offline_access scope was requested) Application > OAuth > Enabled Grants > Refresh Token (Allow a JWT to be refreshed using an refresh token) (edited)

If you are living in the OAuth world, then you can disable the API access, and just use the OAuth configuration. And vice versa.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.

Thanks!

This is possible. Doing so allows you to weave passwordless into the normal OAuth flow so you can use standard OAuth libraries but not have your user enter a password.

Start the passwordless login on the server side (using the API). Get the passwordless code. Send this url to the client: [FusionAuthURL]/oauth2/passwordless/[passwordlesscode]?redirect_uri=[redirect URI]&response_type=code&client_id=[client_id]. Have the client request this url. It'll be just as if the user had authenticated via the /oauth2/authorize endpoint and the user had entered their credentials. You'll get back an authorization code which can then be exchanged for an access token/JWT.