-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Provide customization hooks for reactive oauth2 token client requests #9171
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
Comments
Barring any concerns over the proposed solution, I can put a PR together with the above changes. |
@jjstreet Closing this as duplicate of #8612 |
I read through #8612 and this is totally a duplicate of that. I didn't search thoroughly enough it seems. I am in the same situation as #8612. I need to use client registration id to look up a resource value and apply to the request. Much like Auth0 requires additional fields, so does active directory. In my example I show the token client not being reusable for different registrations, but it would be by passing along a repository of resource registrations (like I plan to). I left it out of the example for the sake of brevity. I should have left it in. Just so I understand your recommended approach:
@Override
public Mono<OAuth2AccessTokenResponse> getTokenResponse(OAuth2ClientCredentialsGrantRequest authorizationGrantRequest) {
return Mono.subscriberContext()
.map(ctx -> {
ctx.put(AdfsResourceReactorContext.RESOURCE, "resource");
return ctx;
})
.flatMap(ctx -> delegate.getTokenResponse(authorizationGrantRequest));
} Not sure if this correct, but I can read up on reactor context to understand it a bit more.
This is where I am now struggling to understand your recommended approach.
Pretty straight forward here. I can do that. |
Yes. Assuming you want to modify the default token request for a private ReactiveOAuth2AccessTokenResponseClient<OAuth2ClientCredentialsGrantRequest> clientCredentialsTokenResponseClient() {
WebClient webClient = WebClient.builder().filter(clientCredentialsTokenRequestProcessor()).build();
WebClientReactiveClientCredentialsTokenResponseClient clientCredentialsTokenResponseClient =
new WebClientReactiveClientCredentialsTokenResponseClient();
clientCredentialsTokenResponseClient.setWebClient(webClient);
return clientCredentialsTokenResponseClient;
}
private static ExchangeFilterFunction clientCredentialsTokenRequestProcessor() {
return ExchangeFilterFunction.ofRequestProcessor(request ->
Mono.just(ClientRequest.from(request)
.body(((BodyInserters.FormInserter<String>) request.body())
.with("resource", "resource1"))
.build()
)
);
} |
The casting is kind of a bummer, but I'm definitely gonna give this a shot and see how it works. Thanks for the followup advice. Really appreciate it. |
Uh oh!
There was an error while loading. Please reload this page.
Enhancement
AbstractWebClientReactiveOAuth2AccessTokenResponseClient
by class outside the package.BodyInserters.FormInserter<String> populateTokenRequestBody(T grantRequest, BodyInserters.FormInserter<String> body)
by classes outside the package.OR
Provide some other way to customize the request made by token response clients.
Context
In servlet, we have the ability to provide a
Converter
such asConverter<OAuth2ClientCredentialsGrantRequest, RequestEntity<?>>
to customize the creation of the request ultimately sent to an authorization server for a token.Such customization is not yet available in the Reactive arena. Token response clients are all abstracted from a package-protected abstract class. There is no method available to extend in a way that allows me to do the same as above. All potential methods are located in the abstract class and are themselves package-private.
This customization is especially useful when dealing with different OAuth2 authorization servers that want additional data. One such provider is Active Directory where you may provide a
resource
field in the request.Looking at the token response clients, I see there is no request object to customize, so the next best option would be customizing the token client. This looks to be possible if classes were made extensible. This allow us to customize in a pretty straightforward way:
The text was updated successfully, but these errors were encountered: