Configuration Methods
django-allauth supports two methods for configuring social providers:- Settings-based: Define configuration in
settings.py - Database-based: Create
SocialAppinstances via Django admin
Settings-Based Configuration
Define providers in yoursettings.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
CreateSocialApp instances via Django admin at /admin/socialaccount/socialapp/:
- Navigate to Social applications
- Click “Add social application”
- 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
Global Settings
All settings are prefixed withSOCIALACCOUNT_ 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.
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 timeTrue: 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 asSOCIALACCOUNT_EMAIL_REQUIRED
Request email address from the provider (e.g., using OpenID AX or OAuth scopes).
SOCIALACCOUNT_FORMS
Default:SOCIALACCOUNT_LOGIN_ON_GET
Default:False
Controls whether social login endpoints (e.g., /accounts/google/login/) accept GET requests to initiate authentication.
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.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 viaSOCIALACCOUNT_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:.env file:
Multi-Tenant Configuration
Using Django sites framework for different configurations per domain: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
