ok main thing is, is it ok to use header ES256 for jwt created using secp256k1 keys?

https://datatracker.ietf.org/doc/html/rfc8812 says, secp256k1 curve should only be used with ES256k header, but in authfusion even if we give k1 pair keys and then use sign and encode a JWT using EC, it will come as ES256 only, is that okay?

Another doubt is, those jwt (k1 curve keys + ES256) created in authfusion is only able to verify in jose4j with .setRelaxVerificationKeyValidation() //needed if the key is smaller than 256 bits.

Without it we get the error:

JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.InvalidKeyException: ES256/SHA256withECDSA expects a key using P-256 but was null):

Description inside setRelaxVerificationKeyValidation :

Bypass the strict checks on the verification key. This might be needed, for example, if the JWT issuer is using 1024-bit RSA keys or HMAC secrets that are too small (smaller than the size of the hash output)

Is it the correct way to validate jwt created using ec in authfusion?

The tenant is using the "Default signing key (HS256)" for the access token.

Created the github issue - https://github.com/FusionAuth/fusionauth-issues/issues/1795

Validating the token on every new connection is considered best practice as it is the most secure.

There are two ways to validate a token. You can do it within your own application code leveraging a library that checks the signature and validates the claims (this only works when you sign your JWTs with a public key). Or you can do it by calling out to FusionAuth, and then validating the claims. For scalability/simplicity reasons, we recommend using the library unless there are reasons it won't work

By doing this server side using a library you no longer need to make the API call to FusionAuth to perform the validation. You would only need the public key of whichever signing key was used by FusionAuth. More on that here: https://fusionauth.io/docs/v1/tech/core-concepts/key-master#overview The public key is available via JWKS.

When using keys we also recommend you think about key rotation, explained in more detail here: https://fusionauth.io/docs/v1/tech/tutorials/key-rotation

If you decide on leveraging the endpoints (making a call to FusionAuth) for validation, here are a couple links that can be used depending on your scenario.

https://fusionauth.io/docs/v1/tech/apis/jwt#validate-a-jwt (proprietary)
https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo (part of the OIDC standard)

In both cases, you must validate the claims. Some are standard, as outlined here: https://fusionauth.io/learn/expert-advice/tokens/anatomy-of-jwt#claims-to-verify

But there may be app specific custom claims your code should verify too.

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.