dj-rest-auth Authentication Endpoints for Django REST Framework

Why dj-rest-auth Fits a Django API Client

dj-rest-auth addresses a repeated integration problem: exposing the authentication workflows required by browser and mobile applications through a Django REST Framework API. A client can send credentials to a login endpoint, request a password reset, change the current password, register a user, and read or update the authenticated user's details. The package also provides registration routes, social authentication integration through django-allauth, JWT authentication with cookies, MFA, and WebAuthn passkeys.

The intended users are developers building SPAs such as React or Vue applications, mobile applications, and other clients that communicate with a Django backend. The package does not replace Django's authentication system. Its architecture places `django.contrib.auth`, Django REST Framework, and optional components such as `simplejwt` or `django-allauth` behind the authentication endpoints. That arrangement keeps the API surface reusable while leaving Django responsible for the user model and authentication foundations.

The default endpoint set includes `/auth/login/`, `/auth/logout/`, `/auth/user/`, `/auth/password/change/`, `/auth/password/reset/`, and `/auth/password/reset/confirm/`. Registration adds a separate URL group. The project therefore suits applications that need more than a single login call, particularly when account lifecycle and password recovery are part of the product.

The Request Flow Through dj-rest-auth

The README's architecture diagram places dj-rest-auth between a client and Django REST Framework. Login and logout are handled by the package's authentication views, while Django's authentication machinery provides the underlying user validation and credential operations. Password reset also connects to `django.contrib.auth`.

Registration has a different path. The `dj_rest_auth.registration` application is added to `INSTALLED_APPS`, and django-allauth is used when social authentication is required. JWT is also optional. With `USE_JWT` enabled, `JWTCookieAuthentication` is configured as the default authentication class, while access and refresh tokens can be stored in cookies named by `JWT_AUTH_COOKIE` and `JWT_AUTH_REFRESH_COOKIE`. Setting `JWT_AUTH_HTTPONLY` to `True` makes those cookies HTTP-only according to the configuration shown in the README.

The package is designed around customizable serializers, so applications can adapt representation and validation behavior rather than treating every endpoint as fixed. MFA is an opt-in sub-package with TOTP challenges, recovery codes, short-lived MFA tokens, and activation confirmation. Passkeys are also opt-in and use the FIDO2/WebAuthn standard, with registration and login based on challenge and response exchanges. These are separate extension paths, not automatic features of a basic installation.

Install dj-rest-auth and Mount the Basic API

The repository documents installation with `pip`, followed by registration of the Django REST Framework applications and dj-rest-auth's URL module. The basic endpoint set is available after those project files are configured.

Install the package from PyPI:

pip install dj-rest-auth

Add the required applications in `settings.py`:

INSTALLED_APPS = [
    ...
    'rest_framework',
    'rest_framework.authtoken',
    'dj_rest_auth',
]

Mount the authentication URLs in `urls.py`:

urlpatterns = [
    path('auth/', include('dj_rest_auth.urls')),
]

This produces the documented `/auth/login/`, `/auth/logout/`, `/auth/user/`, and password-management routes. The first real client-side request would be a POST to `/auth/login/`; the response format and exact credential fields are governed by the configured REST framework serializers, so the README does not specify a complete request body here.

The package requires Python 3.10 or later, Django 4.2 or later, and Django REST Framework 3.13.0 or later according to `setup.py`. The repository's test dependencies are separate from runtime installation.

Enable JWT Cookies Without Misreading the Defaults

JWT support is added by installing `djangorestframework-simplejwt` and configuring REST framework to use dj-rest-auth's cookie authentication class. The documented configuration sets `USE_JWT`, selects access and refresh cookie names, and enables HTTP-only cookies.

pip install dj-rest-auth djangorestframework-simplejwt

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'dj_rest_auth.jwt_auth.JWTCookieAuthentication',
    ],
}

REST_AUTH = {
    'USE_JWT': True,
    'JWT_AUTH_COOKIE': 'access',
    'JWT_AUTH_REFRESH_COOKIE': 'refresh',
    'JWT_AUTH_HTTPONLY': True,
}

This is useful for clients that should receive JWTs through cookies instead of managing tokens only in application storage. It does not mean the project supplies a complete deployment policy for cookie domains, secure attributes, cross-origin requests, token lifetimes, or refresh behavior. Those settings are not documented in the README, so a developer must consult the project's JWT and cookies guide before deployment.

