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.
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.
@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.
FusionAuth is API first, so this type of flow could be created using our API and custom integration code.
On tenant B, a user from tenant A logs in.
Do a search for a user
If found, do a registration and/or user create using API.
The newly created user can now be logged in. As referenced above, you may have some interstitial pages that would be needed for password generation as the user passes from one tenant to another.
Another way to do this would be to reconsider how you are using tenants and applications. Depending on your business requirements, registering a user to a new application rather than a completely separate tenant removes a few steps from a workflow as described.
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.