JWTs Cannot Be Revoked: Once a JWT is issued, it remains valid until it expires. JWTs are decoupled authentication tokens, meaning they do not require continuous validation against a central authority. While OAuth2 includes a token introspection endpoint, it is only useful for access tokens and does not support JWT revocation. What the /oauth2/introspect Endpoint Does: This endpoint verifies whether an access token is valid based on its signature, expiration time, and format. It does not check whether a user’s account has been locked or disabled. Impact of a Locked Account on JWTs: If a user’s account is locked, they will not be able to obtain a new access token. However, any previously issued JWTs will continue to be valid until they expire, unless you implement additional measures. How to Handle JWT Revocation:
Since OAuth2 does not include JWT revocation natively, you can implement one of the following approaches: Use Short Token Lifetimes: Issue JWTs with short expiration times and rely on refresh tokens for continued access. Leverage Webhooks for Denylisting: Use FusionAuth’s event system to notify services when a user is locked or a token should no longer be valid. Services can then maintain a blacklist of invalidated JWTs.

For more details, refer to:

Revoking JWTs in FusionAuth

Hiya,

There are currently no plans to support the full mTLS spec. We are discussing DPoP (tracking issue) internally.

However, depending on your needs, there may be a workaround.

Since the client credentials grant depends on Entities, you can leverage this to inject a client certificate hash into an access token obtained through the client credentials grant.

How this works at a high level:

Client Certificate Registration
During onboarding, your customer (e.g., a bank) registers their client certificate. A hashed value of that certificate is securely stored in FusionAuth (entity.data). The hashing process is outlined in the RFC. Client Credentials Request
When the bank requests an access token using the Client Credentials grant, a FusionAuth Lambda is invoked before the JWT is signed. Augment Custom Claims
The Lambda code looks up the stored certificate hash and injects it as a claim in the JWT. For maximum compatibility with RFC 8705, it is recommended to add this hash to the cnf object in the JWT, like so: "cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" } Accessing the Resource Server or API
The customer presents both the access token and presents their client certificate when calling your API. Validation Flow
Your API: verifies the JWT signature computes a hash of the presented client certificate compares it to the x5t#S256 claim in the token Decision Logic
If the hashes match, the request is bound to the correct client and access is granted to the protected resource.

JWTs Cannot Be Revoked: Once a JWT is issued, it remains valid until it expires. JWTs are decoupled authentication tokens, meaning they do not require continuous validation against a central authority. While OAuth2 includes a token introspection endpoint, it is only useful for access tokens and does not support JWT revocation. What the /oauth2/introspect Endpoint Does: This endpoint verifies whether an access token is valid based on its signature, expiration time, and format. It does not check whether a user’s account has been locked or disabled. Impact of a Locked Account on JWTs: If a user’s account is locked, they will not be able to obtain a new access token. However, any previously issued JWTs will continue to be valid until they expire, unless you implement additional measures. How to Handle JWT Revocation:
Since OAuth2 does not include JWT revocation natively, you can implement one of the following approaches: Use Short Token Lifetimes: Issue JWTs with short expiration times and rely on refresh tokens for continued access. Leverage Webhooks for Denylisting: Use FusionAuth’s event system to notify services when a user is locked or a token should no longer be valid. Services can then maintain a blacklist of invalidated JWTs.

For more details, refer to:

Revoking JWTs in FusionAuth

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.

@seednextsrl you typically don't use the access token as a login password.

The access token is what you present to other applications as proof that someone has logged in.

There are a few FusionAuth APIs you can call and present the access token as a means of authentication. They are marked with a little blue person.

Here's more about API authentication: https://fusionauth.io/docs/v1/tech/apis/authentication

Here's an example of an API which uses a JWT to authenticate: https://fusionauth.io/docs/v1/tech/apis/users#retrieve-a-user (scroll to the "Retrieve a User using a JWT" section).

Also, if you are interested in building a more secure JWT, this article may be of interest: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt/

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/