social-core freezes its test tools and floats its runtime deps

Only the core and Django modules are still being developed

The contributing section carries the most important sentence in the README, and it is short. Only the core and the Django modules are currently in development. Everything else is in maintenance only mode, and maintainers are especially welcome there.

That sentence defines the health of the whole ecosystem rather than of this one repository. The social-core package here is the piece that gets new work, while the surrounding providers and framework adapters are held steady. For a user that means backends for less common providers may move slowly, and it also means the invitation is aimed at maintainers rather than contributors of new features.

The repository itself is not archived, its last push was 2026-10-02, and the release line is healthy: 5.1.0 on 2026-08-06, 5.1.1 on 2026-09-18 and 5.2.0 on 2026-09-30, with 924 stars, 579 forks and 38 open issues. Forks outnumbering open issues by fifteen to one is what a widely depended-on library looks like.

The types group configures three type checkers at once

The development dependencies are declared as PEP 735 dependency groups rather than as extras, and every one of them is an exact pin. The dev group holds coverage 7.16.2, flake8 7.4.1, pytest-cov 7.1.0, pytest 9.1.1, pytest-xdist 3.8.0, pytest-profiling 1.8.1, responses 0.26.3 and pytest-github-actions-annotate-failures 0.4.2, then pulls in two more groups by reference.

The types group is the interesting one, because it installs three separate checkers:

"ty==0.0.84",

alongside mypy 2.4.0 and pyright 1.1.414, plus stub packages for defusedxml, lxml, oauthlib, requests-oauthlib and requests. Running mypy and pyright together is defensible for a library that others import with either; adding a third is a statement about the annotations in this codebase, and it is also three times the work to keep green.

The remaining group is pylint at 4.1.2, alongside flake8 in the dev group, so the project lints with two linters and type checks with three tools.

Runtime dependencies have floors and no ceilings

The runtime list is seven packages, and the policy is the opposite of the development groups:

"cryptography>=46.0.7",
"defusedxml>=0.7.1",

The rest follow the same shape, oauthlib at 3.3.1 or newer, PyJWT with the crypto extra at 2.13.0 or newer, python3-openid at 3.2.0 or newer, requests-oauthlib at 2.0.0 or newer, and requests at 2.34.0 or newer. Nothing has an upper bound.

That asymmetry is the design decision most likely to affect you. A library with open-ended runtime ranges resolves fresh on every install, which keeps a security update to cryptography or oauthlib flowing in without an upstream release, and also means a breaking major release of any of those packages can arrive underneath an application that pinned nothing. The development side takes the opposite stance and freezes everything exactly, so a green test run means the same thing today and next month.

If you ship this to production, the upper bounds belong in your own lock file rather than in your dependency declaration.

Three of the seven exist to verify tokens and parse XML

Read as a group, the runtime dependencies describe what the package does rather than what it provides. cryptography and PyJWT with the crypto extra cover token signing and verification, oauthlib and requests-oauthlib cover the OAuth 1 and OAuth 2 flows, and python3-openid covers OpenID Connect. requests is the transport underneath all of it.

The seventh is the one that looks out of place and is not: defusedxml, at 0.7.1 or newer. An authentication library parses XML from identity providers, and defusedxml is the standard way to do that without opening the door to entity expansion attacks. Stub packages for defusedxml, lxml, oauthlib, requests-oauthlib and requests are pinned in the types group, which says the maintainers intend those imports to be typed and checked.

The package keywords list oauth, openid, saml and social auth, so SAML is claimed here even though the SAML implementation lives elsewhere in the family, with this package providing the common interface the backends are written against.

The distribution is social-auth-core, the import is social_core

The install command uses the distribution name:

pip install social-auth-core

while the code lives in a directory called social_core, and the version is written in pyproject as 5.2.0, which matches the 5.2.0 release. Setuptools is the build backend at 78.0.2 or newer, and the license is declared as BSD-3-Clause with the license-files entry pointing at the LICENSE file, matching the README's statement that the project follows the BSD license.

The optional dependency group is where the family shows through. An extras group called all begins by pulling social-auth-core with further extras, which is how a single install line can reach the Azure and other provider extras that are implemented in the sibling packages rather than in this one.

Metadata is otherwise conventional and slightly conservative: Development Status :: 5 - Production/Stable, Environment :: Web Environment, Intended Audience :: Developers, Topic :: Internet, and requires-python at 3.10 or newer with classifiers for 3.10 through 3.14. Two maintainers are named in the authors list, Matias Aguirre and Michal Čihař, and the version history follows Semantic Versioning 2.0.0.

A 149 word README that points at a documentation site

The README is short enough to read in a minute, and everything else lives on readthedocs. It has a title, a two-line description of the package, a documentation link, the install command, a contributing note, the versioning policy, the license and two donation links. Nothing in it explains how a backend is written.

That is a defensible choice for a package with this many dependents, and the description is precise about scope: this is the core component of the python-social-auth ecosystem, implementing the common interface to define new authentication backends to third party services and to integrate with web frameworks and storage solutions. Anyone arriving for provider-specific instructions has to leave the repository.

The repository itself is tidy for its size. There is a .coveragerc and a tox.ini, a pre-commit configuration, a MANIFEST.in, a CHANGELOG, a scripts directory and the social_core package directory, plus a .well-known directory that holds the funding metadata matching the GitHub Sponsors and Open Collective links at the bottom of the README.

Editorial conclusion

social-auth-core is the right dependency if you are writing a backend for a provider, since the whole point of the package is the shared interface and the OAuth, OpenID and JWT plumbing underneath it. Two things to check before you depend on it. First, the version floor: Python 3.10 or newer, and the newest release line is 5.2.0 from 2026-09-30, so pin a minor version rather than tracking the trunk, especially since the project states that only the core and the Django module are still in active development. Second, the runtime floors: cryptography, oauthlib, PyJWT, python3-openid and requests all sit at recent lower bounds with no upper cap, so a fresh resolve can move a crypto library underneath you without any change on your side. That is a deliberate trade for library flexibility, and it is your dependency resolver's problem to manage.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes