Not currently. We've discussed it and haven't ruled it out.

However there are so many products, both free and commercial, that do this well.

You can always put a firewall on the server that FusionAuth is running or put a proxy in front of it.

@denisskaletti Thanks for feedback. I removed your link because it seemed like spam. We welcome useful links that are about using FusionAuth, please check out the blog category and post there.

You could look at kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

This would be a good fit if the other devs fusionauth instances are going to be starting from scratch.

Otherwise you might want to vote for https://github.com/FusionAuth/fusionauth-issues/issues/560 which talks about a different path forward (which is as of now unimplemented).

You can experiment in the admin UI using the search field.

You can use the query string DSL or a full JSON query in the search field, if you are running elastic search.

Here's a link to building an ElasticSearch query (in version 6.3): https://www.elastic.co/guide/en/elasticsearch/reference/6.3/query-dsl-query-string-query.html

For example if you have companyName in custom data, the query string would be data.companyName:"Acme Corp."

If you are using the database search, you won't be able to use this kind of querying.

Here's more on the difference between the database search and elasticsearch options for user search: https://fusionauth.io/docs/v1/tech/core-concepts/users#user-search

We do not support this directly in FusionAuth, but you could use a Lambda to set the aud claim to whatever you want.

The specification allows for a string value, or an array of string values, so you could create a Lambda with something like: jwt.aud = [ 'foo', 'bar' ];

More about Lambdas and JWTs here: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

While we continue to improve FusionAuth (and will always have a free community edition), if you are interested in paying for a specific feature to be built, we're happy to chat. Please contact us and we'll be happy to discuss costs and timelines.

You can search on the user id. While it doesn't say that in the placeholder, it works.

There are a few things to consider.

how long tokens live for what happens if permisssion are modified in FusionAuth but the protected resource still allows access? any performance worries due to a large number of accessToken validation calls being made by the protected resource.

With the first approach (validating the access token without communicating with FusionAuth) the holder of the token will be able to access your API as long as the token is valid (unless the API server communicates periodically with FusionAuth to check the validity). In addition, changes to user privileges won't take place until the JWT expires and the client retrieves a new access token using the refresh token.

With the second approach, if a token is revoked in FusionAuth (if for instance the user is disabled) the access is cut off immediately. The cost is that you're making an additional network call every time, which has a performance impact. Note that if you could use the userinfo endpoint instead of the token if you want updated user claims. The token endpoint isn't going to give you that information, just a yes/no depending on if the token is valid.

So it's hard to make a recommendation without knowing what the consequences of unauthorized access to your API or protected resource would be. It also would be helpful to know the expected traffic; if it is expected to be low, the performance impact of the second approach will be minimal.

Themes are mapped to tenants. Per https://fusionauth.io/docs/v1/tech/apis/themes

Themes are configured per Tenant.

That is correct. Each user can have one email address, one username, or both. Either of these values can be used to login, and therefore the values are unique within the tenant.

We do have a username field on a registration, but it is not used for login.

There's a github issue open for multiple identities: https://github.com/fusionauth/fusionauth-issues/issues/1

Yes, you can provide the tenantId on the request as a parameter. More information here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#openid-configuration

You can use the post_logout_redirect_uri query parameter on the logout endpoint to configure where a user ends up after logout.

More here: https://fusionauth.io/docs/v1/tech/oauth/endpoints

@bboure You may be interested in this new feature from the 1.17.0 release, which allows for a sliding window of refresh tokens:

Sliding Window Refresh Token Expiration. By default the expiration of a refresh token is calculated from the time it was originally issued. Beginning in this release you may optionally configure the refresh token expiration to be based upon a sliding window. A sliding window expiration means that the expiration is calculated from the last time the refresh token was used. This expiration policy means that if you are using refresh tokens to maintain a user session, the session can be maintained as long as the user remains active. This expiration policy must be enabled at the tenant level, and may optionally be overridden by the Application JWT configuration.

@rnsupercool

Unfortunately, there's no way to extract the password and the other information via the APIs.

Options I could see working:

if you have developer edition (or other paid edition), you could set up a connector from FusionAuth to itself (via a generic http connector). This would take time to move the users to a different tenant. you can get a database dump of your FusionAuth instance and run a bulk import of the user data, password, and other password settings into another tenant. you could move over the users, set a random password and force them to change their password by setting passwordChangeRequired. Not sure that would definitely work; you should test this.

Hope this helps.

Yes. We don't have any specific guidance around using MySQL and PostgreSQL in an high availability configuration. However, it should work. This document discusses the various possible architectures at a high level: https://fusionauth.io/docs/v1/tech/installation-guide/server-layout

It is worth noting that MySQL group replication will not work. It requires a primary key on each table. We do not meet this requirement and have no plans to adjust the schema for this style of replication to work. Other types of replication that do not require a PK on every table should work.

The particulars of DB clustering are outside of the scope of what we can assist with, however.

You always get the same features whatever level you are at no matter where you host. That is to say, if you have a premium plan, you can host or we can, the features are the same. If you use the community edition, the features are the same no matter where you host.

However, there are feature differences between the premium and community plans. More here: https://fusionauth.io/pricing

Yes. You can view our plans here: https://fusionauth.io/pricing

Each plan has the same level of support whether you are hosting with FusionAuth or in your own cloud or data center.