Not currently.

You could create a single user called anonymous and auth that user to get a generic token.

There is an open issue for a more elegant solution; feel free to upvote it: https://github.com/FusionAuth/fusionauth-issues/issues/525

This depends on how the JWT was signs, but is probably fine, especially if JWTs are only used in APIs. It's very typical to want to ensure that existing JWTs are accepted as long as they haven’t expired. You'll also need to ensure that new JWTs from FusionAuth are also accepted.

So this is really a question of making sure the JWT producers and consumers have the correct signing secrets.

You can solve this by sharing the secrets between the old system and FusionAuth (check out the Keymaster to import existing keys or making sure your clients can look up the keys from a JWKS endpoint from both the old and the new system.

The JWT (id_token or access_token) will contain the email_verified claim with a value of true or false, so if you wish to limit privilege based upon this state, that would be a good way to do it.

You’re correct. That is not a standard redirect URL. You could easily build some glue code to to look like an OpenID Connect compliant SP and then handle the redirect yourself. I am not super familiar with some of the OpenID Connect server options, but something like Hydra may be useful here. Perhaps some others from the community here can help with off the shelf options if you don’t want to code it yourself.

But coding it yourself may be the easiest, if you coded it in Node or something like that, it would be super simple, you’d have FusionAuth redirect to your node app and then you’d redirect to the video platform.

There's additional localization and internationalization doc that was written recently here: https://fusionauth.io/docs/v1/tech/core-concepts/localization-and-internationalization/

The team wrote a tutorial outlining how to rotate keys, including signing keys: https://fusionauth.io/docs/v1/tech/tutorials/key-rotation/

Hiya,

When you say

Everybody can see authorization key.

Who do you mean? Do you mean anyone with access to the FusionAuth admin console? Or some other set of users?

In general you are going to want to use a Lambda to populate additional claims: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

This issue has some notes about Hasura in particular: https://github.com/FusionAuth/fusionauth-issues/issues/61

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

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