FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login
    1. Home
    2. dan
    3. Posts
    • Profile
    • Following 0
    • Followers 9
    • Topics 684
    • Posts 2,733
    • Best 171
    • Controversial 0
    • Groups 4

    Posts made by dan

    • RE: What are the use cases for the user.data.email field?

      It is useful in a few scenarios.

      • When you have users that share an email address, but are in the same tenant and have distinct accounts. FusionAuth enforces uniqueness on user.email per-tenant.
      • When your users have a username (such as an account number) as a main unique identifier, but need self-service account recovery.
      • When you have duplicate email addresses in a legacy system and are migrating them to FusionAuth, whether they point to the same account or not. You can move the users over and address email updates or account merges later.

      Not all email related functionality is available when using user.data.email, but common workflows like forgot password are.

      posted in Q&A
      danD
      dan
    • What are the use cases for the user.data.email field?

      I see the user.data.email field is used when it is present and user.email is not present. From the doc:

      This field will be used as the email address if no user.email field is found. This field may be modified by advanced registration forms or the API. Setting this value to another account's email address allows that account to, in some cases, access information about this user.

      What are the use cases for that field?

      posted in Q&A
      danD
      dan
    • RE: What are FusionAuth entities good for?

      Entities are one of the most flexible parts of FusionAuth and can be used to represent links and/or permissions between domain objects and users.

      Entity types are like classes in an object-oriented programming language, which define the permissions that an entity can have.

      Entities are similar to objects, in that they are an instantiation of an entity type. No behavior though, and no inheritance.

      Entities are connected to users and other entities via grants. You can think of this setting up a directed permission graph that can be traced.

      0 to N permissions are attached to each grant.

      There are three major uses for entities:

      • the client credentials grant (agentic, machine to machine or service account authentication)
      • building limited fine grain authentication (FGA-ish) systems that don't need full ReBAC, but do want to use a permission graph or dynamically add and remove permissions
      • modelling permissions on something you don't log into

      A few notes about entities:

      • you'll want to get familiar with the API or the client libraries; entities are managed in code. Both in creating the graph and reading it from your application.
      • each entity has a data field which can handle arbitrary JSON and is searchable
      • the graph can be cyclic if you make bidirectional grants between entities. Users cannot accept grants, they can only be granted permissions to entities.
      • if you need full ReBAC or ABAC, you want FusionAuth FGA. More functionality, including automatic relationship graph traversal. The downside is you have to sync data and run a separate service.
      posted in Q&A
      danD
      dan
    • What are FusionAuth entities good for?

      I'm curious about entities. What are they good for?

      posted in Q&A entities
      danD
      dan
    • RE: Importing users over time

      As of 1.69.0, you can now update the password hash using the User API.

      From the documentation, the passwordFieldType is the API field to use. This field:

      Describes what user.password in the request is. The possible values are:

      HASHED - user.password is an already hashed value. When this value is supplied, user.encryptionScheme, user.factor, user.password, and user.salt are required.
      PLAINTEXT - user.password is a plain text/unhashed value. FusionAuth will hash this value according to user.encryptionScheme and user.factor.

      posted in Q&A
      danD
      dan
    • RE: Email MFA Timeout

      You want to modify the Two-Factor Login duration in the Tenant Settings, which applies across to SMS and MFA methods.

      https://fusionauth.io/docs/get-started/core-concepts/tenants#advanced has more details.

      posted in Q&A
      danD
      dan
    • Email MFA Timeout

      Users who's email is lagged by 30 - 60 seconds , the emailed MFA verification code has expired by the time they receive them. I've done a Zoom meeting with the user and verified they are doing everything correctly, but their email is web mail based and must be from cloud provider that has a really slow system. They probably get the email about 60 seconds of they click send verification code and it always fails to verify.

      I can't find anything in settings to change the timeout or searching the documentation. Is there a setting for this somewhere that I could change or could Emailed Verification codes be good for at least 90 seconds?

      ported to forum from https://github.com/FusionAuth/fusionauth-issues/issues/3545

      posted in Q&A mfa email timeout
      danD
      dan
    • Intelligent MFA enabled for the forums

      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.

      posted in Announcements mfa meta
      danD
      dan
    • RE: How do I allow access to FusionAuth using agents?

      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.

      posted in Q&A
      danD
      dan
    • How do I allow access to FusionAuth using agents?

      how would I use the FusionAuth MCP server to allow an agent to interact with FusionAuth?

      posted in Q&A agent mcp
      danD
      dan
    • RE: Why Can Only One user_support_manager Remove MFA Devices in 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.

      posted in Frequently Asked Questions (FAQ)
      danD
      dan
    • RE: How to Block Logins Based on IdP Links in FusionAuth Without Storing API Keys in Lambdas

      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.

      posted in Frequently Asked Questions (FAQ)
      danD
      dan
    • RE: How to deal with sign-up spam?

      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

      posted in Q&A
      danD
      dan
    • RE: Disable login to an application without deleting it

      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.

      posted in Q&A
      danD
      dan
    • Disable login to an application without deleting it

      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.

      posted in Q&A login application disable
      danD
      dan
    • RE: What are account recovery options with FusionAuth?

      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.
      posted in Q&A
      danD
      dan
    • What are account recovery options with FusionAuth?

      What are account recovery options available with FusionAuth?

      posted in Q&A account recovery options
      danD
      dan
    • RE: how can I get an exact number of users with some attributes?

      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.

      posted in Q&A
      danD
      dan
    • how can I get an exact number of users with some attributes?

      How can I get an exact number of users with some attributes? I'm using elasticsearch.

      posted in Q&A search
      danD
      dan
    • RE: Collect additional attributes at login after a user has been created and registered

      Beginning in version 1.65.0, FusionAuth offers Complete Registration. Full docs here.

      How this would work:

      • enable a registration form for the application your users are logging into
      • select certain attributes as 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 need
      • set the Registration mode to Complete registration. This setting means that users cannot self-register, but can complete missing information from an existing registration.
      • save the application

      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.

      posted in Q&A
      danD
      dan