Support verifying access tokens provided from Client Credential Flow or Resource Owner Password Flow

[miner46er]

Currently there is no way to verify a standalone access token provided from other flows aside from normal (authorization code) flow since the available verifier is only for ID Token or when you have an ID Token from the access token.

A way to reuse the logic for verifying id token signature using the JWKS from the oidc provider would be preferable. Otherwise people using flows aside from normal flow would need to re-implement the token signature checking themselves.

[ericchiang]

Thanks for opening this issue. What are the specs that define those tokens? What providers return them?

[miner46er]

For example For Client Credential Flow defined in RFC 6749 a client would authenticate with the OIDC compliant authorization server and would return an access token with the same format as the other flows. Since this access token is the one sent to the resource owner rather than an id token, then this access token must be verified too right? The same as verifying id tokens. We can't trust just any access token sent by any client since it is generated and sent directly to the client rather than through the resource owner.

What I mean by provider in my original post is the oidc.Provider one. This Client Credential access tokens are supported by many providers such as Keycloak, Jetbrains Hub, 0Auth, etc.

[ericchiang]

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

https://datatracker.ietf.org/doc/html/rfc6749#section-1.4

(emphasis my own)

It doesn't seem appropriate to assume that the access token is a JWT or any other format, and probably not correct for go-oidc to parse or verify one?

[miner46er]

I see... I guess the only way to verify access token according to the standard is via token introspection endoint or else need to be handled on a per-provider basis huh. Either way that would be outside the scope of this package I suppose.

[ericchiang]

Yeah, I agree. If you need this package to provide access to the JWKs that's based on a spec or recommendations from a popular provider, please reopen!