Integrations

Social authentication

Authkits uses django-allauth for provider OAuth and brings completed social identities back through the same email-verification, MFA, trusted-device, session, abuse, and audit policy used by password login.

Authkits-managed providers

GitHub and Google are the built-in managed providers. You supply each provider's client ID and secret; Authkits owns the provider credential contract.

Existing django-allauth

Use host-owned allauth configuration for additional providers while keeping Authkits' account-security handoff around completed logins.

Install the social extra

Terminal

$python -m pip install "authkits-django[social]"

Managed GitHub and Google

settings.py

AUTHKITS = {
    "SOCIAL": {
        "ENABLED": True,
        "MODE": "managed",
        "PROVIDERS": {
            "github": {
                "CLIENT_ID": env("GITHUB_CLIENT_ID"),
                "CLIENT_SECRET": env("GITHUB_CLIENT_SECRET"),
            },
            "google": {
                "CLIENT_ID": env("GOOGLE_CLIENT_ID"),
                "CLIENT_SECRET": env("GOOGLE_CLIENT_SECRET"),
            },
        },
    },
}

The host still installs the corresponding allauth provider apps, middleware/backend, and OAuth callback routes. Authkits does not mutate your Django settings behind your back.

Existing provider configuration

settings.py

AUTHKITS = {
    "SOCIAL": {
        "ENABLED": True,
        "MODE": "existing",
    },
}

In existing mode, your project owns django-allauth provider apps and credentials. Authkits discovers the available providers and keeps its security policy around the completed identity handoff.

Identity and reauthentication policy

Authkits does not silently link a social identity to a local account just because the emails match. Connected-provider changes are treated as security mutations. Google currently supports provider-native forced reauthentication for that sensitive flow; a normal GitHub OAuth round-trip is not treated as fresh proof.

Headless social login

API clients can use the same provider boundary through a browser OAuth handoff that exchanges into an Authkits revocable bearer credential.

Headless and DRF APIs