There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

If a user is not registered for the Application they are logging into FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

Yes, you can mix API clients and end-user logins within the same tenant. Tenant-level controls such as MFA do not prevent this when the authentication flows are properly separated.

Recommended Approach: Use Entities for API Clients

The most common and recommended pattern is to use Entities for API authentication:

End users authenticate using the Authorization Code grant, which can enforce MFA and other user-facing security requirements. API clients authenticate using the Client Credentials grant via Entities. Because these are different OAuth grants and flows, tenant-level requirements like MFA apply to users but do not apply to API clients using client credentials.

This allows both authentication types to coexist cleanly within the same tenant while maintaining appropriate security boundaries.

Cost and Licensing

There are no additional licensing or cost implications for using this approach:

Entities and the Client Credentials flow are included in FusionAuth plans. API clients authenticated via Entities do not count as end users for MAU-based billing.

Additional Resources

These resources provide detailed guidance and examples:

API Authorization with FusionAuth Entity Management Concepts Using Entities for API Authorization (Video)

This setup is widely used and should cover your use case well.

Yes. You can use FusionAuth's OpenID Connect Identity Provider.

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

A yahoo account A running FusionAuth instance (localhost is fine)

Steps:

Go to the Yahoo! developer network and create an app. The redirect URI for Yahoo is https://<your instance>/oauth2/callback Save off the provided Client ID (Consumer Key) and Client Secret (Consumer Secret). Then go to FusionAuth and create an OpenID Connect Identity Provider: <your instance>/admin/identity-provider/add/OpenIDConnect Put the Client ID (Consumer Key) and Client Secret (Consumer Secret) into the Client Id and Client secret fields, respectively. Uncheck Discover Endpoints. Manually configure the endpoints: Set the Authorization Endpoint to https://api.login.yahoo.com/oauth2/request_auth Set the Token Endpoint to https://api.login.yahoo.com/oauth2/get_token Set the Userinfo Endpoint to https://api.login.yahoo.com/openid/v1/userinfo Set the Scope to openid email profile and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.) Update the Button text and Button image as needed. Enable it for applications as needed. Save the Identity Provider.

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:

API Authorization with FusionAuth Tenants Overview JWT Anatomy Authorization Models

Good question—it’s a common challenge.

By default, the email verification flow breaks the OAuth/PKCE context because the user leaves the registration page to check their email and clicks a verification link. FusionAuth can’t continue the OAuth flow automatically from that email link, which is why your hard-coded redirect URI fails without the required OAuth code.

A better solution is to switch your email verification strategy from Clickable Link to Form Field (under Tenant → Email → Email Verification → Verification Strategy). With this approach, users stay on the original registration page, enter the verification code from their email, and the OAuth/PKCE flow remains intact—including the authorization code. This enables seamless redirecting back into your app after verification.

If you’re creating and registering users for an application at the same time, remember to also check the app-level registration verification settings under:
FusionAuth Admin UI → Applications → Edit Application → Registration tab.

More details are in the docs: Registration Email Verification

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

There isn’t a way to stop FusionAuth from synchronizing the user object when using a generic connector. Even when a third-party system is the “system of record,” FusionAuth still requires a local user record to support its internal workflows and features. If you choose not to migrate users into FusionAuth, your external system must also provide application registrations on the returned user object to ensure proper integration.

Regarding your first question, there’s no way to prevent an error if the user.id changes between logins. The id field in the user object should remain consistent across logins. Changing it will inherently cause issues with how FusionAuth matches and manages user records.

For more detail, see the documentation here:
Using the Generic Connector as the System of Record

At this time, the generic connector in FusionAuth only supports a single error response type:

The connector returns a 404 Not Found in any failure scenario, whether: The user does not exist in the external system, or The user exists but provides invalid credentials.

This design is intentional and exists to prevent user enumeration attacks by not revealing which part of the login process failed.

Because of this security restriction:

You cannot display different error messages on the hosted login page for different connector failure scenarios. There’s no way to pass additional custom data or error context from the generic connector to the hosted templates for display purposes.

You can read more details here:
Generic Connector - Response

Here’s how you can approach securing access to your FusionAuth instance:

IP Access Control Lists (ACL):
You can define IP Access Control Lists in FusionAuth by navigating to Settings > IP Access Control in the Admin UI. Click the + icon to create a new ACL list. Add entries for each IP address or range you want to allow or block. Assign these ACLs to specific tenants or API keys as needed. Important Note:
IP ACLs restrict access to endpoints like /oauth2/, /account/, /email/, /password/, /registration/, and other user-accessible pages. However, they do not restrict access to the FusionAuth Admin UI unless the Admin UI is accessed via SSO.
Documentation: IP ACL API Overview Secure the Admin UI:
Since IP ACLs do not directly secure the Admin UI, consider the following options: Use a Trusted Proxy:
Place a trusted proxy at the edge of your network to filter incoming traffic before it reaches FusionAuth. The proxy can enforce IP-based restrictions or other security rules. In FusionAuth, configure your proxy under System > Networking, where you can specify the proxy’s IP address. If a request doesn’t go through the trusted proxy, FusionAuth will deny access.
Documentation: FusionAuth Networking Login Lambda for Additional Validation:
Implement a Login Lambda to validate login attempts further. This Lambda allows you to execute custom code during login, such as checking the origin IP or other request details to block unauthorized attempts.
Documentation: Login Lambdas Recommended Next Steps: Configure IP ACLs for your tenants and API keys to secure application-level access. Implement a trusted proxy to filter admin panel access based on source IP. Use a Login Lambda for additional request-level security, if needed.

