Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opaque Token Support for Custom Parameters #6798

Closed
jzheaux opened this issue Apr 18, 2019 · 6 comments

Comments

@jzheaux
Copy link
Contributor

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 4, 2019

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

@jzheaux

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

@sayembd, it's yours!

@jzheaux

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

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

@sayembd

This comment has been minimized.

Copy link
Contributor

commented May 13, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

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 added a commit to sayembd/spring-security that referenced this issue May 13, 2019

Add custom parameters to token introspection requests
Added support for providing custom parameters to an OAuth 2.0 token
introspection request. This is done by explicitly instantiating a
NimbusOAuth2TokenIntrospectionClient instance and then setting a custom
Converter implementation.

Fixes spring-projectsgh-6798
@sayembd

This comment has been minimized.

Copy link
Contributor

commented May 13, 2019

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

sayembd added a commit to sayembd/spring-security that referenced this issue May 14, 2019

Add custom parameters to token introspection requests
Added support for providing custom parameters to an OAuth 2.0 token
introspection request. This is done by explicitly instantiating a
NimbusOAuth2TokenIntrospectionClient instance and then setting a custom
Converter implementation.

Fixes spring-projectsgh-6798

@jzheaux jzheaux closed this in 0bc60dc May 14, 2019

jzheaux added a commit that referenced this issue May 14, 2019

Polish OAuth2TokenIntrospectionClient
Placed URI.create in constructor so that the code doesn't do that
processing on each request. Also moved the construction helper methods
up by the constructor for added readability.

Issue: gh-6798

eleftherias added a commit to eleftherias/spring-security that referenced this issue May 14, 2019

Add custom parameters to token introspection requests
Added support for providing custom parameters to an OAuth 2.0 token
introspection request. This is done by explicitly instantiating a
NimbusOAuth2TokenIntrospectionClient instance and then setting a custom
Converter implementation.

Fixes spring-projectsgh-6798

eleftherias added a commit to eleftherias/spring-security that referenced this issue May 14, 2019

Polish OAuth2TokenIntrospectionClient
Placed URI.create in constructor so that the code doesn't do that
processing on each request. Also moved the construction helper methods
up by the constructor for added readability.

Issue: spring-projectsgh-6798
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.