social-core
social-core copied to clipboard
python-social-auth
Generic OAuth2 backend
Expected behaviour
I would like to be able to use an OAuth2 service without having to make a custom backend python file just in order to set the URLs.
Actual behaviour
It seems that you cannot instantiate BaseOAuth2 directly and there is no way to configure the authorisation and token and userinfo URLs anyway. Please correct me if I'm wrong. But it looks like every single service that uses OAuth2 has had to create a subclass in social_core/backends/. This is particularly problematic for me as I then need to rebuild docker containers just to get this custom subclass in.
Any other comments?
This does not seem to be a problem for SAML or OpenID, just for OAuth2.
https://github.com/python-social-auth/social-core/pull/669 does this for Open ID Connect. The problem with OAuth2 is that there is no standard way of getting user details and that is what every subclass of BaseOAuth2 implements...
It seems that this just could be passed a mapping array, anyway in the meantime I've submitted a PR for uffd support with the URLs configured through config.
Other software manages to do generic oauth2 with some restrictions. See for example gitlab: https://docs.gitlab.com/ee/integration/oauth2_generic.html That's enough for most use case and for those where it isn't you can still fork.
It's much easier to just enter urls and field mappings than to having to fork the whole library and get a packaging infrastructur as well as the deployment side by side to your distro's running.
#669 does this for Open ID Connect. The problem with OAuth2 is that there is no standard way of getting user details and that is what every subclass of BaseOAuth2 implements...
I completely agree.
It's much easier to just enter urls and field mappings than to having to fork the whole library and get a packaging infrastructur as well as the deployment side by side to your distro's running.
On the other side, it is much easier to write code for a single OAuth2 service, than a generic one which can be configured in a way you describe. Maybe that's why nobody has contributed it so far. I'm not saying it cannot be implemented, but somebody has to do that.
