skip to content

What does django-allauth add on top of Django's contrib.auth, and how do you plug it into a project?

level: juniorimportance: should knowfreq 48%

answer

  1. contrib.auth has no signup
  2. account, socialaccount, mfa apps
  3. a backend, a middleware, a URL include
  4. migrate after installing

basics

~10 s

django-allauth adds signup, email verification and management, rate-limited login by username or email, social providers and MFA on top of contrib.auth. Install its apps, its AuthenticationBackend, AccountMiddleware, and include allauth.urls.

solid answer

~30 s

Django's `contrib.auth` gives you the user model, `authenticate()`/`login()`, login, logout and password-reset views, but no signup view, no email verification, no login rate limiting, no social login and no MFA. **django-allauth** builds those on the same user model: `allauth.account` (signup, email addresses with verification, login by username or email, rate limits), `allauth.socialaccount` plus one app per provider, and `allauth.mfa` (TOTP, recovery codes, WebAuthn). Wiring it takes four steps: add the apps to `INSTALLED_APPS`, set `AUTHENTICATION_BACKENDS` to `allauth.account.auth_backends.AuthenticationBackend`, add `allauth.account.middleware.AccountMiddleware` to `MIDDLEWARE`, and `path("accounts/", include("allauth.urls"))`, then run `migrate`. Behaviour is tuned with `ACCOUNT_*`, `SOCIALACCOUNT_*` and `MFA_*` settings and adapter classes.

code

bash · 2 lines
bash
python -m pip install "django-allauth[socialaccount,mfa]"
python manage.py migrate

go deeper

for a junior

Recall the gaps in contrib.auth that allauth fills (signup, verification, social, MFA) and the four wiring steps.

for a middle

Explain what the AuthenticationBackend and AccountMiddleware each do, and how settings and adapters split configuration from policy.

for a senior

Call out operational edges: the admin login bypass, session engine requirements, and setting renames across allauth releases.

for a principal

Weigh adopting a large auth dependency against building flows in-house: security surface, upgrade cadence, and who owns account policy.

