OAuth 2.0 Token Introspection (RFC 7662)

[jeroenvervaeke]

I'm in the need for OAuth 2.0 token introspection (RFC 7662).

This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.

I want to implement this feature but I'm not sure if you guys feel like it belongs here. Since the readme states that this library is an strongly-typed implementation of OAuth2 (RFC 6749).
I also realize there is a library available already (tokkit), but personally I feel like it would be more convenient to have all these features in one library.

What do you guys think. Should this RFC be added to this library? Should it be added by default? Should this feature be added behind a feature flag etc?

Thanks in advance!

[ramosbugs]

Hey, this seems like a reasonable feature to incorporate into the library. There's some precedent for including closely-related RFCs like PKCE directly into this crate.

I think the inclusion criteria should be that:

1. the functionality is of interest to many users of this crate, and
2. it doesn't significantly increase the complexity of the crate.

In this case, I think both criteria apply, so I'd be open to incorporating it. By contrast, something like OpenID Connect is far more complex, so I put that into a separate crate (https://github.com/ramosbugs/openidconnect-rs) built on top of this one.

For clarity, I think it makes sense to incorporate the token introspection client request/response from that RFC, but not any functionality that directly introspects into JWTs or anything like that.

From glancing at the RFC, I think we can incorporate this into the crate most cleanly by:

1. adding a Client::set_introspection_url method for setting the URL (which can be leveraged by multiple subsequent introspection calls, similar to the pattern for setting the auth_url and token_url in Client::new, but without introducing a breaking change to that method)
2. adding a Client::introspect_token method that follows the same pattern as exchange_code, etc. (i.e., it should return an IntrospectionRequest struct).
3. defining a strongly-typed IntrospectionResponse struct leveraging the NewType pattern where appropriate
4. adding appropriate unit tests

[jeroenvervaeke]

I finally find some time to implement this and create a PR (See #117)
I've tested everything against a local keycloak identity server and added multiple unit tests.

It would be nice to run rustfmt against the entire library after this PR is completed (in a separate PR), that would make the code more consistent and easier to read.