django-allauth-async 65.16.1.1

django-allauth plus allauth_async, a native-asyncio twin of its auth flows for ASGI apps. Ships the allauth package; do not install alongside django-allauth.

django-allauth-async

This is a fork of django-allauth (MIT licensed, by Raymond Penners and contributors) that adds allauth_async: a native-asyncio twin of allauth’s authentication flows for ASGI applications.

Why fork?

django-allauth is sync throughout — sync ORM in its flows, sync signal dispatch, blocking requests calls for OAuth/OIDC, and sync headless views. An async-first ASGI application (such as GlitchTip) can only call it through sync_to_async, paying a thread hop per auth request and running into known ASGI issues (upstream issues #3566, #3634). Upstream has no async roadmap; this fork exists to build one — with the intent of proposing the design upstream once it has stabilized in production.

How it relates to upstream

The allauth package in this repository is unmodified upstream code at the version this fork is based on (see the release tag). All fork code is additive, inside allauth_async/: each of its modules mirrors one upstream module and re-implements the blocking parts with real asyncio — async ORM, auth.alogin/aauthenticate, Signal.asend, async sessions, and aiohttp for outbound HTTP. A drift manifest (allauth_async/_upstream_manifest.json) records the reviewed hash of every mirrored upstream file; CI fails after an upstream merge until the affected async twins are re-reviewed (scripts/check_drift.py / scripts/ack_drift.py). Non-additive changes to upstream files are avoided; if one is ever unavoidable it carries [patch-upstream] in the commit subject so git log --grep='\[patch-upstream\]' lists the entire conflict surface.

Versioning

<upstream version>.<fork iteration> — e.g. 65.16.1.2 is the second fork release based on upstream 65.16.1. Upstream updates are merged (never rebased) from the upstream tag.

Installation

pip install django-allauth-async

Do not install alongside django-allauth — this distribution ships the allauth package itself, and the two would overwrite each other. allauth_async refuses to import if both are present.

Upstream’s documentation at https://docs.allauth.org applies to everything under allauth. The async layer is enabled by swapping specific entry points to their allauth_async counterparts (middleware, authentication backend, and the headless/provider URL includes); see the allauth_async module docstrings until dedicated docs land here.

Everything below this line is the original django-allauth README.

---

Welcome to django-allauth!

Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.

Home page

https://allauth.org/

Source code

https://codeberg.org/allauth/django-allauth

Issue Tracker

https://codeberg.org/allauth/django-allauth/issues

Documentation

https://docs.allauth.org/en/latest/

Stack Overflow

https://stackoverflow.com/questions/tagged/django-allauth

Demo

https://django.demo.allauth.org and https://react.demo.allauth.org

Translations

https://hosted.weblate.org/projects/allauth/django-allauth/

Rationale

Most existing Django apps that address the problem of social authentication unfortunately focus only on one dimension - the social. Most developers end up integrating another app in order to support authentication flows that are locally generated.

This approach creates a development gap between local and social authentication flows. It has remained an issue in spite of numerous common scenarios that both require. For example, an email address passed along by an OpenID provider may not be verified. Therefore, prior to hooking up an OpenID account to a local account the email address must be verified. This essentially is one of many use cases that mandate email verification to be present in both worlds.

Integrating both is a humongous and tedious process. It is not as simple as adding one social authentication app, and one local account registration app to your INSTALLED_APPS list.

This inadequacy is the reason for this project’s existence – to offer a fully integrated authentication app that allows for both local and social authentication, with flows that just work, beautifully!

Features

🔑 Comprehensive account functionality

Supports multiple authentication schemes (e.g. login by user name, or by email), as well as multiple strategies for account verification (ranging from none to mandatory email verification).

👥 Social Login

Login using external identity providers, supporting any Open ID Connect compatible provider, many OAuth 1.0/2.0 providers, as well as custom protocols such as, for example, Telegram authentication.

💼 Enterprise ready

Supports SAML 2.0, which is often used in a B2B context.

🕵️ Battle-tested

The package has been out in the open since 2010. It is in use by many commercial companies whose business depends on it and has hence been subjected to various penetration testing attempts.

⏳Rate limiting

When you expose an authentication-enabled web service to the internet, it is important to be prepared for potential brute force attempts. Therefore, rate limiting is enabled out of the box.

🔒 Private

Many sites leak information. For example, on many sites you can check whether someone you know has an account by input their email address into the password forgotten form, or trying to signup with it. We offer account enumeration prevention, making it impossible to tell whether or not somebody already has an account.

🧩 Customizable

As a developer, you have the flexibility to customize the core functionality according to your specific requirements. By employing the adapter pattern, you can effortlessly introduce interventions at the desired points to deviate from the standard behavior. This level of customization empowers you to tailor the software to meet your unique needs and preferences.

⚙️ Configuration

The required consumer keys and secrets for interacting with Facebook, X (Twitter) and the likes can be configured using regular settings, or, can be configured in the database via the Django admin. Here, optional support for the Django sites framework is available, which is helpful for larger multi-domain projects, but also allows for easy switching between a development (localhost) and production setup without messing with your settings and database.

Commercial Support

Commercial support is available. If you find certain functionality missing, or require assistance on your project(s), please contact us: [e-mail].