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

Auto-configure Reactive/OAuth2AuthorizedClientManager @Bean #18195

Closed
jgrandja opened this issue Sep 10, 2019 · 2 comments
Closed

Auto-configure Reactive/OAuth2AuthorizedClientManager @Bean #18195

jgrandja opened this issue Sep 10, 2019 · 2 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@jgrandja
Copy link

The release of Spring Security 5.2.0.RC1 introduced the new interfaces OAuth2AuthorizedClientManager and OAuth2AuthorizedClientProvider, which provide core OAuth 2.0 Client features around realizing Authorization Grant's and the management of OAuth2AuthorizedClient's. The reactive counterpart is ReactiveOAuth2AuthorizedClientManager and ReactiveOAuth2AuthorizedClientProvider.

Given this, it would be ideal if Boot could auto-configure the default implementations as @Bean's.

Here is a sample configuration for Servlet and Reactive.

For additional details around these new interfaces please see this comment.

@mbhave
Copy link
Contributor

mbhave commented Sep 25, 2019

@jgrandja and I discussed this today. I'm not convinced that we should add a OAuth2AuthorizedClientManager to Boot's auto-config, the main reasons being:

  • ServletOAuth2AuthorizedClientExchangeFilterFunction and ServerOAuth2AuthorizedClientExchangeFilterFunction are already configured to use a DefaultOAuth2AuthorizedClientManager (if one isn't provided using the new constructor). This bean wouldn't provide anything additional if WebClient is used.
  • Most users will not need all the grant types configured in the sample and will most likely provide their own OAuth2AuthorizedClientManager.
  • Configuring a DefaultOAuth2AuthorizedClientManager for users who need it is straightforward and will avoid an unused bean in the context for cases that do not need it.

Let's see what the rest of the team and Rob think.

/cc @rwinch

@philwebb
Copy link
Member

I think we're in general agreement to leave this out for now. If there's any comments to contrary we can reopen the issue.

@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

4 participants