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/