Skip to main content

Configuration Methods

django-allauth supports two methods for configuring social providers:
  1. Settings-based: Define configuration in settings.py
  2. Database-based: Create SocialApp instances via Django admin
Avoid Mixing Methods: Don’t configure the same provider using both methods simultaneously, as this will cause a MultipleObjectsReturned exception.

Settings-Based Configuration

Define providers in your settings.py:

Benefits

  • Secrets managed in environment variables or secret management systems
  • Version controlled configuration (without secrets)
  • Simpler deployment and CI/CD workflows

Database-Based Configuration

Create SocialApp instances via Django admin at /admin/socialaccount/socialapp/:
  1. Navigate to Social applications
  2. Click “Add social application”
  3. Fill in the form:
    • Provider: Select from dropdown
    • Name: Display name (your choice)
    • Client id: From provider’s developer console
    • Secret key: From provider’s developer console
    • Key: Usually left blank
    • Sites: Select applicable sites (if using django.contrib.sites)
    • Settings: JSON field for provider-specific settings

Benefits

  • No code changes needed to update credentials
  • Multi-tenant support via Django sites framework
  • Non-technical staff can manage configurations
Security Consideration: Database-based configuration stores secrets in your database. Ensure proper database security, encryption at rest, and access controls.

Global Settings

All settings are prefixed with SOCIALACCOUNT_ in your settings.py.

SOCIALACCOUNT_ADAPTER

Default: "allauth.socialaccount.adapter.DefaultSocialAccountAdapter" Specifies the adapter class for customizing behavior.

SOCIALACCOUNT_AUTO_SIGNUP

Default: True Attempt to bypass the signup form by using fields retrieved from the social provider (username, email). If a conflict arises (duplicate email), the signup form still appears.

SOCIALACCOUNT_EMAIL_AUTHENTICATION

Default: False When enabled, users logging in via a social provider with a verified email that matches an existing local account will be logged into that local account, even without a prior connection.
Security Risk: Only enable for fully trusted providers. An untrustworthy provider could fabricate social account data to access any local account.

SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT

Default: False When email authentication is applied, controls whether the social account is automatically connected to the local account.
  • False: Local account remains unchanged; future logins require email authentication each time
  • True: Social account is connected; future logins work even if the email changes

SOCIALACCOUNT_EMAIL_VERIFICATION

Default: ACCOUNT_EMAIL_VERIFICATION Email verification method for social accounts. Inherits from account settings by default.

SOCIALACCOUNT_EMAIL_REQUIRED

Default: "email*" in ACCOUNT_SIGNUP_FIELDS Require email address when signing up with a social account.

SOCIALACCOUNT_QUERY_EMAIL

Default: Same as SOCIALACCOUNT_EMAIL_REQUIRED Request email address from the provider (e.g., using OpenID AX or OAuth scopes).

SOCIALACCOUNT_FORMS

Default:
Override default forms.

SOCIALACCOUNT_LOGIN_ON_GET

Default: False Controls whether social login endpoints (e.g., /accounts/google/login/) accept GET requests to initiate authentication.
Security Best Practice: Keep this False to require POST requests and prevent CSRF attacks.

SOCIALACCOUNT_STORE_TOKENS

Default: False Store OAuth access tokens in the database. Required if you need to make API calls on behalf of users.
Tokens are only stored when the social account is stored. This doesn’t work with EMAIL_AUTHENTICATION unless EMAIL_AUTHENTICATION_AUTO_CONNECT is also enabled.
Access tokens later:

SOCIALACCOUNT_REQUESTS_TIMEOUT

Default: 5 Timeout in seconds for upstream requests to providers.

SOCIALACCOUNT_SOCIALACCOUNT_STR

Default: str of user object Customize the string representation of SocialAccount.

SOCIALACCOUNT_ONLY

Default: False Disable all local account functionality. Users can only authenticate via social providers.

SOCIALACCOUNT_OPENID_CONNECT_URL_PREFIX

Default: "oidc" URL path prefix for OpenID Connect providers. With default settings, a provider with ID foo uses /accounts/oidc/foo/login/.

Provider-Specific Configuration

Each provider supports specific configuration options via SOCIALACCOUNT_PROVIDERS.

Common OAuth2 Settings

Most OAuth2 providers support these settings:

App-Level Settings

Settings can also be configured per app:

Example Configurations

Google with Offline Access

GitHub with Custom Scopes

Multiple OpenID Connect Providers

SAML Configuration

Environment Variables

Best practice for managing secrets:
In .env file:

Multi-Tenant Configuration

Using Django sites framework for different configurations per domain:
Create separate SocialApp instances via admin and assign to different sites. Each site can have different credentials for the same provider.

Next Steps

Providers

Explore provider-specific configuration options

Advanced Usage

Learn about adapters, custom redirects, and more