how does OIDC /revoke work for JWT access_token when JWT validation is mostly stateless

AS I understand JWT validation involves JWKS Uri providing public keys to ensure the 3rd part of the access_token (JWT token) passed as a Authorization Bearer token is not tampered i.e. issuer is same and then further it can validate expiration and additional claims verification against as supplied for the validator.

If someone were to call /revoke - the revocation_endpoint then according to the specs https://datatracker.ietf.org/doc/html/rfc7009 the OIDC providers are to "invalidate" the access token.

So how does it work with the above token validation ?

Am I missing any more validation steps e.g. that the validators also consult the OIDC providers for the tokens that are in flight ?

Solution

The RFC you quote states:

Implementations MUST support the revocation of refresh tokens and
SHOULD support the revocation of access tokens (see Implementation
Note).

So, the first answer is, it is not required that the revocation endpoint do anything with an access token. An unsupported_token_type error code is defined for a system which can only revoke refresh tokens.

Refresh tokens are much easier to check against some central state, since they should only be validated by a central authorization server, not a distributed set of resource servers.

The Implementation Note (section 3) explains:

OAuth 2.0 allows deployment flexibility with respect to the style of
access tokens. The access tokens may be self-contained ... A system
design may, however, instead use access tokens that are handles
referring to authorization data stored at the authorization server.

It then points out the same thing you have: if the token is self-contained, revocation is not trivial. It suggests:

In the former case, some (currently non-standardized) backend
interaction between the authorization server and the resource server
may be used when immediate access token revocation is desired.

So, the second answer is "there is no standard for how it works".

However, we can speculate on some designs for this "backend interaction":

The authorization server could have a means of contacting all resource servers, alerting them to the revocation. This would then be added to a local cache, which was checked whenever a token was presented. This cache can "forget" any tokens once they reach their expiry date, so will not grow indefinitely.
The same local cache could be used passively: the authorization server could publish a list of revoked (but not yet expired) tokens, and the resource server periodically fetch it into their local cache.
Alternatively, the network architecture might allow the cache to be shared, and a check made on every request. Assuming that the revocation list is expected to be a small subset of issued tokens, this could still be more efficient than a fully stateful authorization server.

A further optimisation is suggested in the RFC:

Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization grant.

This means that the revocation list does not need to contain any tokens at all, a revocation could be for a whole class of tokens at once, reducing the amount of data to store further.