I can see we can create applications and add tenants to them, which can't be edited/changed later. Is it possible to Add multiple tenants to one application? And maybe change the tenant later.

Nope, applications are contained within tenants. Here's a blog post talking about multi tenant in FusionAuth.

Also, on the documentation, it can be seen that in order to support multi-tenant or offer services to more than one client.
In this scenario, it is suggested to maintain separate Users, Applications, and Groups for each of your clients.

Yes, you can think of a tenant as an entirely separate installation of FusionAuth. So you'd have to create users, applications and groups for each tenant. Another way of structuring this would be to have an application for each client. Which you choose depends on how much separation you need.

what is the purpose of multiple application and multiple tenants?

The main purpose of using tenants in the higher level of separation. If you want each client to have their own FusionAuth theme, API keys, and a separate user space, then you want multi tenant. If you don't care about the themes, tenant scoped API keys, or that someone with the same email address wil have the same password for the application of client A and client B (because both use the same FusionAuth and live in the same tenant, the user will have the same password for each application), then separate FusionAuth applications in the same tenant will work.

Hmmm. That seems to be a bug, because the aud claim should be absent from the authorization code grant, since the user isn't registered for that application.

I filed an issue: https://github.com/FusionAuth/fusionauth-issues/issues/713

Have you tried webhooks?

Nope, webhooks completely slipped my mind, that's actually even better or my use case 🙂

Thanks for the detailed answer!

Here's a contrib project where community members have added proxy configs: https://github.com/FusionAuth/fusionauth-contrib

Please check out https://fusionauth.io/docs/v1/tech/tutorials/setting-up-user-account-lockout which walks you through the steps to lock logins after a configurable number of attempts.

We don't support this functionality at this time.

Pulled over from https://github.com/FusionAuth/fusionauth-issues/issues/700

Apparently jackson + friends make assumptions when it comes to parsing raw -> ZonedDateTime. It appears that the ZonedDateTime for createInstant when deserializing timestamps are not being handled properly somehow, so you need custom code. We have our own Jackson serializer and deserializer for ZonedDateTime to ensure we always get milli in and milli out.

Here's the code (Apache2 license) and the maven repository links if it's helpful.

Yes, a refresh token has a configured time to live (TTL). It can be configured at the Tenant or Application level.
More here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#jwt

There are a few ways to do this.

This assumes that you are running elasticsearch on a different server than you are running the fusionauth instances. If they are on the same server, you should be fine, as that is the default configuration.

The first is at the network level, using a firewall or something like security groups on AWS. If you are doing this, you can configure the server that elasticsearch is installed on to accept requests only from the server that FusionAuth is installed on.

The second is to use basic authentication. That is, set fusionauth-search.servers in the fusionauth.properties file, or the FUSIONAUTH_SEARCH_SERVERS environment variable to include the basic username and password. https://user:password@example.com. And make sure to set up elastic to use basic auth, using whatever authentication source you'd like. (You could even go meta and have elasticsearch auth the user against the fusionauth instance 🙂 ).

Further discussion here.

You need to use the user search API with an elastic search query string.

Here's a curl example:

API_KEY=.... GROUP_ID=f4a64b10-1cf6-4289-84c0-c3035f3b78bc curl -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/search/?queryString=memberships.groupId:'$GROUP_ID

If you are using the database search engine, you cannot find all the members of a group.

Regarding all the settings, yes, you'll have to set those up again. There's currently no way to export configuration of a FusionAuth setup.

What you can do is write a Kickstart file which lets you set up a new FusionAuth instance to be configured just how you want it. You basically build a JSON file which calls the APIs to configure FusionAuth: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

@ashok you got it!

FusionAuth does not have any plugins that directly write to 3rd party services like DataDog.

But with the API https://fusionauth.io/docs/v1/tech/apis/event-logs you can write an ingester.

Hiya!

You have a couple of options.

You should be able to use the validateJWT method on the fusionauth node client. That calls this API: https://fusionauth.io/docs/v1/tech/apis/jwt#validate-a-jwt

You can call into /oauth2/introspect, but you'll have to construct that URL manually, as it isn't currently supported by the client libraries.

Finally, you can also use a jwt package (like this one) to verify the JWT is still valid without communicating with FusionAuth.

Hope this helps.

It depends on the issue, but there are two things you can do. Note that FusionAuth typically sends the query you post to the /api/user/search endpoint with the query parameter straight through to Elasticsearch

First, ensure you are running elasticsearch and not the database search engine.

Then, for some queries you can see the generate ElasticSearch query strings by clicking on the 'advanced' option in the user search area of the admin UI. This can be helpful.

Finally, try running the query directly against elasticsearch and seeing if it works. Here are examples which will pull back all the data in your elasticsearch cluster (beware!).

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d' { "query": { "match_all": {} } }'

or, if you have the query stored in query.json

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d@query.json

Groups would be a good solution. The group just allows you to assign the roles to the group instead of the user - and then the group membership allows you to inherit those roles (assuming the user is registered for the application whose roles belong to the group).

I think you could look at the latest tag on dockerhub? https://hub.docker.com/r/fusionauth/fusionauth-app/tags

I'm not sure if there's an automated way to do this, but this might be useful: https://docs.docker.com/registry/spec/api/#pulling-an-image

UUID v4

More details about datatypes in general: https://fusionauth.io/docs/v1/tech/reference/data-types

@jmarin Interesting. What instructions are you working off of from Rosetta Stone?

Great. It's typically used for CSRF protection, but can be used for other purposes. Here's a pretty good article covering this.