The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

From the user search docs, for the database search engine:

Regular expressions may not be used. A value of * will match all records.

For the elasticsearch search engine, you are limited to 10,000 records returned due to this bug: https://github.com/FusionAuth/fusionauth-issues/issues/494

Here's docs on how to switch between them: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

If you use the request body you should be fine. You can do a lot more than 500 if you like.

I would start with 5-10k and see how performance is.

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

You can use the user.data and registration.data fields to store arbitrary key value data.

If the metadata is associated with the user, use user.data. If it is associated with the user's account for a given application, use registration.data.

Note that this field is read/write via the API, but only readable via the administrative UI.

Here are some notes about the limits of these fields: https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources

And for the latter option, should I use a webhook for registration events

If you want a separate database, that's the way to do it. Listen for a webhook and create the records then.

Whether you should use the data fields or a separate database depends on what you are trying to do. The data fields are simpler and more tightly tied to the user records. You can also query them, but you'll be writing elasticsearch queries.

If you'd rather write straight SQL or will be storing lots and lots of data about a user (for example, their entire login history for analytics), then a separate database might work better. Of course, that's another system to maintain, so more complexity is the tradeoff.

If you want to add or remove a registration from a user (registrations are how a user is authorized to use an application) you could either allow someone to use the FusionAuth admin screen (possibly with a limited role) or you could use the API to build your own more limited interface.

Here's the API call you would want for this specific use case: https://fusionauth.io/docs/v1/tech/apis/registrations#delete-a-user-registration

@fusionauth_user, are you using Klemen's schema or did you create your own?

Symmetric keys are not returned on the JWKS endpoint, as they don't have a public key. Per the docs this api:

returns public keys generated by FusionAuth, used to cryptographically verify JWTs using the JSON Web Key format

If you create an RSA or EC key which is an asymmetric key pair - the public key will be returned on the JWKS endpoint.

The system status API call is the best solution here. It will return a status code when you (or your application load balancer, CDN or other software system) makes a GET request on <faurl>/api/status. It'll either be a 200 if things are all good or a 500 if there are any issues with the system.

It's documented more fully here: https://fusionauth.io/docs/v1/tech/apis/system#system-status

Note that this endpoint is not currently supported by the client libraries, but is just a curl away.

There is no way to create API keys from the API.

You can bootstrap the system with an API key using Kickstart. Kickstart would allow you to create one or more API keys, which can optionally scoped to a tenant. More on Kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

However, this doesn't solve the issue of dynamically creating a tenant scoped API key. If that's a use case for which you need support, please file a github issue: https://github.com/fusionauth/fusionauth-issues with more detail.

Yes, you want to use sourceTenantId when creating the tenant

You can keep a tenant around or use a particular one as the template, and then always create a new tenant using the sourceTenanId. This does not do a merge however, so if you want specific values, you’d want to do something like:

Call create w/ sourceTenantId Consume the response and then modify what you want Call update or patch with the new values

The client libraries all consume the same REST API, so you can use that as a reference: https://fusionauth.io/docs/v1/tech/apis/

This seems like a case for the client credentials grant, which is unfortunately still on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/155 Not sure that would help with the rotation, though. Just like username and password approach, I don't believe the credentials grant lets you rotate creds in.

Other options: you could look into a third party api management solution (as mentioned here).

Could you use longer lived JWTs but then a webhook to revoke them, as outlined here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts ?

You can control the duration on an application by application basis (so all JWTs issued by one application have to have the same length). You could create a 'services' application that only these services would have registrations with, not sure if that would work.