DOCSEARCHbyAlgolia
Submit Docs

django-allauth Documentation

repository·main·Indexed 27 days ago

https://github.com/pennersr/django-allauth

A comprehensive authentication suite for Django that unifies local account management with social and enterprise authentication, including OAuth, OpenID Connect, and SAML. It features a Headless API supporting both browser and app contexts, specialized OAuth2 clients for providers like Apple, DingTalk, Feishu, and Notion, and management tools for handling user email data integrity.

Tokens
65.1K
Snippets
174
Records
407
Agent score
95%

What's inside django-allauth

  1. Overview of MFA features in django-allauth

    main

    The allauth.mfa app provides the following authentication capabilities:

    • TOTP: Time-based One-Time Password authentication.
    • Recovery Codes: Authentication via recovery codes, including functionality for viewing, downloading, and regenerating them.
    • WebAuthn: Support for WebAuthn-based credentials (Note: WebAuthn support is disabled by default).
    • Passkeys: Login using passkeys.

  2. Overview of django-allauth

    main
    django-allauth is an integrated set of Django applications designed to handle authentication, user registration, account management, and 3rd-party (social) account authentication. It aims to bridge the gap between local authentication flows and social authentication flows, ensuring features like email verification work consistently across both.

  3. Overview of social account features

    main

    The allauth.socialaccount app manages third-party ("social") accounts where authentication is delegated to an external identity provider. Key capabilities include:

    • Connecting accounts: Link one or more social accounts to an existing local/regular account.
    • Disconnecting accounts: Remove a social account connection. Note that if only a local account remains, you must have a password set for that account to ensure you can still log in.
    • Instant-signup: Enable optional instant-signup for social accounts to allow users to register without additional questions/forms.

  5. Understand the django-allauth architecture

    main

    django-allauth is organized into specialized Django apps, each targeting a specific functional area. When looking for documentation or implementing specific features, identify which app you need:

    • allauth.account: Handles regular account functionality, such as username and/or email-based authentication.
    • allauth.socialaccount: Handles social account integration and authentication.
    • allauth.mfa: Handles multi-factor authentication (MFA) functionality.

  6. Choose a client type for django-allauth Headless API

    main

    The Headless API supports two distinct client types, which determines the routing path and security mechanism used. You must choose the path based on your application context:

    • Browser context: For web applications (e.g., React SPAs) running in a browser. Uses session cookies and requires CSRF protection.
      • Path pattern: /_allauth/browser/v1/...
    • App context: For non-browser applications (e.g., mobile Android/iOS apps). Uses session tokens instead of cookies.
      • Path pattern: /_allauth/app/v1/...

    Security handling (cookies vs. tokens) is automatically adjusted based on the request path used.

  8. Manage regular user accounts with allauth.account

    main

    The allauth.account application provides the core functionality for managing standard user accounts in Django. It handles authentication, registration, and account maintenance features.

    Key capabilities include:

    • Authentication: Users can authenticate using either a username or an email address.
    • Registration: Support for new user signup, including the ability to use custom signup forms.
    • Email Management: Supports simple email changes as well as complex flows for managing multiple email addresses (e.g., adding secondary addresses or setting a primary address).
    • Password Management: Includes workflows for both forgotten password recovery and manual password changes.
    • Verification: Provides an email address verification flow to ensure user identity.

  9. Configure Atlassian Social App in Django Admin

    main

    To connect your Atlassian app to your Django project, create a new social application via the Django admin interface at /admin/socialaccount/socialapp/ with the following settings:

    • Provider: Atlassian
    • Name: A descriptive name (e.g., Atlassian)
    • Client id: Enter the value labeled Client ID in the Atlassian console.
    • Secret key: Enter the value labeled Secret in the Atlassian console.
    • Key: Leave this field blank.

  11. Configure OpenID Connect clients via Django admin

    main

    OpenID Connect clients (consumers/applications) are managed through the Django admin interface. When creating a client, the ID and Secret are automatically generated. Note that the Secret is only displayed once in a message at the time of creation.

    Key configuration properties include:

    • Name: The display name shown on the authorization page.
    • Scopes: The scopes the client is permitted to request. Enter values one per line.
    • Default scopes: Scopes used if the client does not specify any. Enter values one per line.
    • Grant types: Allowed grant types (e.g., authorization_code, client_credentials, refresh_token). Enter one per line.
    • CORS origins: Allowed origins for cross-origin requests. Enter one per line.
    • Redirect URIs: Allowed callback URLs. Enter one per line.
    • Response types: Allowed response types (e.g., code). Enter one per line.
    • Skip consent: If enabled, the consent page is bypassed and all requested scopes are granted automatically.
    • Type:
      • Confidential: Clients capable of securely storing a secret (e.g., server-side apps).
      • Public: Clients unable to keep secrets safe (e.g., browser or mobile apps).