Each JWT goes through this process within the gateway (option 1), which essentially causes the
sub field to be transformed into an internal representation of the JWT holder, and then policies, ACLs and rate limits are hung off that identity instead of the JWT. This allows us to track an identity (the underlying user) across JWT refreshes.
Since there is an internal token that gets generated to identify the user, that token's various session options can be used to manage the user, e.g. to block them across JWTs. A special case with JWT and OIDC is that this internal token ID is then added to this token as metadata so that it can be retrieved / audited later.
To do this, you need to get an idea of what this internal token is, to do so, you can use the global header injector, and injecting the meta_data associated with the underlying token into the headers list as something you can trap / log.
The specific key for this JWT internal token ID is:
$tyk_meta.TykJWTSessionID, by adding this as a header value, you can trap / log the offending token ID, and then use the Dashboard REST API (viz. "Get a specific key") to modify the session object, in this case you want to set the
is_insactive flag to
PUT this token data back into the dashboard, the JWT will be blocked.