The `djangorestframework-simplejwt` dependency is also listed in the repository's test requirements at version `5.5.1`, but that test pin should not be treated as a general runtime instruction. The README gives the package name without a version constraint.

Add Registration, Social Login, MFA, or Passkeys Selectively

Registration is a separate feature and needs both the registration application and an additional URL include. The social-authentication extra installs `django-allauth` with its socialaccount support.

Install the social-authentication extra:

pip install 'dj-rest-auth[with-social]'

Configure the registration and allauth applications:

INSTALLED_APPS = [
    ...
    'django.contrib.sites',
    'allauth',
    'allauth.account',
    'dj_rest_auth.registration',
]

SITE_ID = 1

Mount registration routes beside the basic authentication routes:

urlpatterns = [
    path('auth/', include('dj_rest_auth.urls')),
    path('auth/registration/', include('dj_rest_auth.registration.urls')),
]

The MFA extra adds `pyotp>=2.9.0`, and the passkey extra adds `webauthn>=2.0.0` according to `setup.py`.

pip install 'dj-rest-auth[with-mfa]'

pip install 'dj-rest-auth[with-passkeys]'

These extras expand the attack surface and operational responsibilities. MFA requires enrollment and challenge flows, including recovery codes. Passkeys require WebAuthn-compatible clients and registration or login ceremonies. The README points to separate guides for endpoint details but does not document the complete configuration in the repository overview.

Limits of the Package and the Trade-Off with Custom Views

dj-rest-auth is useful when the default endpoint set matches an application, but it is not a complete identity platform. The README does not document a production email workflow for password reset, account lockout policy, session invalidation rules, audit logging, or client-specific token handling. Email verification is listed as a registration feature, but the configuration shown in the README does not explain how the Django email backend is configured.

The package also depends on a supported Django and Python combination. `setup.py` declares Python `>=3.10`, Django `>=4.2`, and Django REST Framework `>=3.13.0`. A project running outside those ranges cannot rely on the declared metadata, and an upgrade can require checking framework behavior as well as dj-rest-auth settings.

The alternative is to write custom Django REST Framework serializers and views using `django.contrib.auth` directly. That approach gives more control over payloads, error formats, registration rules, and endpoint boundaries, but it also means implementing and maintaining each workflow. dj-rest-auth reduces that initial work by supplying the common routes and extension points. The trade-off is accepting the package's conventions and reading its feature-specific documentation when application requirements go beyond login and password management.

For an API with unusual identity rules, a custom implementation may be clearer than adapting several optional subsystems. For a conventional account system, the packaged endpoints can avoid rebuilding the basic flows.

Maintenance, Releases, and the MIT License

The repository is not archived, and its last push was on 2026-06-05. The recent release history includes 7.2.0 on 2026-03-15, described as opt-in MFA/2FA support; 7.1.1 on 2026-02-17, containing test compatibility fixes and documentation improvements; and 7.1.0 on 2026-02-15, with Django 6 support and translation updates. These release notes indicate recent development around security features and framework compatibility, but they do not by themselves establish suitability for every production deployment.

Upgrade cost is concentrated in configuration review. Moving between releases can require checking Django compatibility, serializer behavior, JWT settings, allauth integration, MFA enrollment, and passkey ceremonies. The repository includes a `demo/` directory, documentation under `docs/`, and a `runtests.py` test runner. The README's contributor commands are:

pip install -r dj_rest_auth/tests/requirements.txt
python runtests.py

The package is licensed under the MIT license. That identifies the declared licensing model, but it does not answer application-specific compliance questions or replace review of dependency licenses and deployment obligations. The repository is suitable for teams that can manage Django upgrades and verify client behavior against their own deployment.

Editorial conclusion

Adopt dj-rest-auth when a Django REST Framework API needs packaged authentication endpoints, especially for an SPA or mobile client that also needs registration, JWT cookies, social authentication, MFA, or passkeys. Do not assume that installing the package completes email delivery, token policy, or production cookie configuration, because those concerns remain part of the Django project. Verify first that the chosen extra, URL configuration, authentication class, cookie settings, email configuration, and client handling match the application.

Frequently asked questions

Official sources

1. iMerica/dj-rest-auth on GitHub
2. License: MIT
3. Project website
4. README
5. Releases