django-allauth

django-allauth is a comprehensive Django authentication app that unifies local (username/email + password) and third-party (social) account authentication into a single, coherent set of flows. Rather than bolting together a separate registration app and a separate OAuth app, it addresses cross-cutting concerns that both share — such as verifying an email address supplied by a social provider before linking it to a local account — as first-class functionality.

Beyond basic login and signup, it ships support for over 120 identity providers (OAuth 1.0/2.0, OpenID Connect, and custom protocols), multi-factor authentication (TOTP, WebAuthn/passkeys, recovery codes), SAML 2.0 for enterprise SSO, a headless API mode for SPA/mobile clients, and account-enumeration prevention and rate limiting out of the box. In active use since 2010 and now mirrored to GitHub from its canonical Codeberg repository, it is widely regarded as the de-facto standard authentication solution for production Django applications.

What You Get

• Local authentication with configurable login methods (username or email) and verification strategies (none to mandatory email confirmation)
• Social login against 120+ OAuth1/OAuth2/OpenID Connect providers, plus custom protocols like Telegram authentication
• Multi-factor authentication: TOTP, WebAuthn/passkeys, and recovery codes
• SAML 2.0 support for enterprise B2B single sign-on
• A headless API mode for building React/SPA or mobile front ends against the same auth flows
• Built-in rate limiting and account-enumeration prevention to resist brute-force and information-leak attacks

Common Use Cases

• Adding “Sign in with Google/GitHub/Facebook” social login to a Django application without hand-rolling OAuth flows
• Building a SaaS product that needs both traditional email/password signup and social login with unified account linking
• Implementing enterprise SSO via SAML 2.0 for B2B Django applications
• Building a headless Django backend that serves auth flows to a separate React or mobile front end

Under The Hood

Architecture: The codebase is organized as a set of Django sub-apps under allauth/ — account/ (core local auth), socialaccount/ (with a providers/ directory containing 128 individual provider integrations), mfa/, idp/ (identity provider / OIDC server mode), headless/ (JSON API for SPA/mobile clients), and usersessions/. Each concern is a separately pluggable Django app, and the library uses an adapter pattern throughout (DefaultAccountAdapter, DefaultSocialAccountAdapter) so consuming projects can override specific behaviors without forking core logic.

Tech Stack: Requires Django >= 4.2.16 and asgiref >= 3.8.1, supporting Django 4.2 through 6.0 and Python 3.10–3.14. Optional extras add scoped dependencies only when needed: pyjwt[crypto] for headless mode, PyYAML for the headless OpenAPI spec, and oauthlib for the OIDC identity-provider mode — keeping the base install lean for projects that only need core auth.

Code Quality: The tests/ directory contains 419 test files, reflecting the surface area of supporting 128 distinct social providers plus MFA, SAML, and headless flows, each of which needs isolated provider-specific coverage. The project has been in continuous production use since 2010 and describes itself as subjected to “various penetration testing attempts,” with account-enumeration prevention and rate limiting built in as security-hardening defaults rather than opt-in features.

API Design: The adapter pattern is the primary extension mechanism — rather than subclassing views or monkeypatching, developers override adapter methods to customize behavior (e.g., what happens when a social email doesn’t match an existing account). This keeps upgrades safer since core view/model code stays untouched, though the sheer configuration surface (dozens of ACCOUNT_* and SOCIALACCOUNT_* settings) means there is a real onboarding cost before a team feels fluent in the library’s conventions.