The way to do this is to use the user.data or registration.data objects as a transfer mechanism.

If you are using OIDC (SAML is much the same, but I'll use OIDC as an example), you can create a OIDC Reconcile Lambda. It might look like this:

// Using the JWT returned from UserInfo, reconcile the User and User Registration. function reconcile(user, registration, jwt) { user.data.favoriteColor = jwt.favoriteColor; }

So the jwt in this case is that returned from the OIDC identity provider. We store the data in user.data.

Now we need to pull it off of the user.data object using a JWT populate lambda. That might look a little something like this:

// Using the user and registration parameters add additional values to the jwt object. function populate(jwt, user, registration) { jwt.favoriteColor = user.data.favoriteColor; }

favoriteColor is now available as a claim in the JWT produced by FusionAuth.

Don't forget to assign your lambdas to the correct operations. The OIDC Identity provider needs to be configured with the reconcile lambda. The application's JWT tab is the right place to configure the use of the JWT populate lambda.

More information on all the lambda options available here: https://fusionauth.io/docs/v1/tech/lambdas/

No, FusionAuth doesn't support adding JWT headers to FusionAuth generated JWTs. I looked at the code and don't think it'd be a ton of work to add support; there's already some scaffolding in the fusionauth-jwt OSS project.

I highly encourage anyone with this problem to file a feature request here with more details about your needs: https://github.com/fusionauth/fusionauth-issues/issues

We consult that in our roadmap planning. We also offer professional services if you need us to build it on a schedule. Please send a request to our sales department if that is an option you'd like to pursue.

An alternative would be to build a service that would re-sign your JWTs from FusionAuth with the needed header changes. Not optimal, I understand, but another avenue that might get you what you need.

That is an encoded (signed) JWT being sent in response to the user info request that the FusionAuth OIDC identity provider is making.

This is technically allowed in the OIDC spec, but we do not currently support this response type.

Per spec, the endpoint should support a JSON response which is the default unless the client requests a signed or encrypted response body.

I would look at how your client is registered and see if it is asking for a JWT userinfo response at that time, and change it to be a normal JSON response. You could also file an issue detailing your needs for FusionAuth to support this user info response type.

If that isn't an option, you could also look at using a SAML Identity Provider if the remote identity source supports that.

Yes. You can use the Authorization Code grant with cookies. Here is a workflow diagram of this: https://fusionauth.io/learn/expert-advice/authentication/webapp/oauth-authorization-code-grant-jwts-refresh-tokens-cookies/

No, those tokens are completely de-coupled from FusionAuth (in a fundamental way, that is the point of those tokens).

There are revocation strategies however, but they require some additional work.

Here is one strategy we have documented: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts/

You should always validate your JWT locally.

As outlined in this doc, you need to make sure, at a minimum, that the aud, roles, and iss claims are as expected, and that can only be done by looking at a JWT and examining those claims. If you use a library that supports JWKS, doing this should be super simple.

Note that the FusionAuth API endpoint validates JWTs at a basic level. It ensures that the JWT hasn't expired and that it was signed correctly.

The reasons to use the API endpoint are:

If you have an HMAC signed JWT and you don't want to share the secret with the JWT consumer If you have no JWT library that is available (whether because it hasn't been written, or you don't want to deploy it with your application) You are willing to accept a network call instead of loading up a such a library

That's great to hear, glad you figured it out!

If you want to skip calling FusionAuth for each of these validation events, you can validate the JWT on your end without a network call.

If you configure a key pair (public + private) to sign your JWT, then the public key will be available in the JWKS. Many libraries exist that will validate JWTs using JWKS.

https://fusionauth.io/docs/v1/tech/oauth/endpoints/#openid-configuration
https://fusionauth.io/docs/v1/tech/oauth/endpoints/#json-web-key-set-jwks

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.

Seems like the library I used is opinionated. Thanks for the hints.

Yes. While OAuth2 access tokens aren't guaranteed by the spec to be JSON web tokens, in FusionAuth access tokens are always JWTs.

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