Optionally disable remote introspection for JWT/non-opaque tokens

[sbia...@redhat.com]

Hi Paulo, All

Awhile back we were discussing at some length :-) the cooperation between refreshing JWK keys (via the registered missing JWK handler) and the remote introspection requests.

Here is how it works now when a non-opaque JWT token needs to be verified and no local matching JWK key is found:

1. Try to find a matching local JWK key

2. If it is not available and a missing JWK key has been registered - let it know about it (in Quarkus we ask Vert.x to refresh the set and time-restrict it, i.e, no more JWK set refresh requests during the next configured number of minutes)

3. Run the introspection request since 2. is async

So when we have a situation where OIDC server rotates the JWK key set, a given user request will see 2 background remote requests - one JWK refresh request, one - introspection request. I recall we talked a lot about it but eventually I realized that since, in production, the key rotation is likely to be irregular and also rare enough, having a cost of 2 (instead of 1) remote operations once per every few months or so is negligible and is not worth worrying about :-)

We've had another Quarkus user raising this issue (of 2 remote requests) where I had to clarify it.

However, what is very reasonable IMHO is for the users who work with JWT tokens and expect them to be verified locally with the JWK key set only (refreshed at some rotation intervals) is for them expect that no introspection calls will be happening.

This applies not only to the token veriification, we have a user request to cache the userinfo and - for opaque tokens - introspection responses. I.e, it is important for some productions to avoid a remote verification/etc call per every token.

The problem with the current JWT verification flow, is that one can very easily 'provoke' the remote introspection calls by automating the process of forwarding a randomized set of strings with 3 parts where the 1st part would be a base64-url encoded sequence with some random 'kid's - our JWK refresh handler will block N number of refresh requests in such cases during the configured period of time, but there is nothing we can do to stop the remote introspection calls.

I'd like to make sure that those Quarkus users who know they work with JWT which should always be verified with the JWK, be able to block the remote introspection.

I'd like to propose to keep it simple and add a configuration property (name to be decided) which, if enabled, will tell Vert.x Auth OAuth2 to ignore an introspection call when it detected that it is not an opaque token (and maybe a local JWK set is not empty)

Paulo, what do you think ?

Cheers, Sergey

[sbia...@redhat.com]

This is a Quarkus issue:

https://github.com/quarkusio/quarkus/issues/12984

Cheers, Sergey

[Paulo Lopes]

The current way to disable the introspection (is to set the "introspection path" in the config to "null"). If we don't know where to introspect then the processing stops right away for opaque tokens.