By combining these approaches, you can enhance the security of your FusionAuth deployment and mitigate unauthorized access.

The 11 Lambdas you see are the default ones included with FusionAuth. To create a JWT Populate Lambda, follow these steps:

Navigate to Settings > Lambda in the FusionAuth Admin UI. Click the green + button in the top right to create a new Lambda. In the "Type" dropdown, select JWT Populate. Configure your Lambda logic as needed.

For additional guidance, you can refer to the JWT Populate Lambda documentation, which includes a helpful video walkthrough of the process.

Yes, this can be achieved using FusionAuth’s Webhooks. You can trigger a Webhook when the user.registration.verified event occurs and send the necessary data to Google Tag Manager (GTM).

Steps to Set Up:

Create a Webhook in FusionAuth: Navigate to Settings > Webhooks in the FusionAuth Admin UI. Create a new Webhook and configure it to trigger on the user.registration.verified event. Enable the Webhook for Your Tenant: Go to Tenant > Webhooks and enable the Webhook for the desired tenant. Integrate with GTM: While FusionAuth Webhooks send data to external systems, ensure that GTM can ingest Webhook data. From my research, GTM supports Webhook ingestion, but you may need to configure a custom setup within GTM to process the incoming data.

Resources for Reference:

FusionAuth Events and Webhooks User Registration Verified Event

This approach allows you to track account verification events seamlessly.

The sendSetPasswordEmail functionality currently has a limitation in that it doesn’t allow you to pass custom data for use in the email template through the API. However, you can still achieve personalization by configuring the email template directly in the FusionAuth Admin UI.

Steps to Personalize the Setup Password Email:

Edit the Email Template: Navigate to Customizations > Email Templates > Setup Password in the Admin UI. You can either edit the existing default template or duplicate it to create a new one. Use variables like ${user.firstName!'Unknown User'} or any other user data fields to customize the message. Assign the Template to Your Application: Go to Applications in FusionAuth. Edit your application and assign the appropriate template to the Setup Password field. Consider Custom Message Content: Include static or semi-dynamic content like "You were invited by ABC" in the email template. If you have multiple initiators, you might need to create separate templates for each scenario.

Documentation for Reference:

Email Templates and Replacement Variables FusionAuth Email Templates

While the API does not allow for passing custom fields directly for sendSetPasswordEmail, configuring the templates in the Admin UI should allow you to achieve the desired level of personalization.

FusionAuth provides replay-resistant authentication mechanisms by adhering to industry standards for the technologies it implements. The level of replay resistance depends on the authentication workflow and specific standards followed.

Key Standards:

OAuth 2.0: FusionAuth adheres to RFC 6749, RFC 8628, and OpenID Connect Core, which include mechanisms to mitigate replay attacks (e.g., nonce and state parameters). Documentation: OAuth 2.0 Authorization Code Grant Example Other Standards:
FusionAuth follows established standards for other authentication protocols, such as: WebAuthn: Provides strong, cryptographic-based authentication resistant to replay attacks. SAMLv2: Uses unique assertions and timestamps to prevent replay. OIDC (OpenID Connect): Includes nonce and other mechanisms to mitigate replay.

Replay Resistance Considerations:

Replay resistance is primarily ensured when these protocols are implemented as defined by their standards. FusionAuth provides the tools and configurations necessary to follow these standards. However, deviations from these standards or implementation flaws outside of FusionAuth’s control (e.g., improper handling of state or nonce values) could introduce vulnerabilities.

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?

JWTs Cannot Be Revoked: Once a JWT is issued, it remains valid until it expires. JWTs are decoupled authentication tokens, meaning they do not require continuous validation against a central authority. While OAuth2 includes a token introspection endpoint, it is only useful for access tokens and does not support JWT revocation. What the /oauth2/introspect Endpoint Does: This endpoint verifies whether an access token is valid based on its signature, expiration time, and format. It does not check whether a user’s account has been locked or disabled. Impact of a Locked Account on JWTs: If a user’s account is locked, they will not be able to obtain a new access token. However, any previously issued JWTs will continue to be valid until they expire, unless you implement additional measures. How to Handle JWT Revocation:
Since OAuth2 does not include JWT revocation natively, you can implement one of the following approaches: Use Short Token Lifetimes: Issue JWTs with short expiration times and rely on refresh tokens for continued access. Leverage Webhooks for Denylisting: Use FusionAuth’s event system to notify services when a user is locked or a token should no longer be valid. Services can then maintain a blacklist of invalidated JWTs.

For more details, refer to:

Revoking JWTs in FusionAuth

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

This is not available today without some glue code.

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success https://fusionauth.io/docs/apis/users#update-a-user

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user if you are self-hosting, block access to the /register endpoint using a proxy if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.