Social Auth Core

Social Auth Core is the framework-agnostic foundation of the Python Social Auth project, defining a common backend interface that nearly 180 third-party authentication providers implement — from major OAuth2 providers (Google, GitHub, Facebook, Microsoft/Azure AD) to SAML and OpenID Connect providers, niche services, and enterprise identity providers. Each backend lives as its own module under social_core/backends/, implementing the shared base classes for the specific OAuth/OpenID/SAML flow that provider requires.

On its own, social-core is not tied to any web framework; it defines the strategy.py/storage.py abstraction that framework-specific packages (social-auth-app-django, social-auth-app-flask, etc.) implement to plug the authentication pipeline into a particular framework’s session, user model, and storage layer. The pipeline/ module implements the configurable step-by-step authentication pipeline (create user, associate social account, etc.) that runs after a successful login with any backend.

What You Get

• Backend implementations for close to 180 identity providers (Google, GitHub, Microsoft, Facebook, Apple, and many more) under a shared interface
• Support for OAuth1, OAuth2, OpenID Connect, and SAML authentication flows through provider-specific backend classes
• A configurable authentication pipeline for steps like user creation, account association, and social profile syncing after login
• Abstract strategy/storage interfaces that framework-specific packages (Django, Flask, etc.) implement to integrate with that framework’s session and user model
• A registry for looking up and instantiating configured backends by name at runtime
• Type-checked codebase (py.typed) with an extensive tests/ suite covering backend behavior

Common Use Cases

• Adding “Sign in with Google/GitHub/Microsoft/…” social login to a Django, Flask, or other Python web application via a framework-specific adapter package
• Enterprise applications needing SAML or OpenID Connect SSO against a corporate identity provider
• Multi-provider auth systems that need one consistent interface regardless of which of the ~180 supported services a user authenticates with
• Custom authentication pipelines that need to run extra steps (e.g. account association, profile enrichment) after a successful social login

Under The Hood

Architecture - social_core/backends/ holds one module per identity provider (178 files), each subclassing shared base classes (base.py) that implement OAuth1/OAuth2/OpenID/SAML protocol mechanics once, so individual provider backends mostly just declare endpoint URLs and scope/field mappings; pipeline/ implements the post-authentication step sequence, strategy.py/storage.py define the abstract interface framework adapters must implement, and registry.py resolves configured backend names to classes at runtime. Tech Stack - Pure Python, BSD-3-Clause licensed, framework-agnostic by design (only the Django and framework-adapter packages in the broader python-social-auth org depend on a specific web framework), versioned per Semantic Versioning 2.0.0. Code Quality - 145 test_*.py files exercise the backend and pipeline logic, the package ships py.typed for downstream type-checking support, and 4,022 total commits across 33 tagged releases with active recent commits indicate a long-running, still-maintained project, though the README notes only the core and Django integration are actively developed while other framework adapters are maintenance-only. API Design - Implementing a new backend mostly means subclassing an existing OAuth2/OpenID/SAML base class and filling in a handful of provider-specific constants (endpoint URLs, scope, field mapping), which keeps the barrier to adding a new provider low; framework integrators, however, need to understand the strategy/storage abstraction before wiring the library into a new framework, which is a steeper but well-precedented path given ~180 existing backend examples to reference.