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