Trix's OpenID Connect (OIDC) support is focused around one provider (Dataporten), but it would be good to make it provider agnostic so that we can either switch to another provider if-need-be or run multiple providers simultaneously.
We should:
remove hard references to Dataporten as login provider in the code :heavy_check_mark:
move login provider config from SocialApp (Django Admin) to settings.py :heavy_check_mark:
allow multiple login providers in parallel :heavy_check_mark:
when more than one login provider is available, the users should be asked to choose :heavy_check_mark:
display the name of current login provider (if any) next to last login details on /user/ :heavy_check_mark:
TO-DOs
remove or fix (link back to origin?) burger menu on login provider selection page
find a less hacky solution for adding logout URLs and expected responses
translations for login provider selection page (#158)
Known issues
if you log in using an Allauth OpenID Connect provider you have used before, but with another login backend offered by that identify provider (IdP) you get stuck at /authenticate/allauth/3rdparty/signup/. I suspect the issue is that the Django user object is already associated with a SocialAccount from that provider, but that the response can't be overwritten the SocialAccount from the provider's other login backend.
Trix's OpenID Connect (OIDC) support is focused around one provider (Dataporten), but it would be good to make it provider agnostic so that we can either switch to another provider if-need-be or run multiple providers simultaneously.
We should:
settings.py:heavy_check_mark:/user/:heavy_check_mark:TO-DOs
Known issues
/authenticate/allauth/3rdparty/signup/. I suspect the issue is that the Django user object is already associated with a SocialAccount from that provider, but that the response can't be overwritten the SocialAccount from the provider's other login backend.