There are a couple of overlapping layers here.

1. Access tokens aren’t revocable by default
   Access tokens (JWTs) are self-contained. Once issued, they remain valid until they expire unless you implement a custom revocation strategy (such as token blacklisting). FusionAuth covers one approach here:
   https://fusionauth.io/articles/tokens/revoking-jwts
   So if your access token lifetime is 600 seconds, a disabled user could continue to access APIs until that token expires (up to ~10 minutes) unless you add an additional revocation layer.

2. FusionAuth sessions are typically independent from the IdP
   Once the upstream IdP authenticates the user, FusionAuth generally maintains its own session state. If a user is disabled in the upstream IdP, that does not automatically invalidate FusionAuth sessions or prevent refresh token usage.
   So yes, depending on your implementation, a user can potentially continue to operate in FusionAuth even if they are disabled upstream, until you either:

   • expire/stop honoring their tokens, or
   • remove/disable the user in FusionAuth, or
   • enforce additional checks at login/session refresh time.

3. Options to meet “disabled within 300 seconds” for one customer
   If you need disablement to take effect quickly without shortening sessions for everyone, you generally need an integration that pushes the disablement signal into FusionAuth (or into your resource servers).

   A. SCIM (best fit when the customer maps cleanly to a tenant)
   If your customer can be logically isolated (e.g., “customer A users live in tenant A”), SCIM is a strong option. The customer’s IdP can provision/deprovision users into FusionAuth, and a disable/delete action can remove their FusionAuth access (including sessions). This is the cleanest approach when tenant segmentation is possible.

   B. Event-driven deprovisioning (IdP → your service → FusionAuth API)
   If the customer’s IdP can emit events (user disabled/deprovisioned), you can build a lightweight integration that:

   • receives the IdP event, then
   • disables or deletes the corresponding user in FusionAuth via API.

   Once the user is disabled/deleted in FusionAuth, they won’t be able to continue normal authentication flows.

   C. Token revocation strategy (resource server enforcement)
   If the requirement is “deny access within 300 seconds,” the most deterministic way is to enforce it at the API/resource-server layer by:

   • using short access-token lifetimes (<= 300 seconds), and/or
   • adding token blacklisting / introspection-style checks in your APIs.

   This avoids relying on refresh token expiration to enforce disablement.

About limiting refresh token lifetime per customer

A reconcile lambda can help with user provisioning and claims, but it won’t reliably solve the core issue of existing sessions and refresh tokens already issued. There isn’t a simple “per-customer refresh token TTL override” you can apply after the fact without an architectural approach like the ones above.

We have a customer with strict session-lifetime requirements and I’m trying to understand the best way to implement them in FusionAuth.

This customer authenticates through their own IdP, which we’ve configured as an Identity Provider in FusionAuth. In our tenant, we’ve configured:

• Access token (JWT) duration: 600 seconds
• Refresh token duration: 960 minutes

These settings work well for users who log in directly through FusionAuth because they can stay signed in for a long time without re-authenticating.

However, this customer requires that if a user is disabled, they must be denied access to our application within 300 seconds or less.

My understanding is that FusionAuth will continue to honor the user’s existing session (via refresh tokens) for up to the full refresh token lifetime, and the user won’t be forced back to the customer’s IdP until the refresh token expires.

1. Is that understanding correct?
2. If so, what options do we have to meet this customer’s requirement without forcing all users to re-authenticate every few minutes?
3. Can we limit refresh token lifetime for only this customer, possibly via a reconcile lambda or another mechanism?

At this time, FusionAuth does not support changing WantAssertionsSigned to true in the generated SAML metadata. This value is hard-coded and cannot be modified through IdP configuration or other settings.

From a practical standpoint, this should not impact security or standards compliance. FusionAuth signs the entire SAML response using the verification key configured in the IdP. Since the assertion is part of the signed response, signing the assertion itself would be redundant and is not required by the SAML specification.

If your client strictly requires WantAssertionsSigned="true" due to a non-standard or legacy implementation, this would need to be addressed on the Service Provider side, as FusionAuth cannot currently emit metadata with that value set to true.

We have a client requirement for our SAML metadata to specify WantAssertionsSigned="true".
We’ve configured a verification key in the Identity Provider (IdP) settings, but when we generate the metadata, the value still appears as WantAssertionsSigned="false".
Is there a way to configure FusionAuth to set this value to true in the generated metadata?

@rachel-flatt It is odd that you do not see the page. Are you an admin user? Can you post a screenshot with what you do see? (Please be sure to redact secrets and private information)

@brad sounds super frustrating.

I'll send you a message.

You’re correct—there is no fixed limit on the number of hosted FusionAuth instances you can have.
However, since your account is on invoiced billing, new hosted deployments cannot be created directly through the Account Portal. That functionality is only available for self-serve billing accounts.

Next Steps

• Our Customer Success team will reach out to you via email.
• They’ll help provision the additional non-production instances and add them to your existing order.

Once that’s complete, you’ll have access to the new hosted deployments without needing to manage them through the portal yourself.

I’m reviewing the Hosting page in the FusionAuth Account Portal but don’t see an option to create a new hosted instance.

Based on the documentation and what I’ve found so far, there doesn’t appear to be a hard limit on the number of hosted instances. Is there a different process for creating additional hosted deployments, or is something preventing this option from appearing in the portal?
Ultimately, we’re looking to add at least two additional non-production instances.

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.

We are evaluating FusionAuth for JWT-based API authentication and would like to better understand how this fits alongside end-user authentication.

Specifically:

1. Is it possible to authenticate API clients and end users within the same tenant, given that some controls (such as MFA) are configured at the tenant level?
2. If so, what is the recommended approach for structuring API authentication separately from end-user authentication?
3. Are there any licensing or cost implications associated with these approaches (for example, using separate tenants, applications, or service accounts)?