Provide client adaptors for common OAuth 2.0 Providers
See original GitHub issueThere are OAuth 2.0 Providers that are not spec-compliant making it difficult for user’s to integrate with using oauth2Login()
.
For example, LinkedIn does not return the token_type
parameter in the Token Response even though it is required as per spec. However, Spring Security 5.1 allows you to customize the Token Response to workaround this issue.
This is just one example, but there are other OAuth 2.0 provider’s that are either non-compliant or require custom/additional parameters and/or headers to make oauth2Login()
work.
We should consider adding out-of-the-box adaptors (connectors) for common OAuth 2.0 providers that are non-compliant. These adaptors would come with pre-configured properties (similar to CommonOAuth2Provider
) as well with configured components required by oauth2Login()
, for example, OAuth2AccessTokenResponseClient
, OAuth2UserService
, etc.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:8 (3 by maintainers)
@jgranda I’ll have a try configuring aws cognito now that the userinfo endpoint has been added to their support. I initially had difficult because I had to map values directly out of the ID token in to the user oidc user profile and prevent the user info call. I’ll check this is complaint now that the endpoint has been added
It would be great if the client adapters can be generalized in such a way that it is possible to package them in a .jar and have them be found automatically by spring security. I am thinking of a user experience similar to Spring Boot
@ConfigurationProperties
. Such an approach would make it possible to ship jars likeWhile it would be nice to have a something in spring security that out of the box includes all the config settings of all the major social networks. Many users will have internally deployed corporate OAuth2 or OIDC providers so a simple way to package
my-corporate-spring-security-login.jar
is going to reduce developer friction.