django-allauth: the authentication app, and the mirror that is not where the work happens

The GitHub repository is a mirror, and that changes where you file things

The repository description says it plainly: this is a mirror of the project on Codeberg. The README agrees, listing source code, issue tracker and documentation all pointing at codeberg.org, with the documentation at docs.allauth.org and the homepage at allauth.org.

That detail has practical consequences that are easy to miss from the star count. The GitHub repository has two open issues against more than 10,000 stars, which would be extraordinary for an actively developed project of this scale. The explanation is that issues live on Codeberg, so the GitHub count measures nothing about responsiveness. If you find a bug, the issue tracker to use is the Codeberg one, and reading the GitHub issues for prior reports is not a reliable way to check whether something is already known.

The split continues past issues. The README's continuous integration badge points at a GitHub Actions workflow in the pennersr repository, and the tree contains both a `.github/` directory and a `.woodpecker.yaml`. So the GitHub mirror is not purely passive: builds appear to run there as well, while Codeberg is where the project is developed and triaged. Developers who assume a GitHub mirror implies no activity in the GitHub repository will be wrong.

There is a licence oddity in the same vein. GitHub reports MIT and pyproject.toml declares MIT, but the package.json in the root declares ISC. Reading that file explains it: it contains no real metadata beyond a dev dependency on standard, a test script that echoes an error and exits 1, and empty author fields. It is a stub existing to run standardjs over the JavaScript files, not a description of the package. Trust pyproject.toml.

The gap the project exists to close

The rationale section makes a case that is more specific than most authentication packages bother with. Its argument is that most Django apps addressing social authentication focus only on one dimension, the social one, so developers end up integrating a second app to support authentication flows that are locally generated, and that creates a development gap between the two.

The example given is an email address passed along by an OpenID provider that may not be verified, meaning that before the OpenID account can be hooked up to a local account, the email address must be verified. That is described as one of many use cases that mandate email verification in both worlds, and the conclusion is that integrating both is a humongous and tedious process rather than a matter of adding two entries to `INSTALLED_APPS`.

That is a real architectural complaint, not a marketing one. The failure mode it describes is subtle: if social signup and local signup are separate code paths, then every account-level invariant, password reset flow, email change handler, and lockout policy has to be implemented twice, and the two implementations drift. A library that makes both paths go through the same account model removes the duplication rather than documenting it.

The customization story follows from the same premise. The README describes using the adapter pattern to introduce interventions at the desired points and deviate from standard behaviour. For an authentication library, this is the difference between usable and not, because almost every application needs at least one account flow shaped differently.

Extras decide what you actually install

The pyproject.toml classifies the package as Development Status 5 - Production/Stable, requires Python 3.10 or above, and depends on Django 4.2.16 or above plus asgiref. The classifier list covers Python 3.10 through 3.14 and Django 4.2 through 6.1, which is a wide support matrix for a package this central.

The optional dependency groups are the part that matters most for a new user, because they explain the breadth without installing it. `mfa` pulls in qrcode and fido2, which is what passkeys and WebAuthn support requires. `saml` pulls in python3-saml, and the topics list confirms SAML is a first-class concern rather than a plugin. `openid` brings python3-openid, and `idp-oidc` brings oauthlib alongside pyjwt, which is the group for using allauth as an identity provider rather than only a client.

Then there are two groups whose names describe an architectural shift rather than a provider. `headless` pulls in pyjwt, and `headless-spec` pulls in PyYAML. The Makefile confirms what this is by validating an OpenAPI document at `allauth/headless/spec/doc/openapi.yaml` with swagger-cli. So the headless mode is a documented HTTP API for authentication, meant to be consumed by a separate frontend application rather than by Django templates.

The README links two demos, one at django.demo.allauth.org and one at react.demo.allauth.org, and the second of those is the headless path in use: a React single-page application authenticating against an allauth backend through its API. That pairing is the clearest available answer to the question of what headless mode is for, and it is worth opening before designing a SPA's login flow.

