Set Up Social Login with django-allauth

Users hate filling out registration forms. Every extra field is a chance for them to leave. Social login removes that friction in one click.

django-allauth makes social authentication straightforward. It supports over 100 providers, handles OAuth flows, and links social accounts to local users.

This guide walks through the full setup. You will configure Google and GitHub, wire up the callback URLs, and test the complete login flow.

How Social Login Works

Social login uses the OAuth 2.0 protocol. Your app redirects the user to the provider, the provider asks for permission, and then it sends the user back with a code.

Your app exchanges that code for an access token. The token grants access to the user's profile data, like name and email address.

django-allauth handles every step of that handshake. You configure credentials once, and the package manages redirects, token exchange, and account creation.

When a new user signs in with a provider, allauth creates a local user record automatically. Returning users are matched by their provider ID or email address.

If you have not installed the package yet, start with this guide on how to install django-allauth first. Then return here for the provider setup.

Prerequisites

Before configuring providers, confirm your environment meets these requirements.

• django-allauth installed with the [socialaccount] extra
• django.contrib.sites added to INSTALLED_APPS
• SITE_ID = 1 set in your settings file
• allauth URLs included in your project's urls.py
• Database migrations applied successfully

You also need developer accounts with each provider you plan to enable. Google and GitHub both offer free developer consoles.

Registering a Google OAuth App

Google is the most common social provider. Start by opening the Google Cloud Console and creating a new project.

Navigate to the Credentials section and create an OAuth 2.0 Client ID. Choose "Web application" as the application type.

Add the authorized redirect URI. This must match the callback URL that django-allauth uses.

 # For local development http://127.0.0.1:8000/accounts/google/login/callback/ # For production https://yourdomain.com/accounts/google/login/callback/ 

Copy the generated client ID and client secret. You will paste them into your Django settings next.

The trailing slash matters. A mismatch between the registered URI and the actual callback causes a redirect_uri_mismatch error from Google.

Registering a GitHub OAuth App

GitHub follows a similar process. Open the Developer Settings page in your GitHub account and create a new OAuth App.

Fill in the application name and homepage URL. Then set the authorization callback URL.

 # For local development http://127.0.0.1:8000/accounts/github/login/callback/ # For production https://yourdomain.com/accounts/github/login/callback/ 

GitHub issues a client ID and a client secret. Treat the secret like a password. Never commit it to version control.

GitHub also allows you to request specific scopes. The default user scope returns basic profile data and a verified email.

Configuring Providers in Settings

Add the provider credentials to your settings.py file. Load secrets from environment variables so they stay out of your repository.

 # settings.py import os SOCIALACCOUNT_PROVIDERS = { "google": { "APP": { "client_id": os.environ.get("GOOGLE_CLIENT_ID"), "secret": os.environ.get("GOOGLE_CLIENT_SECRET"), "key": "", }, "SCOPE": ["profile", "email"], "AUTH_PARAMS": {"access_type": "online"}, }, "github": { "APP": { "client_id": os.environ.get("GITHUB_CLIENT_ID"), "secret": os.environ.get("GITHUB_CLIENT_SECRET"), "key": "", }, "SCOPE": ["user", "user:email"], }, } 

The APP dictionary holds the credentials for each provider. The SCOPE list defines what user data your app can access.

For Google, the access_type parameter controls whether you receive a refresh token. Set it to online unless you need offline access.

For GitHub, the user:email scope is important. Without it, GitHub may not return a verified email address, and account creation fails.

Registering the Provider in the Admin

django-allauth also supports database-stored credentials through the Django admin. This is useful for multi-tenant apps or when you want to change credentials without redeploying.

Open the admin at /admin/ and navigate to Social applications. Click Add and fill in the fields.

Select the provider, enter the client ID and secret, and choose the site. The sites field must include your site or the provider login will not appear.

Credentials in settings.py take precedence over database entries. Pick one approach and stay consistent.

Adding Login Buttons to Templates

django-allauth provides template tags for rendering provider links. Load the tag library first, then use the provider_login_url tag.

 {% load socialaccount %} 
Continue with GoogleContinue with GitHub

The provider_login_url tag generates the correct OAuth redirect URL. It handles the state parameter and callback path automatically.

Place these buttons on your login and signup pages. Keep the design consistent with the rest of your site.

If you are building an API alongside your web app, you can reuse the same authentication flow. Check these Django Rest Framework best practices for scalable APIs to keep the backend consistent.

Handling the Callback Flow