## What contrib.auth leaves out Django's built-in `django.contrib.auth` is an authentication **toolkit**: the `User` model (or your custom one), password hashing, `authenticate()` and `login()`, `LoginView`, `LogoutView` and the password-reset views. A public site usually needs more: - a **signup** view with validation and duplicate checks; - **email verification**, and more than one email address per account; - login **by email** as well as username; - **rate limiting** on login, signup and reset attempts; - **social sign-in** with third-party providers; - **multi-factor authentication**. **django-allauth** is the widely used third-party package that fills these gaps while keeping `contrib.auth` underneath: users are still rows of `AUTH_USER_MODEL`, sessions are still Django sessions, and `request.user` works as before. ## The apps | App | Adds | Install extra | |---|---|---| | `allauth.account` | Signup, login by username/email, `EmailAddress` records with verification, password set/change/reset flows, rate limits | none | | `allauth.socialaccount` + `allauth.socialaccount.providers.<name>` | Social sign-in, `SocialAccount` and `SocialApp` models, connecting several providers to one user | `django-allauth[socialaccount]` | | `allauth.mfa` | TOTP, recovery codes, WebAuthn and passkeys | `django-allauth[mfa]` | | `allauth.usersessions`, `allauth.headless` | Session listing; a JSON API for single-page and mobile front ends | optional | ## Plugging it in ```python # settings.py INSTALLED_APPS = [ # ... "django.contrib.auth", "django.contrib.messages", "allauth", "allauth.account", "allauth.socialaccount", "allauth.socialaccount.providers.github", "allauth.mfa", ] AUTHENTICATION_BACKENDS = [ "allauth.account.auth_backends.AuthenticationBackend", ] MIDDLEWARE = [ # ... SessionMiddleware, AuthenticationMiddleware, MessageMiddleware ... "allauth.account.middleware.AccountMiddleware", ] ``` ```python # urls.py from django.urls import include, path urlpatterns = [ path("accounts/", include("allauth.urls")), ] ``` Then: 1. Keep `django.template.context_processors.request` in the template options; allauth's templates need it. 2. Run `python manage.py migrate` to create the account, social and MFA tables. 3. Give each social provider its client credentials, either as a `SocialApp` row in the admin or under `SOCIALACCOUNT_PROVIDERS["<provider>"]["APP"]` in settings. ## What each wiring piece does - **`AuthenticationBackend`** subclasses Django's `ModelBackend` and looks users up by email and/or username according to `ACCOUNT_LOGIN_METHODS`, still running `user_can_authenticate()` and a dummy hash on misses. allauth's quickstart no longer lists `ModelBackend` beside it, because that would add a password path (the admin login) that allauth's rate limits do not cover. - **`AccountMiddleware`** has been required since allauth 0.56.0. It gives each request allauth's context and converts exceptions raised by hooks, such as `ImmediateHttpResponse` from an adapter or a reauthentication requirement, into responses. - **`include("allauth.urls")`** mounts named views such as `account_login`, `account_signup`, `account_logout`, `account_email`, the social provider callbacks and `/accounts/2fa/` for MFA. You usually do not also need `django.contrib.auth.urls`. ## How you customise it - **Settings** with the `ACCOUNT_`, `SOCIALACCOUNT_` and `MFA_` prefixes switch features on and off: login methods, signup fields, verification mode, rate limits, supported authenticator types. - **Adapters** (`ACCOUNT_ADAPTER`, `SOCIALACCOUNT_ADAPTER`, `MFA_ADAPTER`) are classes whose methods you override for policy: closing signups, populating the user from provider data, redirects, encrypting stored secrets. - **Templates** under `account/`, `socialaccount/` and `mfa/` are overridden like any app template. ## Caveats worth saying in an interview - allauth stores secrets such as verification codes in the session, so it is not designed for the signed-cookie session engine. - The Django admin keeps its own login view, which bypasses allauth's rate limits and MFA unless you wrap it. - It is a dependency with its own release cadence and setting renames; pin it and read its release notes on upgrade. ## Settings allauth reuses from Django allauth sits on Django's conventions rather than replacing them, which keeps the rest of the project unchanged: - **`LOGIN_REDIRECT_URL`** is where the account adapter's `get_login_redirect_url()` sends users after sign-in, unless a safe `next` parameter says otherwise. - **`LOGOUT_REDIRECT_URL`** is the fallback for allauth's own `ACCOUNT_LOGOUT_REDIRECT_URL`, which defaults to `"/"` when neither is set. - **Logout by GET is off** (`ACCOUNT_LOGOUT_ON_GET = False`), matching Django's own POST-only `LogoutView`. - **`request.user`, `login_required` and permissions** behave exactly as before, because the logged-in session is an ordinary Django auth session. That continuity is the practical argument for allauth over a hand-built signup stack: views, templates and permission checks written against `contrib.auth` keep working after it is installed.

  • Why is AccountMiddleware required, and what breaks without it?
    allauth needs a per-request context and a place to turn control-flow exceptions into responses: an adapter hook raising `ImmediateHttpResponse`, or a view demanding reauthentication. `AccountMiddleware` provides both. Since 0.56.0 it is mandatory, and projects upgrading from older versions must add it to `MIDDLEWARE`.
  • Does django-allauth replace Django's user model?
    No. It works with whatever `AUTH_USER_MODEL` points to, default or custom, and adds its own related models such as `EmailAddress`, `SocialAccount` and `Authenticator`. Settings such as `ACCOUNT_USER_MODEL_USERNAME_FIELD` tell it how your model is shaped, for example when there is no username field.

saying these in an interview costs you the question

  • django-allauth ships its own user model that replaces AUTH_USER_MODEL.
  • Django's contrib.auth already includes a signup view and email verification.
  • allauth only does social login; local accounts still need custom views.
  • Adding allauth to INSTALLED_APPS is enough; no backend or middleware changes.
  • allauth protects the Django admin login automatically.