A `steam` extra also exists in the dependency list, which is a reminder that provider coverage extends past the major social networks into individual services.

Security features that are on by default rather than added later

Two of the listed features are the kind that get bolted on after an incident, and here they are described as defaults. Rate limiting is enabled out of the box, with the reasoning given plainly: when you expose an authentication-enabled web service to the internet, you need to be prepared for brute force attempts.

Account enumeration prevention is the other one, and the README's justification is the most concrete security writing in the project. It notes that on many sites you can check whether someone you know has an account by entering their email address into the password forgotten form, or by trying to sign up with it. The claim is that allauth makes it impossible to tell whether somebody already has an account, which closes both probes at once.

Both features are easy to underestimate, because each protects an attack that produces no visible failure in your own logs. Enumeration is typically used to build a list of valid accounts before credential stuffing, and the difference between an endpoint that reveals membership and one that does not is the difference between a targeted attack and a spray.

The topics list adds passkeys, webauthn, oauth2, openid-connect and two-factor-authentication, so the security surface covered extends well past password login. The README also makes an age claim: the package has been out in the open since 2010 and is in use by many commercial companies whose business depends on it, which is why it says it has been subjected to various penetration testing attempts. A library holding credentials for a large user base is a target by definition, and the length of that history is relevant to how you should treat it.

For operational configuration, the README notes that consumer keys and secrets can be set in regular settings or in the database through the Django admin, with optional support for the sites framework, which it describes as helpful for larger multi-domain projects and as a way to switch between a localhost development setup and production without editing settings and database.

Tooling choices that say how the project is worked on

The tree and Makefile describe a project with more than one way of running its checks, which usually indicates contributors arriving with different backgrounds. There is a Makefile, a noxfile.py, a mise.toml, devenv.nix and devenv.lock, plus both .dir-locals.el and an .editorconfig. That is four distinct environment strategies, which is generous but does mean a newcomer has to pick one.

The Makefile's `qa` target composes the full set: validate-api-spec, mypy, djlint, bandit, black, isort and flake8. Notably absent from that chain is the test suite, which has its own target running pytest against the `allauth/` directory, so the local loop and the pre-commit loop are deliberately different things. bandit running against pyproject.toml as its configuration is the security scanner slot, and djlint checking `allauth` and `examples` covers the template files.

The API spec validation is written defensively, checking whether swagger-cli exists on the PATH and printing a warning rather than failing if it does not, which means a contributor without Node tooling installed can still run the rest of the chain. The CI target delegates to `woodpecker-cli exec .woodpecker.yaml`, which is a self-hosted CI runner rather than GitHub Actions, matching the Codeberg-centred development story.

The documentation tree has its own Makefile target, and `examples/` is checked by djlint alongside the package, which suggests the example projects are maintained as real code rather than as prose snippets. For an authentication library, that matters more than usual: the examples are how most people learn the correct integration, and examples that drift out of date cause security problems in a way that documentation drift rarely does.

Commercial support is offered through an address at intenct.nl, the same domain as the maintainer's email in pyproject.toml. That is a normal arrangement for infrastructure libraries and is worth knowing about before you are three weeks into an integration.

Editorial conclusion

django-allauth earns its position by treating local and social authentication as one problem instead of two, which is the gap its rationale section describes in detail and which most competitors leave open. The features are broad enough to replace a stack of smaller packages: OpenID Connect, OAuth 1 and 2, SAML, WebAuthn with passkeys, rate limiting and account enumeration prevention, with extras installed per need rather than all at once. Two practical notes for anyone picking it up. File issues on Codeberg, since the GitHub repository is a mirror and its low open issue count reflects where reports actually go. And read the extras list in pyproject.toml before installing, because the SAML, MFA and headless capabilities are separate optional dependencies.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pennersr/django-allauth on GitHub
4. Project website
5. README