Is it possible to set all users to have the passwordChangeRequired status set to true by default, so they are forced to reset their password upon their first login? Additionally, can we set a default password format as company{username}? For example, a user with the username 1234 would have the default password company1234.
Best posts made by wesley
-
How do you reset a user's password upon their first login?
-
How to Create a JWT Populate Lambda in FusionAuth
Our FusionAuth instance only lists 11 Lambdas by default, and JWT Populate is not one of them. How can we create a JWT Populate Lambda?
-
How to Manage Application Roles in FusionAuth Without a Bulk Import API
Does FusionAuth provide an API to import roles for an application?
-
How to Prevent Double Email Issues with FusionAuth's Forgot Password API
We are using the /api/user/forgot-password API for password resets, with sendForgotPasswordEmail set to false since we send our own email. However, users are now receiving two emails: our custom email and a password reset email from FusionAuth using our template. This issue occurs only in our pre-live and production environments, not in the local Dockerized version. What could be causing this?
Latest posts made by wesley
-
RE: Best Practices for Securing Partner APIs with FusionAuth
Yes—using FusionAuth access tokens to secure partner-facing APIs is a solid approach. The key is ensuring the tokens contain the right claims to enforce proper authorization for your endpoints.
Separating partners into a different tenant or application can improve security and simplify management. Different tenants fully isolate users and tokens, but would require duplicating application configs. Alternatively, you could keep partners in the same tenant and distinguish them via roles, claims, or separate applications.
If partners are accessing APIs server-to-server, the client credentials grant (Entities in FusionAuth) is the correct choice. Be sure to carefully scope each partner’s access to avoid over-permissioning.
More on these topics:
-
Best Practices for Securing Partner APIs with FusionAuth
We use FusionAuth for user authentication on our website and plan to expose certain API endpoints to external partners. Our idea is to have partners authenticate via FusionAuth and then use the access token (JWT) to call our secured APIs.
Is this the recommended way to secure partner APIs with FusionAuth? Should we separate partner users into a different tenant or application for better isolation? And if partners need server-to-server access, is the client credentials grant the right approach?
-
RE: How to Safely Add a New Custom Domain in FusionAuth
Yes—you can safely add a fourth custom URL. The “replace” label appears because the system expects you to submit the entire list of domains each time. To avoid losing any URLs, make sure all four domains—including your existing three—are entered in the form before you submit. Only custom domains omitted from the list will be removed.
More details here:
Updating Custom Domains -
How to Safely Add a New Custom Domain in FusionAuth
We have three custom URLs in production and want to add a fourth. The interface only shows a “replace” option, which worries us in a production environment. Can you confirm if we can safely add a fourth URL without affecting the existing ones?
-
RE: How to Report on Users with MFA Enabled in FusionAuth
Yes! FusionAuth stores MFA details on the user object, and you can search for users with MFA enabled using Elasticsearch queries.
For example, in the Admin UI’s User search, you can run:
_exists_:twoFactor
This returns all users with at least one MFA method configured. You can also perform similar searches via the User Search API to build custom reports. For more details on searchable user fields and Elasticsearch queries, see:
-
How to Report on Users with MFA Enabled in FusionAuth
We’d like to generate a custom report showing which imported user accounts have set up multi-factor authentication (MFA). Ideally, we want to see all users and their MFA status under the Multi-Factor tab. Is this possible?
-
RE: How to Support Elevated OAuth Scopes for Select Users in FusionAuth with Google Reauthentication
This is definitely an uncommon scenario, so there’s no out-of-the-box flow documented for it, but here’s one way to handle it:
- Create a second Google IdP: FusionAuth supports only one native Google IdP, but you can set up an additional Google connection as a generic OpenID Connect (OIDC) IdP. This second IdP can request the elevated scopes you need for email access. See the OIDC docs here: OpenID Connect IdP in FusionAuth.
- Trigger reauthentication: When a user opts into the email client feature, redirect them through the second IdP’s OAuth flow to acquire the elevated scopes. This effectively escalates their session without forcing all users through additional authentication unnecessarily.
This approach allows you to avoid reauthentication for users who don’t need the extra scopes while supporting a higher-privilege flow for users who do.
-
How to Support Elevated OAuth Scopes for Select Users in FusionAuth with Google Reauthentication
We want to provide two different login experiences:
- Users who opt to have us as an email client should re-login with Google to get elevated OAuth scopes (e.g. to read their email).
- Users who don’t opt for email services shouldn’t be forced to reauthenticate and should have a smooth login experience.
Ideally, we’d like to build our /oauth2/authorize URL with the additional scopes when needed, have users reauthenticate via Google, and have FusionAuth update the linked account with the new access token and elevated permissions. Is this possible?
-
RE: Why FusionAuth Webhooks Show ONE_TIME_PASSWORD Authentication Type for Logins
Great question—this often causes confusion.
In FusionAuth, logging in after a Forgot Password flow is tracked as ONE_TIME_PASSWORD. That’s because, technically, FusionAuth uses a one-time password during that process. For example, if you look at the Change a User’s Password API, it returns a one-time password token. On the hosted pages, FusionAuth automatically consumes this token to sign the user in immediately after they reset their password via the forgot password link in their email.
So even without traditional OTP or MFA configured, these login events can appear as ONE_TIME_PASSWORD due to password reset flows.
-
Why FusionAuth Webhooks Show ONE_TIME_PASSWORD Authentication Type for Logins
In the login events from webhooks, I’m seeing many logins where authenticationType is set to ONE_TIME_PASSWORD. Our current configuration doesn’t seem to explain this, and as far as I know, we’re not using any OTP or MFA. What does this refer to?