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.

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

This guide might be helpful to you: https://fusionauth.io/docs/v1/tech/guides/user-search-with-elasticsearch

Thanks,
Dan

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

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.

FusionAuth Kickstart(tm) is super easy and if you can do it with an API, you can do it in Kickstart. Kickstart allows you to build a template that will be executed during startup to quickly replicate development or production environments.

It's a JSON document that is executed when a FusionAuth server is being started up from scratch, and allows you to replicate configuration between different environments. It's especially useful for CI environments, where you may want to run tests against a known configuration, and dev environments, where you may want to wipe and re-setup your FusionAuth instances regularly.

Hiya,

In addition to what @maciej-wisniowski suggested, if you have a paid license you can now have application specific themes (one theme per application; if no application theme is specified, it defaults to the tenant).

You can see how that works in the sandbox environment (sandbox.fusionauth.io). I believe that feature landed in 1.27.0.

You can buy a licensed edition here.

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

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

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.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.

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