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.

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

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.

@oliver-muthusami hmmm. I did some poking around Microsoft's documentation and found this.

The inclusion of the refresh token in the response can depend on several factors, including the specific configuration of your application and the scopes requested during the authorization process. If you expect to receive a refresh token in the response but fail to, consider the following factors: Scope requirements: Ensure that you're requesting the offline_access scopes along with any other necessary scopes. Authorization grant type: The refresh token is provided when using the authorization code grant type. If your flow differs, the response can be affected. Client configuration: Check your application's settings in the identity platform. Certain configurations may restrict the issuance of refresh_tokens.

Are you sure you have Entra configured correctly?

@dalamenona I see your point about the Database_primary_pool_MaxConnections being set to 20 on the value for usage being reported above that. Browsing around the web, I came across something that said Database_primary_pool_Usage is over the lifetime of the application, but can't seem to find the source now. You also make a valid point about around the other data defenitions. It may make sense to do a deeper dive into HikariCP sources in general. There may be some answers there.

Anyone here familiar with these numbers?

It may also make sense for you to open an issue with FusionAuth as it is not clear to me if these numbers are coming from FusionAuth or HikariCP.

@marcel-beutner If you have found a bug, you may want to report it using the FusionAuth Issues.

I just did a search on 1.61.0 in the Admin UI and my results were sortable by the name. Can you give us the exact query you used to use the search API and the search you used in the search bar? I am curious to see if that returns something different.

Hi there, I'm working on the same project. And since this forum post, the error did not occur again for about a month and has recently occurred 3 times in the last week.
The instance is a fusionauth instance.
(auth.*.ch is a CNAME (alias) for bnjmvfriojf0pzpzhtmmz6xf2sgl6b.durable.fusionauth.io)

The access where the error occurs was via browser (firefox to be exact if sentry is to be believed).

There are no recent changes to the CORS config.

For most of our users this does not seem to be an issue. It happens very isolated for a handful of users.

@dftz3966 said in Is there away to provide error message data from a webhook via either Webhook or Event logs?:

@mark-robustelli said in Is there away to provide error message data from a webhook via either Webhook or Event logs?:

@edschlough If you take a look at the example code from the webhook documentation, it shows how to return errors. Is this what you are after?

Thank you so much
Wow! This is what I need, thank you for sharing

@mark-robustelli Well, here are some screenshots:

at first I added a new IdP - via API POST /api/identity-provider - and the existing dummy/placeholder certificate is linked:
7ee96348-07c1-4845-8a9a-26998572d0e0-image.png
-> this is the only IdP

then I import - via API POST /api/key/import - the correct certificate:
ab51c6c5-1c2b-4939-a01d-2e045274400d-image.png

but I do not link this in the IdP, and so do not set the Verification key

Do I get it right, that the login should not work in that case? But I am able to login via this EntraID IdP.

@vijaysingh1784 Looks like you have done a bit of research your self and made a pretty good analysis. I am not very familiar with MojoAuth, but just to confirm a few things:

FusionAuth is very customizable. You should check out things like Lambdas, Webhooks and other various options.

FusionAuth can be self-hosted or can be hosted for you.

FusionAuth handles SAML, SCIM and other various integrations.

FusionAuth is very scalable and gives you great control with api acess and other mechanisms.

Depending on your needs, FusionAuth can be as easy to self host as spinning up a docker image to a full blown complex K8s deployment. It should fit your needs there.

While there is no direct migration guide for the product you are talking about, there are several other migration guides for you to look over that should give you an idea on how to do it.

@manoj-patil said in We are getting ERROR org.primeframework.mvc.PrimeMVCRequestHandler - Error encountered:

t F ... 63 common frame

Under what circumstances and you receiving this error?

@mark-robustelli

We used Lambda to get audit and event logs from DB and put in CloudWatch

@chad-hurd Awesome that you got if figured out. Do you mind sharing what, specifically, was wrong with the setup? It may help others down the road.

FusionAuth doesn’t support uploading a CSV to retrieve last-login timestamps. However, you can do this efficiently with the Search for Users API and return lastLoginInstant for many users at once.

How to do it (batch via API)

Use the User Search endpoint
POST /api/user/search (set your X-FusionAuth-TenantId and Authorization headers).

Send an Elasticsearch query using terms to match a batch of emails/usernames, and read lastLoginInstant from each returned user:

{ "search": { "query": "{\"terms\":{\"email\":[\"a@example.com\",\"b@example.com\",\"c@example.com\"]}}", "numberOfResults": 500, "startRow": 0 } } Swap email for username if that’s what you have. If your list is large, chunk it (e.g., 200–500 logins per request) and paginate with startRow / numberOfResults. (Optional) Filter by last-login date with a range query on lastLoginInstant: { "search": { "query": "{\"range\":{\"lastLoginInstant\":{\"gte\":\"2025-10-01T00:00:00Z\"}}}" } }

You can also query by epoch millis if you prefer.

Map results
Each user object includes lastLoginInstant (epoch millis). Convert to your desired timezone/format in your script and write out a CSV.

Tips

If you need all users in a tenant (not just your list), you can search with a wildcard or a match-all query and page through results, then filter locally. For ongoing metrics, consider subscribing to user.login.success webhooks and recording last logins as they happen.

Docs:

Search for Users API (Elasticsearch): https://fusionauth.io/docs/apis/users#elasticsearch-search-engine

You can work around this by passing the IDs directly in your request. Here’s an example of how to structure the request correctly:

from fusionauth.fusionauth_client import FusionAuthClient api_key = 'your-fusionauth-api-key' base_url = 'https://your-fusionauth-instance.com' group_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' user_ids_to_remove = [ 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy', 'zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz' ] client = FusionAuthClient(api_key, base_url) member_delete_request = {'members': {group_id: user_ids_to_remove}} response = client.delete_group_members(member_delete_request) if response.was_successful(): print("Successfully removed users from group!") else: print(f"Error: {response.error_response}")

This approach correctly formats the request for the API to process and delete the specified users from the group.

@batmysta, Thanks for clearing that up. Unfortunately, there is no way I know of to configure federated authentication with the FusionAuth Account Portal.