Access token validation

[alex88]

Is your feature request related to a problem? Please describe.
I'm trying to use the library not only for the first login but also to keep the access token in a cookie and then verify it on every request. However it seems there are only methods to verify the id token (which I don't need) and not the access token give a provider.

Describe the solution you'd like
Have a function that given an access token, validates it against the provider keys

Describe alternatives you've considered
Use the jwt package to verify it but the signing keys are private variables on the oauth config

[livio-a]

Hi @alex88

First of all, thanks for the issue.

I'm not completely sure if you want to validate the access_token on the client or resource server (API) side.
For JWT access_token there's now finally a RFC: https://www.rfc-editor.org/rfc/rfc9068.html
I believe this would be handy for clients or resource servers.

We have not yet decided whether and, if so, when we will implement it.
Would you consider implementing it?

In the meantime there are already possibilities you could use (regardless if the access_token is a JWT or an opaque string)

• From a client perspective:
  There's the VerifyAccessToken which will validate it using the at_hash from the id_token:
  https://github.com/caos/oidc/blob/eb10752e485ced36bd996bcb290c6e617f5ea449/pkg/client/rp/verifier.go#L93
  From the token endpoint response you would also get the Expiry of the access_token.
  And as the access_token might get revoked or otherwise invalidated at any time, I would simply send it to the resource server and handle a HTTP 401 response by reauthenticating the user (with a refresh_token or a new login flow)

• From a resource server (API) perspective:
  I'd use the introspection endpoint to validate the access_token. Given the access_token is a JWT, there would be the possibility to validate it directly as mentioned above.
  The advantage of using the introspection endpoint is, that you would be sure the token is still active and has not been revoked. For performance issues, there would also be the possibility to cache the introspection result for a given time, depending on the security needs of the api.

I hope I have been able to help you a little further.

[alex88]

Hi @livio-a, sorry for the delay..
My initial idea was to validate the access token in the resource server.
My use case was to build a custom auth proxy for grafana, this proxy would do the oauth part with this library and then after getting the access token I would have to validate and decode it and set appropriate grafana headers like user email/role etc.

Unfortunately I ended up not using this library because I've found an easier way to handle authentication without having to build a proxy layer.

Thank you a lot any way for your help!

[fforootd]

Closing this issue as it looks resolved/discussed.