Hi folks,
We recently enabled Intelligent MFA for the forum application.
If you don't have MFA set up, you'll be prompted to enable it.
Then, going forward, you'll be prompted for MFA if and only if the authentication is determined to be high risk.
Please contact us if you have feedback.
Here are two scenarios for using the FusionAuth API MCP Server, which is an MCP server that connects over STDIO and can be used to configure a FusionAuth instance.
Preview Warning: The FusionAuth MCP server is a preview release and may break, change, or be discontinued. It is intended for development and test instances. Never give an MCP client unrestricted access to a production instance.
This lets you configure FusionAuth and record steps to apply to other instances.
{
"mcpServers": {
"fusionauth-mcp-api": {
"command": "npx",
"args": [
"@fusionauth/mcp-api"
],
"env": {
"API_KEY_APIKEYAUTH": "<your-read-write-api-key>",
"API_BASE_URL": "http://localhost:9011"
}
}
}
}
Restart Claude Desktop after saving.
"Which tools do you have access to?"
You should see a list of all FusionAuth API tools (300+).
"Set up a custom registration form for the Pied Piper application. Require email address and password, but allow first name and favorite color to be optional. Put them all on one page."
Or:
"Add a user with an email address of test@example.com and a password of password."
The agent will make the appropriate API calls on your behalf.
"Please export the configuration for the Pied Piper application to a kickstart file."
"Export the current tenant configuration as a Terraform file."
This gives you a reproducible artifact you can commit to source control or use in CI/CD pipelines.
You can reduce tool scope. If you only need to work with specific operations (e.g., no deletes), you can reduce the tool list to improve performance and limit risk:
"env": {
"API_KEY_APIKEYAUTH": "<your-api-key>",
"API_BASE_URL": "http://localhost:9011",
"USE_TOOLS": "create,update,retrieve,search,other"
}
This omits the delete APIs and reduces the tool list by ~20%.
The security model of this approach consists of three layers: the instance you connect to, the tool categories you expose, and the permissions on the API key itself. Combining a read-only API key with USE_TOOLS="retrieve,search" gives you defense in depth for production queries.
{
"mcpServers": {
"fusionauth-mcp-api-prod": {
"command": "npx",
"args": [
"@fusionauth/mcp-api"
],
"env": {
"API_KEY_APIKEYAUTH": "<your-read-only-api-key>",
"API_BASE_URL": "https://your-production-fusionauth-instance.com",
"USE_TOOLS": "retrieve,search"
}
}
}
}
Setting USE_TOOLS="retrieve,search" reduces the tool list by 66% and ensures the agent cannot create, update, patch, or delete anything. This is a second layer of defense.
"Which tools do you have access to?"
Confirm that only retrieve and search tools are listed — no create, update, delete, or patch tools should appear.
Query production data. You can now safely ask questions like:
The agent will use the read-only API tools to answer your questions without modifying anything.
how would I use the FusionAuth MCP server to allow an agent to interact with FusionAuth?
Note that as of release 1.68.0 (released in late Jun 2026), there is a mfa_deleter role that can remove MFA from a user.
Please see the release notes for more details.
Since we can’t store API keys in code,
FYI, with the release of 1.64.0, you now can store secrets elsewhere and have lambdas retrieve them.
As of 1.62.0, FusionAuth supports pre-verification of emails and phone numbers.
More details:
https://fusionauth.io/docs/lifecycle/manage-users/verification/identity-pre-verification-using-email
https://fusionauth.io/docs/lifecycle/manage-users/verification/identity-pre-verification-using-phone
You have a couple of options.
However, the easiest way to make sure an application cannot be logged into is to deactivate the application.
Is there a way to disable logging into an application without disabling/deleting it?
Per https://github.com/FusionAuth/fusionauth-issues/issues/1810 I'm not clear what my options are.
Lots of options!
What are account recovery options available with FusionAuth?
You want to use search parameters like those outlined in this sample script.
POST on /api/user/searchaccurateTotal on the requestnumberOfResults to 1 on the requestIn the response, look at the total field.
This will let you get exact numbers while reducing load on your instance.
How can I get an exact number of users with some attributes? I'm using elasticsearch.
Beginning in version 1.65.0, FusionAuth offers Complete Registration. Full docs here.
How this would work:
required. If you are using a basic form, you could select 'birth date'. If you are using an advanced form, you can select whatever profile attributes you needRegistration mode to Complete registration. This setting means that users cannot self-register, but can complete missing information from an existing registration.Now, your admin user can create a user with a minimal amount of data (perhaps just an email address).
The user will, at first login, be prompted to fill out their profile data, including all fields you've marked required.
This is not full progressive registration, but can be useful in certain circumstances.
How can I collect additional profile attributes at login after a user has been created and registered?
I'm using the hosted login pages. My admin user creates an account, but I want to collect other profile attributes from the user afterwards.
@kevin-doran This is a great question to ask FusionAuth support.
Have you opened a ticket?
Thank you for letting us know.
This is an open issue. To see when this is resolved, you can follow along with the github issue here: https://github.com/FusionAuth/fusionauth-issues/issues/3439
The cleanest way to do it is with asymmetric JWT verification plus a bounded offline grace period.** Here's the pattern.
FusionAuth signs JWTs with a private key it holds. The matching public key is published at the JWKS endpoint (/.well-known/jwks.json). Your mobile app — or any resource server — can verify a token's signature locally, with zero network calls, as long as it has that public key. You can even bundle the public key with the application and avoid the retrieving it.
That's the property that makes offline auth possible. You're not asking "is this token still good?" over the wire; you're asking "did FusionAuth sign this, and has it expired?" using math the device can do on its own.
See JWT signing configuration and the JWKS endpoint docs.
The Flow
1. First login (online, required). The user authenticates against FusionAuth via OAuth with the offline_access scope, or via the Login API with loginId + password + applicationId. You get back two things:
Refresh token details are in the refresh token settings docs.
2. Cache the JWKS on the device. Fetch /.well-known/jwks.json once and store it. You'll match incoming tokens to the right key using the kid in the JWT header. For fully air-gapped scenarios, you can bundle the JWKS into the app at build time — see the air-gapping article.
3. Online operation. The app uses the access token for API calls. When it expires, the app calls the Refresh a JWT API with the refresh token to mint a new access token.
4. Offline operation. The app validates the cached access token locally:
kid matches the JWT headerexp, iss, aud, and any custom claims you care aboutIf the token is past exp but the device is offline, allow a bounded grace period (e.g., 24 hours past expiration). After that, degrade functionality until the device reconnects and refreshes. For instance, you could allow read operations but nothing that changes data.
5. On reconnect. Refresh immediately. If the refresh token has been revoked server-side, the call will fail and the user must re-authenticate.
Token lifetime tuning
This is where you make your security/availability tradeoff explicit. FusionAuth lets you tune both lifetimes per tenant or per application:
ttl_seconds
set this short for online use (5–15 minutes is typical), but if you want longer offline windows without the grace-period workaround, you can extend it. Whatever you pick is the maximum revocation lag for compromised tokens.What FusionAuth gives you for revocation
Refresh tokens can be revoked automatically on password change, MFA enrollment, or any action that prevents login. You can also call the Revoke Refresh Tokens API directly. The catch: revocation only takes effect the next time the device tries to refresh. Already-issued access tokens remain valid until their exp.
Tradeoffs you're signing up for
Be honest with yourself about this approach. These aren't FusionAuth limitations, they're inherent to offline auth:
exp checks rely on the device clock, which the user controls. If that matters for your threat model, store a "last known server time" on each refresh and refuse to validate tokens if the clock has moved backward.Practical starting point
Here's an example of the configuration:
expTighten the numbers for higher-sensitivity apps, loosen them for field-work apps where availability matters more than instant revocation.
Some further reading for you:
The short version: FusionAuth gives you all the primitives:
The offline policy is yours to design, and the design is mostly about choosing how much revocation lag you can tolerate in exchange for how much offline runway your users need.
I'm building a mobile app that needs to work in places with spotty or no connectivity (think field workers, transit, rural areas).
Can I use FusionAuth as my central identity provider while still letting users authenticate when the device is offline?
Yes, there's currently no support for using a certificate.
Here's an open tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/3083
Please comment and/or upvote this with any other details that would help the product team prioritize this.
Thanks for taking the time to chat with me.
I'm sharing the feedback internally, but for future folks there were multiple issues.
@elliotdickison please keep me honest and let me know if I missed something.