Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

I'm facing challenges validating JWTs generated by FusionAuth using RSA-SHA256 within my .NET application using the JwtBearer middleware. I've generated a public/private key pair in the FusionAuth Key Master and configured my application as follows:

public static void AddFusionAuthentication(this IServiceCollection services)
{
    var fusionAuthSettings = services.BuildServiceProvider().GetRequiredService<IOptions<FusionAuthSettings>>().Value;
    byte[] publicKeyBytes = Convert.FromBase64String(fusionAuthSettings.IssuerSigningPublicKey);
    
    services
        .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(opt =>
        {
            opt.Authority = fusionAuthSettings.FusionAuthUrl;
            opt.Audience = fusionAuthSettings.ClientId;
            opt.IncludeErrorDetails = true; // for debugging

            opt.TokenValidationParameters = new()
            {
                ValidateIssuer = true,
                ValidIssuers = [fusionAuthSettings.Issuer],
                ValidateIssuerSigningKey = true,
                IssuerSigningKey = new SymmetricSecurityKey(publicKeyBytes)
            };
        });

    services.AddAuthorization(options => { });
}

However, I'm encountering two unexpected scenarios:

1. The JWT validation succeeds regardless of the value I set for IssuerSigningPublicKey.
2. Even when using the correct public key from FusionAuth, JWTs signed with different keys are still validated successfully.

It seems like the signature validation isn't working as expected.

Has anyone else encountered similar issues? Could there be a configuration problem in FusionAuth or my .NET application? Any guidance or suggestions for troubleshooting would be greatly appreciated.

Thanks in advance!

We need to pass the token in the API header as Authorization: Bearer<token> But what is the process so that I can validate the endpoint with the valid token if the token is invalid or does not have the required roles or scope then I should get 401 else I should be able to access the API successfully.

Once you have a token in your API, you can validate it in two different ways. But it's worth noting that to validate the token, you must validate the signature and then the claims.

First option: use a library to validate the signature. Most languages have options. For java, you can use fusionauth-jwt, the readme has sample code.

Second option: use the validate API. You could use the FusionAuth client library to make this call if you'd like.

The first means you have to pick a library. The second means you have to make a network call.

Either way, after you validate the signature, you need to check the claims (issuer, audience, expiration, custom claims) to make sure they are what you expect.

Here's more about how to consume a JWT.

I'm not sure what you mean? Are you talking about the JWT generated for a login event?

Without it we get the error:

Description inside setRelaxVerificationKeyValidation :

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

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.

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:

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:

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/

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.

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.

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/

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

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.