When a user clicks a login button, allauth redirects them to the provider. After they approve access, the provider sends them back with a code.

allauth exchanges that code for an access token, fetches the profile, and creates or updates the local user record.

You can hook into this process with signals. Use the user_signed_up signal to run custom logic after a new social signup.

 # signals.py from django.dispatch import receiver from allauth.account.signals import user_signed_up @receiver(user_signed_up) def handle_new_signup(request, user, **kwargs): """Assign a default group to new social users.""" from django.contrib.auth.models import Group default_group, _ = Group.objects.get_or_create(name="Members") user.groups.add(default_group) 

The user_signed_up signal fires once when a new user is created through any login method. This is the right place for welcome emails, default roles, or profile setup.

Connect the signal in your app's apps.py ready method so it registers at startup.

Customizing Account Settings

django-allauth exposes many settings through ACCOUNT_* keys. Adjust them to match your application's requirements.

 # settings.py # Require email verification before login ACCOUNT_EMAIL_VERIFICATION = "mandatory" # Allow login with email instead of username ACCOUNT_AUTHENTICATION_METHOD = "email" ACCOUNT_EMAIL_REQUIRED = True # Skip the username field entirely ACCOUNT_USERNAME_REQUIRED = False # Automatically connect social accounts to existing users with the same email SOCIALACCOUNT_EMAIL_AUTHENTICATION = True SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True 

The ACCOUNT_EMAIL_VERIFICATION setting controls whether users must confirm their email before signing in. Use mandatory for apps that need verified identities.

The SOCIALACCOUNT_EMAIL_AUTHENTICATION setting lets existing users link a social account by matching email addresses. This prevents duplicate accounts.

Enable this only when you trust the provider to return verified emails. Both Google and GitHub mark emails as verified when appropriate.

Testing the Login Flow

Start the development server and open the login page in your browser.

 python manage.py runserver 

Navigate to http://127.0.0.1:8000/accounts/login/. You should see the social login buttons alongside the standard form.

Click the Google button. You are redirected to Google's consent screen. After approving, you land back on your site, logged in.

Check the database to confirm a new user was created.

 python manage.py shell >>> from django.contrib.auth import get_user_model >>> User = get_user_model() >>> User.objects.last().email '[email protected]' 

The get_user_model() function returns your project's user model, whether it is the default or a custom one.

Also verify the social account record exists.

 >>> from allauth.socialaccount.models import SocialAccount >>> SocialAccount.objects.last().provider 'google' 

If both records exist, the login flow is working correctly.

Common Setup Problems

Problem: "redirect_uri_mismatch" from Google

The callback URL registered in the Google Console does not match what allauth sends. Check for trailing slashes, http versus https, and the exact domain.

Problem: Provider button does not appear

The social application is not registered for the correct site. Open the admin and make sure the sites field includes your current site.

Problem: "Social network login failure" error

Usually caused by a wrong client secret or a missing scope. Double-check the credentials in your environment variables.

Problem: GitHub returns no email address

Add the user:email scope to the provider configuration. Without it, GitHub hides private emails and account creation fails.

Problem: Duplicate accounts for the same user

Enable email-based account linking in your settings. Then a user who signs in with Google and later GitHub links both to one local account.

Problem: Local development callback fails

Google accepts 127.0.0.1 but not always localhost. Use the IP address in both the console and your browser.

Best Practices

Store secrets in environment variables. Never commit client IDs or secrets to source control.

Use HTTPS in production. Most providers reject callbacks over plain HTTP outside localhost.

Register both development and production callbacks. Add both URIs to the provider console so you can test locally without editing settings.

Enable email verification for sensitive apps. It prevents someone from creating an account with an email they do not own.

Log social login failures. OAuth errors are cryptic. Store the response body so you can debug later.

Test each provider separately. Add one provider, verify the flow, then add the next. Debugging two broken providers at once is painful.

If you also expose filterable endpoints in your app, pair this authentication setup with a clean data layer. This guide on how to filter QuerySets with django-filter shows how to keep list views fast and predictable.

When you are ready to ship, review how to deploy a Django app with Fabric to automate the release and keep your credentials safe on the server.

Conclusion

Setting up social login with django-allauth takes some configuration, but each step is small. Register an OAuth app, paste the credentials into settings, and add login buttons to your templates.

Start with one provider. Test the full flow in development. Then add more providers one at a time.

Customize the account settings to match your app's requirements. Enable email verification for sensitive systems. Add signals to run logic on new signups.

With social login in place, your registration form becomes a single click. Users get in faster, and your conversion rate reflects it.