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.

@gokul-mahajan20

Can you add ----BEGIN to the JWKS certs?

You can use the user.create or the user.registration.create webhook to do something like this.

If you enable these webhooks and configure the transaction to require the webhook to succeed, then you simply need to return a non-200 status code from the webhook to cause FusionAuth to fail this create.

https://fusionauth.io/docs/v1/tech/events-webhooks/#tenant-settings
https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-create
https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-registration-create

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

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

Our validation takes in inverse approach. The setting is actually to require a non-alphanumeric character. So any character that is not alphabetic, or a digit, will satisfy this requirement.

There is not a fixed set of symbols as this would reduce the password entropy, which is generally a bad idea.

There are a few things to consider.

how long tokens live for what happens if permisssion are modified in FusionAuth but the protected resource still allows access? any performance worries due to a large number of accessToken validation calls being made by the protected resource.

With the first approach (validating the access token without communicating with FusionAuth) the holder of the token will be able to access your API as long as the token is valid (unless the API server communicates periodically with FusionAuth to check the validity). In addition, changes to user privileges won't take place until the JWT expires and the client retrieves a new access token using the refresh token.

With the second approach, if a token is revoked in FusionAuth (if for instance the user is disabled) the access is cut off immediately. The cost is that you're making an additional network call every time, which has a performance impact. Note that if you could use the userinfo endpoint instead of the token if you want updated user claims. The token endpoint isn't going to give you that information, just a yes/no depending on if the token is valid.

So it's hard to make a recommendation without knowing what the consequences of unauthorized access to your API or protected resource would be. It also would be helpful to know the expected traffic; if it is expected to be low, the performance impact of the second approach will be minimal.