FusionAuth has the following known limits.
Each account must have a user identifier, either an email address or a username. Users may not have multiple email addresses. See this issue for more information.
When using the Elasticsearch search engine, the maximum number of users returned for any search is 10,000 users. There is an open bug tracking this issue.
You can work around this limit by writing one or more search queries to return less than 10,000 users.
For example, if you needed to pull all of your users, you could query for users with an email address starting with
A, then starting with
B, and so on.
You can also run your query directly against Elasticsearch.
FusionAuth stores most data in a database. Lengths of specific fields are documented in the database schema for your database type. Please download the database schema for your version of FusionAuth to review length limits for a particular column.
Many varchar columns have a length of 191. Why 191? In MySQL when using a
utf8mb4 (4 byte character set) on an indexed column, MySQL limits the usable characters to 191 to account for the overhead of the 4 byte addressing. The InnoDB MySQL engine has a max index length of 767 bytes (for mysql 5.7.9, the earliest version of MySQL which Fusionauth supports). Because we are using
utf8mb4 which allows up to 4 bytes per character, we end up with 767/4 ~ 191, so we set the column length to that.
FusionAuth is API first and every entity can be managed by an API. You can create an API key in the following ways:
Minimum Key Lengths
You can use FusionAuth to manage your cryptographic keys. Due to security considerations, FusionAuth won’t import keys below a certain length.
For RSA keys used to verify signatures, the minimum length is 1024. This key length is allowed as of FusionAuth 1.23.4 and supports external systems that rely upon this weak key length.
For RSA keys used for signing or any other purpose, the minimum length is 2048.
For ECC keys, the minimum length is 256.
See the Keys API for more, including supported algorithms and lengths.
There are a number of default entities which cannot be removed. Additionally, there are limits to modifying these entities.
The Default tenant
The FusionAuth application, which resides in the Default tenant. This will always have the Id
The Default theme, which is read only. This will always have the Id
The FusionAuth application roles, which may be assigned to users, but are immutable. View the roles documentation for the fixed Ids of each role.
FusionAuth supports SAML both as an Identity Provider (IdP) and as a Service Provider (SP).
The IdP implementation has certain limitations. Version
2.0 is supported; other SAML versions are unsupported.
FusionAuth supports two
Please examine the
NameIDPolicy of the software package for which you are configuring FusionAuth as the IdP to determine if these
NameIDPolicy values are supported.
There is an open feature request to support
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent but this
NameIDPolicy is currently unsupported.
FusionAuth supports the following SAMLv2 bindings:
Other bindings are not supported.
Identifiers (Ids) for entities in FusionAuth are UUIDs.
If you are creating an entity, such as an application, with the FusionAuth API, you can specify this Id, as long as it is a valid UUID. This works for users, applications, and tenants, among others, and makes it possible to avoid breaking external systems dependent on existing identifiers.
Data Type Changes In 'data' Fields
data fields on many types of objects:
If you are using the Elasticsearch search engine, the user.data, registration.data, and entity.data fields are indexed by Elasticsearch.
For example, you could create a field contained in user.data called migrated and store a boolean value. If you later set that field to an object value for any user, you won’t be able to search for that user. Other users added after this user will be found, however, as long as they have the correct boolean value for user.data.migrated (or no value).
Elasticsearch requires fields to have the same data type across all indexed objects. In the example above, once Elasticsearch "knows" that user.data.migrated is a boolean, it expects this field, if present, to be a boolean for all users.
Therefore, you should not change the data type of fields stored in these fields across entities.
Other object data fields may in the future be indexed by Elasticsearch. Therefore, it is recommended to maintain a consistent schema for all data contained in [field]data# fields.
This limitation applies only to installations using the Elasticsearch search engine. However, if you start with the database search engine and eventually need to switch to the Elasticsearch search engine because the database search engine no longer meets your needs, if you have not enforced consistency in the
data field types, you will not be able to do so.
TOTP Algorithm Implementation
While there is underlying support for different code lengths, algorithms and time steps, at the current time the system only allows for the following TOTP settings:
|Configuration setting||Currently allowed value|
Any attempt to change these configuration values will currently be ignored.
If you need different configuration settings, please file a GitHub issue detailing your use case.
What’s Not Limited
All other entities, including but not limited to the following, are limited only by the resources of your system:
Identity Providers such as SAML or OIDC connections
API keys to allow for programmatic configuration of and interaction with FusionAuth
Signing and verifying keys
Number of MFA methods per user
How helpful was this page?