Add OIDC token introspection endpoint (RFC 7662) to Vault's OIDC identity provider

[siepkes]

Is your feature request related to a problem? Please describe.

I think (unless I'm missing something here) in it's current state it is very hard to securely use OpenBaos OIDC identity provider (ie. it's IDP) to protect an API such as a REST or gRPC endpoint.

When protecting an endpoint the endpoint will require the caller to use an access_token. The id_token is not really suited for this purpose. To keep it brief, reasons as to why this is are described in articles such as ID Token and Access Token: What's the Difference?.

So that means the endpoint will need to validate the access_token. This means the endpoint probably needs to know at least the following things:

• Is the token valid now? Has it been revoked?
• What is the intended audience of the token? Is this token intended to be used with this specific endpoint?
• What is the expiry time of the token? Is this token still valid and how long can we cache certain results?

Describe the solution you'd like

I would like for OpenBao to offer a OIDC token introspection endpoint (RFC 7662). The token introspection endpoint is an optional part of the OIDC spec but implemented by almost all IDP's (Keycloak, Hydra, etc.).

Describe alternatives you've considered

I've evaluated using the "token lookup" API (since OpenBao access_token's are actually OpenBao batch tokens). While that does tell if the token is valid and what the expiry time is there is no way to tell the intended audience of the token. Meaning that if a token gets stolen from service A there is no way for service B to validate if the token is actually valid for service B or only is only valid for service A.

OpenBao's OIDC UserInfo endpoint only offers additional information about the identity (name, email, etc.). It does not tell much about the token. At the most it tells if the token is valid when you call the endpoint. But there is no expiry time or intended audience information for example. Which makes sense since that's the job of the token introspection endpoint.

Explain any additional use-cases

While a optional piece of the OIDC spec a good chunk of applications will expect the token introspection endpoint to be callable. It will probably be a win for overall compatibility.

Additional context

• I initially created this feature request for Vault: Proposal: Add OIDC token introspection endpoint (RFC 7662) to Vault's OIDC identity provider hashicorp/vault#15659.
• It is related to my other proposal (Support refresh tokens in OpenBao's OIDC provider #186). I think both of these are needed if one wants to use OpenBao's OIDC identity provider if one implements a SPA, Mobile app, etc.