django-allauth: Linking multiple social accounts to a single user django-allauth: Linking multiple social accounts to a single user django django

django-allauth: Linking multiple social accounts to a single user


If your user is already logged in, I've successfully connected another account using the tag provider_login_url and setting the attribute process="connect". Here is the code snippet to put in a block displayed for authenticated users:

{% load socialaccount %}<p><a href="{% provider_login_url "facebook" process="connect" %}">Connect a facebook account</a></p><p><a href="{% provider_login_url "google" process="connect" %}">Connect a Google account</a></p>

Set SOCIALACCOUNT_QUERY_EMAIL=True and don't forget to ask for the email in the scope of your providers:

SOCIALACCOUNT_PROVIDERS = \    {'facebook':         {'SCOPE': ['email', ],          'AUTH_PARAMS': {'auth_type': 'reauthenticate'},          'METHOD': 'oauth2',          'LOCALE_FUNC': lambda request: 'pt_BR'},     'google':         {'SCOPE': ['https://www.googleapis.com/auth/userinfo.profile',                    'email'],          'AUTH_PARAMS': {'access_type': 'online'}         },}

I also want to know if it is possible to automatically associate a account using the email address. I can see in the column "extra_data" of the socialaccount_socialaccount table that both Google and Facebook send a "verified_email": true. For me it would be enough to automatically associate the logins and a great usability enhancement.


Certainly there should be a way to do this without putting the onus on the user? Maybe by email addresses?

Be very very careful about how you do this. You may be opening a huge security hole. If you don't put some onus on the user and just auto-link accounts with the same email address you introduce the following attack vector:

  • Find user on your site, figure out their email address (often this is very easy)
  • Create account at one of your providers with my email
  • Verify email, add their email, delete mine (it only takes one of your providers to not do the full corner cases for this hole to open)
  • 'Signup' for your service with my new lax-provider account
  • Get automatched to intial user, get access to their account

You can take steps to reduce this risk, but even if all providers require email confirmation now, any slip-up in the 3rd party teams would then open this hole in your security.

Maybe for what you're doing the risk is merited, just please be careful. A bit of onus on the user is probably not the worst thing.

I've seen flows where it suggests an auto-match, then asks you for your password or to re-authenticate with one of the original providers to add the new account to your original account. These wouldn't have the same potential to exploit, but have some brain-f*ck level corner cases and UI complications.