social-app-django: the Django side of Python Social Auth

The Django half of a provider agnostic auth stack

Third party login is a solved protocol and a recurring Django integration cost. Every provider brings its own token endpoint, its own error payload and its own habits around scopes, and rebuilding that glue per project is where duplication starts. This repository exists to end that duplication: it is the Django component of the python-social-auth ecosystem, and its stated job is to implement the functionality needed to integrate social-auth-core in a Django based project. Repository topics are authentication, django, oauth2 and python. Its pinned runtime dependencies are an async safety library, Django itself and social-auth-core, with no named identity provider anywhere in the manifest, so nothing here is tied to one vendor. Adopting it is a decision to run on an abstraction layer rather than to add a login button.

Version 6.0.1 sets a Django 5.2 floor and a Python 3.10 ceiling

The manifest is where the boundaries live. The project version is 6.0.1, `requires-python` is `>=3.10`, and the classifiers walk Python 3.10 through 3.14 while naming only Django 5.2 and Django 6.0. The Django requirement is a lower bound with no upper cap, so a future Django version installs without a resolver complaint and leaves the integration unexercised against it. Project policy matches: the README says the project focuses on the currently supported Django versions as stated in the Django Project Supported Versions table, and that backward compatibility with unsupported versions will not be enforced. Treat that as a policy rather than a warning label, because an application held on an out of support Django has no in-package path forward. The last push was on 2026-09-28, the repository is not archived, and `CHANGELOG.md` at the root is the only upgrade record the README points readers to.

Installing social-auth-app-django and finding the real documentation

The setup section of the README is one command, and it is the entire documented installation path. No extra flag, no extras group, no build step:

pip install social-auth-app-django

After that pip resolves three runtime packages and nothing else from this project:

dependencies = [
  "asgiref>=3.8.1",
  "Django>=5.2",
  "social-auth-core>=5.0.0,<6.0.0"
]

What a newcomer will not find in the README is the half that breaks first: no settings block, no authentication backends list, no URL wiring, no template snippet for a login link. The repository carries `manage.py` and a `tests/` directory, so the package is exercised as a Django app, yet none of that wiring is written down on the page. The README points instead to hosted documentation at `python-social-auth.readthedocs.io`, and that is where the settings and URL work is documented.

Why an async library and a capped core range sit in an auth package

Two lines in that dependency list deserve more attention than they usually receive. `asgiref>=3.8.1` is declared directly even though Django ships it, which lets you hold an async safety version independently of whatever Django itself resolves, and it signals that the package is expected to work on the async stack rather than only under WSGI. The heavier constraint is `social-auth-core>=5.0.0,<6.0.0`. The Django layer is written against the core 5.x backend interface, and pip will refuse core 6 until a new version of this package raises that ceiling. Written as a range rather than a floor, it also means a project still holding core 4.x cannot install this package without moving core forward in the same operation. No file shown in the repository describes what breaks at core 6, so that upgrade is something you plan, not something you inherit.

Only the core and Django modules are still under development

The README draws a hard line inside the ecosystem: only the core and Django modules are currently in development, all others are in maintenance only mode, and maintainers are especially welcome there. At package level the metadata sounds calmer, since the classifiers include `Development Status :: 5 - Production/Stable`. Both statements hold at once, and the gap between them is the part that affects you. The Django adapter is where active work happens, so provider packages on the maintenance side will receive fixes only when outside contributors supply them. Choosing a provider from that set means choosing code whose repair schedule you do not control, and the README routes funding for that maintenance to GitHub Sponsors and Open Collective. A badge covering the whole ecosystem would be a different claim.

Contributor gates in tox.ini, pre-commit and two type checkers

Quality controls for contributors live in files a user never touches: `.coveragerc`, `.pre-commit-config.yaml` and `tox.ini` sit at the repository root beside `manage.py`, `social_django/` and `tests/`. The tool set is pinned hard rather than ranged:

dev = [
  "coverage>=3.6",
  "django-stubs-ext==6.0.9",
  "django-stubs==6.0.9",
  "mypy==2.3.1",
  "pre-commit",
  "pyright==1.1.414",
  "tox"
]

Running `mypy==2.3.1` and `pyright==1.1.414` together on a package this small is a deliberate double gate, and both checkers consume `django-stubs==6.0.9` for Django settings types. For an integration layer, that combination catches signature drift in calls into social-auth-core before a shipped version does. One detail rewards a close read: these same seven entries appear twice, once as a dependency group and again as an optional dependency group, and an inline comment in the manifest explains the duplication persists until pip implements PEP 735.

Where the upgrade cost lands, and the missing rollback story

A narrow ceiling is cheap to live with and expensive to break. Because the core dependency is capped below 6.0.0, the moment a Django site needs core 6 features it must take a newer version of this package in the same change, and the resolver will not stage the two moves apart. The manifest offers no upper bound on Django either, so a Django major upgrade and a core major upgrade can collide in one maintenance window. Against that, the upgrade documentation is thin: the README does not describe a migration procedure for either bump, does not document rollback for a failed upgrade, and does not state which Django versions were tested against which core versions. Anyone planning this upgrade has to confirm the Django and core pairing by hand before scheduling it.

The alternative is owning the OAuth exchange in your own backend

A Django project can skip this package entirely by writing a small authentication backend that completes the authorization code exchange itself: redirect, callback, token request, user mapping, done. Both designs work, and the difference is ownership. Hand written code must validate state, schedule token refresh and translate provider error payloads, and it stays yours through every provider deprecation and every change in a remote token endpoint. Installing this package moves that work into the backend classes of social-auth-core plus the Django glue under `social_django/`, and in exchange you accept the strict version range and a dependency on sibling packages in the same ecosystem, several of which the project puts in maintenance only mode. Choose the package when you would rather hold a version contract, and write the backend when your provider list is short enough to own end to end.

Editorial conclusion

social-app-django is a small, sharply scoped Django binding, and its real cost is a version contract rather than a line of code. Teams already on social-auth-core 5.x and a supported Django branch get consistent third party logins without writing provider glue. Teams on core 4.x or an out of support Django version should price the coupled upgrade first, because the README documents no migration steps, no tested Django and core pairing, and no rollback for a failed one. Read the root `CHANGELOG.md` before scheduling the work.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. python-social-auth/social-app-django on GitHub
4. README
5. Releases