Opaque Token Support for Custom Parameters

[jzheaux]

Opaque Token Resource Server simplifies authorizing a Bearer Token request against an OAuth 2.0 /introspect endpoint.

However, it only sends the token request attribute, with no way to add custom parameters to the request.

It would be nice if the application could easily pass other parameters to the /introspect endpoint.

Note that this ticket is restricted to custom parameters that don't come from the original Bearer token request itself. For example, this ticket isn't trying to solve how to take a custom header or other aspect of the Bearer token request and pass that to /introspect. The reason is that that problem is trickier to solve and it will likely be better to address at another time.

One way to solve this would be to add a setter that takes a Converter<String, RequestEntity<?>>. The application could specify in this Converter what additional custom parameters are necessary.

[sayembd]

Hi @jzheaux, I would like to work on this issue.

[jzheaux]

@sayembd, it's yours!

[jzheaux]

@sayembd how is this coming along? Do you have any questions?

[sayembd]

@jzheaux I was familiarising myself with the relevant part of the code base as I was totally unfamiliar with it, and also the way converters are plugged in via configuration. Apologies for the delay.

If I haven't misunderstood anything from my investigation (after studying the DefaultClientCredentialsTokenResponseClient and the DefaultAuthorizationCodeTokenResponseClient), then this is what I need to do -

1. The only implementation of OAuth2TokenIntrospectionClient, the NimbusOAuth2TokenIntrospectionClient, gets a field of type Converter<String, RequestEntity<?>>
2. NimbusOAuth2TokenIntrospectionClient also gets a setter method for the field
3. The current request-building mechanism of NimbusOAuth2TokenIntrospectionClient gets exported into a default implementation of Converter<String, RequestEntity<?>>, which is what we use to initialise the field.
4. Clients can then use OpaqueTokenConfigurer.introspectionClient(OAuth2TokenIntrospectionClient introspectionClient) to specify a NimbusOAuth2TokenIntrospectionClient instance, configured with a custom Converter<String, RequestEntity<?>>, and thus overriding the default one.

Would be great if you could confirm.

I was also curious to know why this setter wasn't on the interface itself (i.e., on OAuth2AccessTokenResponseClient), which would have forced all implementations to provide this custom conversion facility.

[jzheaux]

Correct on all points, @sayembd. Thanks for all your research.

which would have forced all implementations to provide this custom conversion facility.

Good question. It's not necessarily true that all implementations will be RestOperations-based, which is really the only circumstance where a setter like this would make sense. That makes setRequestEntityConverter an implementation detail that we don't want to expose in the interface.

[sayembd]

Hi @jzheaux, thanks for your prompt reply! I've just opened a PR: #6870.