Djoser

Djoser is a REST implementation of Django’s authentication system, providing a set of Django REST Framework views and viewsets for the auth flows nearly every backend needs: registration, account activation, token- and JWT-based login/logout, password reset, username reset, and profile management. It works with Django’s custom user model system rather than assuming a fixed schema, so it drops into existing Django projects without forcing a particular User model shape.

Beyond core token auth, Djoser bundles JWT support (via djangorestframework-simplejwt), social authentication (via social-auth-app-django), and WebAuthn passkey login, all resolved through a single settings.DJOSER configuration dict in the host project. Every serializer, permission class, and email template is overridable by dotted import path, so teams building single-page app or mobile backends can swap in only the endpoints and behaviors they need without subclassing viewsets or hand-writing auth views from scratch.

What You Get

• Token, JWT, social, and WebAuthn authentication endpoints out of the box, selectable per project
• A full user-management ViewSet (create, retrieve, update, delete, me) built on DRF’s ModelViewSet
• Activation, password reset, and username reset flows with configurable confirmation emails
• A single settings.DJOSER dict that overrides any serializer, permission class, or email template by dotted path
• Signals (user_registered, user_activated, user_updated) for hooking into the auth lifecycle

Common Use Cases

• Adding registration/login/logout REST endpoints to a Django API backing a single-page app or mobile client
• Standing up JWT-based authentication without hand-writing token issuance and refresh views
• Adding social login (Google, Facebook, etc.) or WebAuthn passkeys to an existing Django REST Framework project
• Building self-service password/username reset flows with emailed confirmation links

Under The Hood

Architecture Djoser is a thin Django app layered on Django REST Framework: its central entry points are DRF Views/ViewSets in views.py (UserViewSet, TokenCreateView, TokenDestroyView), paralleled by dedicated social/ and webauthn/ sub-packages that each ship their own views, serializers, and URL modules. Configuration flows through a single lazy settings singleton (conf.py’s Settings/LazySettings/ObjDict) that lets a host project override any of SERIALIZERS/PERMISSIONS/EMAIL/WEBAUTHN by dotted import path via Django’s own settings.DJOSER dict, re-evaluating automatically on Django’s setting_changed signal. Every view resolves its serializer and permission classes dynamically from this settings object rather than hardcoding them, making the settings dict the library’s one true extension point; signals.py provides a secondary hook (user_registered, user_activated, user_updated) for reacting to the auth lifecycle. Because nearly all runtime behavior is indirected through the settings singleton, changing that abstraction would ripple through every view, serializer, and email lookup in the codebase.

Tech Stack A pure-Python package targeting Django 3.2 through 5.2 and Django REST Framework 3.14+, with hard dependencies on djangorestframework-simplejwt for JWT and social-auth-app-django for OAuth/social login, plus an optional webauthn extra for passkey support. Packaging uses hatchling with PEP 621 pyproject.toml metadata and uv for dependency management, with dev tooling split into PEP 735 dependency groups (test, code-quality, docs) rather than a loose requirements file. Documentation is built with Sphinx and hosted on Read the Docs. Djoser has no database or ORM layer of its own — it relies entirely on the host project’s configured user model and auth backends.

Code Quality Testing is extensive: a dedicated testproject Django project exercises every endpoint — activation, token create/destroy, password and username reset plus confirm, full user CRUD, WebAuthn, and social auth — across more than twenty pytest modules, run with pytest-django and coverage, with a GitHub Actions matrix testing multiple Django, DRF, and Python version combinations. Pre-commit hooks enforce Black, Ruff, and Docformatter. Error handling favors explicit, idiomatic DRF patterns (serializer.is_valid(raise_exception=True), typed DRF exceptions) over broad excepts, and naming follows standard Django/DRF conventions. There is no static type checking and inline comment density is limited — most self-documentation comes from action docstrings surfaced through DRF’s browsable API rather than implementation comments.

API Design The library’s core developer-experience idea is full substitutability through one settings dict: every internal class reference is a dotted import-path string resolved lazily, so a consumer can override a single serializer, permission class, or email template without subclassing or monkeypatching a viewset, and the same mechanism transparently unifies token, JWT, social, and WebAuthn auth under one configuration surface. Getting started is a pip install plus adding the app and its URLs, though the breadth of optional settings (retype variants, WebAuthn config, per-action permissions) means real customization requires reading the docs rather than guessing from defaults.