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.

@fred-fred

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.

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.

@dwong

FusionAuth is API first, so this type of flow could be created using our API and custom integration code.

Roughly:

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.

Reference documentation -> https://fusionauth.io/docs/v1/tech/apis/

Thanks,
Josh

@dan 160ms

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.