I'd like to update the user data object in the UI. I know I can do it via the API: https://fusionauth.io/docs/v1/tech/apis/users

https://fusionauth.io/blog/2021/04/01/fusionauth-introduces-simplepass/

I have a quick question about FusionAuth and configuring the inactivity timeout of the session cookie it creates. Specifically... Is it possible?

Can you run FusionAuth in Kubernetes?

Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

Within a lambda, you have access to the user and registration properties. So you'd pull the verified property from wherever you wanted and put it into the JWT as a custom claim. Here's a blog post about how that might work.

So yes, it is the same data. It's the tradeoff between a bigger JWT and having to make the additional call from your API.

Don't forget that the JWT will live for a while, so if this sequence happens and you use the JWT, you might have a user with a verified email prevented from using the API.

1. user registers
2. JWT issued, with verified set to false because the user isn't verified.
3. User verifies their email
4. User visits API, but is denied because the JWT has stale data.

I don't know timelines and how long your JWTs live for, but this is something to consider. Does that answer your question?

OK, we just released 1.18.8 and that is the version you want to use:

In requirements.txt:

fusionauth-client==1.18.8

And then this is the call you want to make (with client_id before redirect_uri) :

 resp = client.exchange_o_auth_code_for_access_token(request.args.get("code"), client_id, "http://localhost:5000/oauth-callback", client_secret)

Hiya,

First off, we'd recommend having all the flow you outline be over TLS. That's good enough for most major ecommerce systems and so shouldn't be insecure. If you aren't serving your application over TLS, then I'd advise doing so. And note that the flow is actually:

My Frontend --> My Backend --> FusionAuth API

There's no password returned from the registration API call.

If you are concerned about a new user's password being insecurely transmitted through your application, you could use the FusionAuth hosted login pages and theme them to be like your application. (More docs.)

The other option, which takes encrypted passwords, is the Import Users API, but that's probably not a fit for one off registrations. There are no plans to accept encrypted passwords for one off user registrations. Here's a related issue you can weigh in on/vote up if you'd like. Or feel free to open a new issue if that one doesn't capture the essence of your idea.

Are there specific security concerns you have around your front end/back end systems that I might be missing?

I haven't seen that before.

Does this happen in your customized version of FusionAuth (where you've added a few applications and users) or the default version?

From looking at the mysqldump man page, maybe try --hex-blob ?

You could try loading the schema from the .sql files ( https://fusionauth.io/direct-download/ ) and loading the data separately (that is, exporting with --no-create-info ). Again, that's a wild guess, not sure what the issue is, but some more investigation seems to make sense.

I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3'

services:
  mailcatcher:
    image: yappabe/mailcatcher
    ports:
      - "1025:1025"
      - "1080:1080"
    networks:
      - mailcatcher

  search:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1
    environment:
      cluster.name: fusionauth
      bootstrap.memory_lock: "true"
      discovery.type: single-node
      FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY}
      ES_JAVA_OPTS: ${ES_JAVA_OPTS}
    # Un-comment to access the search service directly
    # ports:
    #  - 9200:9200
    #  - 9300:9300
    networks:
      - search
    restart: unless-stopped
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - es_data:/usr/share/elasticsearch/data

  fusionauth:
    depends_on:
      - search
      - mailcatcher
    environment:
      SEARCH_SERVERS: http://search:9200
      SEARCH_TYPE: elasticsearch
    networks:
      - mailcatcher
      - search

networks:
  search:
    driver: bridge
  mailcatcher:
    driver: bridge

volumes:
  es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

Ah, the answer is that Nginx defaults to HTTP/1.0 and if you are on a recent version of FusionAuth, this protocol is not supported by our HTTP server (HTTP 1.1 was, after all, released in 1997 ).

The remedy is to update your Nginx configuration to use a later protocol with this change:

proxy_http_version 1.1;

Hope that helps.

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.

• Local development — letting an agent configure FusionAuth and recording the steps for later automation
• Production read-only — using an agent to safely query a production 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.

Prerequisites

• A running FusionAuth instance (local or remote)
• Node.js installed
• An MCP-compatible client (e.g., Claude Desktop)

Scenario 1: Local Development

This lets you configure FusionAuth and record steps to apply to other instances.

• Create a read-write API key. In your local FusionAuth instance, create an API key with the permissions you need. For full configuration work, you may want broad permissions, but always follow the principle of least privilege — for example, if you're only working with applications and themes, grant only those permissions.
• Configure your MCP client. For Claude Desktop on macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json to add the FusionAuth MCP server. Since you want full configuration access, omit the USE_TOOLS restriction (note: you'll need a model that can handle ~200k tokens):

{
  "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.

• Verify the connection. Open Claude Desktop and ask:

"Which tools do you have access to?"

You should see a list of all FusionAuth API tools (300+).

• Configure FusionAuth using natural language. Now you can describe what you want in plain English. For example:

"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.

• Export your configuration for automation. Once you've configured things the way you want, ask the agent to export the configuration so you can turn it into repeatable scripts:

"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%.

Scenario 2: Production Read-Only Queries with an Agent

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.

• Create a read-only API key. In your production FusionAuth instance, create an API key scoped to read-only operations only. This is the most important security step — the API key defines the ceiling of what the agent can do.
• Configure your MCP client with read-only tools. Edit your MCP client config to point at your production instance and restrict tools to retrieve and search only:

{
  "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.

• Verify read-only access. Ask the agent:

"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:

  • "Is PKCE enforced for all my applications?"
  • "How many users do I have in my FusionAuth instance?"
  • "How many FusionAuth applications do I have?"

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.

See the documentation for more details.

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.

• If you use the hosted login pages/authorization code grant, disabling all grants in the application settings page will prevent people from logging in.
• If you use the login API and have customer-based API keys, you could turn on the 'require API key for login API' and then disable the customer's API key.
• If you have the Enterprise plan, you could set up an IP ACL for a unroutable IP range.

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!

• Self-service password recovery — SMS or Email based forgot password flows out of the box, with hosted pages that require no custom UI. If a user's login ID is a phone number, the reset is delivered via SMS automatically.
• API-driven recovery — The full forgot password flow is triggerable via POST /api/user/forgot-password with an email, phone, or username as the login ID, giving teams complete control over the UI and recovery experience.
• Admin and support-assisted recovery — Support staff can trigger resets or force password changes directly from the admin UI, no email required.
• Admins can also remove MFA methods directly from the user record.
• MFA recovery — Recovery codes generated at MFA enrollment let users bypass a lost second factor.
• Self-service MFA configuration — Users can add, remove, and manage their own MFA methods (TOTP, SMS, email) from a hosted self-service account page without any admin involvement. Removing a method requires completing an MFA challenge first, which prevents unauthorized removal. If an admin removes a user's MFA method and the tenant or application policy is set to Required, the user will be prompted to set up MFA again on next login.
• Webhooks and event-driven recovery — FusionAuth fires events like user.login.failed and user.password.reset that your backend can listen to and act on, enabling custom recovery logic, audit trails, and downstream notifications.
• Account linking and IdP recovery — For users who log in via a social or enterprise IdP, FusionAuth can be configured to link that identity to a FusionAuth user record. If the IdP connection is the issue, the user can still go through the standard forgot password flow as long as an phone number or email is on their account, so recovery isn't solely dependent on the IdP being available.

What are account recovery options available with FusionAuth?

You want to use search parameters like those outlined in this sample script.

• use a key limited to POST on /api/user/search
• set accurateTotal on the request
• set numberOfResults to 1 on the request

In the response, look at the total field.

This will let you get exact numbers while reducing load on your instance.