Is your feature request related to a problem? Please describe.
When a JWT gets leaked, or when we would want to stop authorizing an authenticated JWT for some reason, there should be a way to invalidate the JWT. I understand that it is best practice to have JWTs with short expiry dates. However, I still see the benefit of this feature.
Describe the solution you'd like
Possible solutions:
The Ingress controller should be configured in such a way that could hold a blacklist of invalidated JWTs
authpolicy's oauth authentication_providers can be configured with not-before unix timestamp field, where it only authenticates JWTs with iat dates greater than the specified date in that not-before field. (see Keycloak docs)
authpolicy can have a deny_authorization_policies field, as opposed to authorization_policies, where the policy can deny access based on the claims. This way, we could deny access to leaked and authenticated JWTs at the authorization level, by specifying, for example the sub claim with the leaked sub value, and reissue a JWT to the related party with different sub
Describe alternatives you've considered
Using a new audience. JWTs with old audience would not authenticate.
Keep track of good JWT subs by providing a list of good subs in the authorization_policies field (keeping track of good subs and subsequently good JWTs might be against the JWT spirit, as it boasts of being a storage-less authentication mechanism)
Additional context
If I am missing a documentation to a preexisting feature that solves my issue, kindly guide me to the related documentation. Thank you!
Is your feature request related to a problem? Please describe. When a JWT gets leaked, or when we would want to stop authorizing an authenticated JWT for some reason, there should be a way to invalidate the JWT. I understand that it is best practice to have JWTs with short expiry dates. However, I still see the benefit of this feature.
Describe the solution you'd like Possible solutions:
authentication_providerscan be configured withnot-beforeunix timestamp field, where it only authenticates JWTs withiatdates greater than the specified date in thatnot-beforefield. (see Keycloak docs)deny_authorization_policiesfield, as opposed toauthorization_policies, where the policy can deny access based on the claims. This way, we could deny access to leaked and authenticated JWTs at the authorization level, by specifying, for example thesubclaim with the leakedsubvalue, and reissue a JWT to the related party with differentsubDescribe alternatives you've considered
subs by providing a list of goodsubs in theauthorization_policiesfield (keeping track of goodsubs and subsequently good JWTs might be against the JWT spirit, as it boasts of being a storage-less authentication mechanism)Additional context If I am missing a documentation to a preexisting feature that solves my issue, kindly guide me to the related documentation. Thank you!