Open misc-herrera opened 3 months ago
siepkes
commented
1 month ago I could be missing something but doesn't this simply "reverse" the problem? Because if you use a JWT you now have to check if the JWT hasn't been revoked?
I guess you could cache the result but the same is also true for the information retrieved of a token?
misc-herrera
commented
4 weeks ago Good point, thank you for thinking of that.
As I understand it, token revocation in OIDC is described in this OAuth2 standard:
Implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens (see Implementation Note).
See rfc7009.
So in the case that access tokens may be revoked as well, you are completely correct. But otherwise connecting to Vault would only be necessary client-side to refresh the access token with the refresh token.
And since these access tokens are short-lived, implementing revocation is not as crucial here, I think.
Is your feature request related to a problem? Please describe. When using Vault as an OIDC Provider in the case of a client application that wants to connect to an api server, the api server (as the resource server in this case) has to validate the access token for every api request.
Currently this validation can not happen on the resource server, instead a request to the vault api has to be made validating the access token (since it is a batch token which in its structure is opaque to the resource server).
This becomes problematic when a lot of api requests are made on different apis that all need to validate the access tokens via vault.
It also makes integration with common libraries for OpenID Connect difficult (e.g. authlib), since these assume access tokens to be Json Web tokens.
The ID Token already is a Json Web Token, just the access token is not.
Describe the solution you'd like I would like the access token to be a Json Web Token (JWT), that can be validated locally with the keys available at the jwks uri.
Describe alternatives you've considered Batch tokens can be validated by using the specific endpoint for batch token validation, which would lead to a lot of traffic on that vault endpoint.
Another alternative is the usage of an introspection endpoint, as requested in this PR. While solving some issues regarding token specificity for a specific service, this solution would pose the same problem of a lot of traffic on vault. An introspection endpoint would nevertheless be a useful addition to vault.
Explain any additional use-cases This would make the OIDC Provider feature much more usable and would facilitate integration with established OIDC libraries.
Additional context This issue is related to the feature request for refresh tokens, which would be another great integration to make Vault as an OIDC Provider even more usable and convenient.