djoser: DRF auth views for registration, login and password reset
REST implementation of Django authentication system.
At a glance
- What is it?
- djoser reimplements Django's authentication flows as Django REST Framework views for single page apps, covering token, JWT, social and WebAuthn authentication under an MIT licence. It is a thin layer of endpoints over Django's user model, and the trade-offs sit in the reimplementation rather than in the feature list.
- Who is it for?
- Adopt djoser if you are building a Django REST Framework backend for a single page app and want registration, activation, password reset and token or JWT login exposed as endpoints without writing serializers yourself. Do not adopt it if you need OAuth2 provider behaviour, since the README points to django-oauth-toolkit for that, or if you cannot accept the documented authenticate() path that ignores an intentional None return.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 45 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap djoser fills between Django auth and a DRF API
Django ships authentication as forms and views that expect server-rendered templates. Django REST Framework gives you serializers, viewsets and authentication classes, but not a ready-made set of endpoints for the account lifecycle. djoser sits in that space. The README describes it as a REST implementation of the Django authentication system and lists the actions it handles: registration, login, logout, password reset and account activation. The stated audience is the single page app architecture. The README is explicit that the library did not reuse Django's own machinery, saying that instead of reusing Django code such as PasswordResetForm, the authors reimplemented a few things to fit better into SPA architecture. That sentence is the whole design premise. A form-based password reset assumes a template and a redirect; an SPA needs a token or a UID passed back through an API call. If your front end is a Django template, you already have this functionality and djoser adds nothing. If your front end is React, Vue or a mobile client talking JSON, the endpoints are the product.
What the views actually cover: tokens, JWT, social and WebAuthn
The supported feature list in the README names four authentication styles: token-based authentication, JWT authentication, social authentication and WebAuthn support. That is a wider surface than a minimal registration app. Token authentication refers to DRF's own token mechanism, which means a database row per token rather than a signed stateless credential. JWT support implies an integration with a token library, though the README does not name which one, so check the configuration documentation before assuming a particular package. Social authentication and WebAuthn are listed without further detail in the supplied material; the README does not explain which providers or which WebAuthn flows are implemented, and I cannot confirm that from what is here. Treat those two entries as claims to verify against the docs rather than settled facts. The important structural point is that djoser is a set of DRF views, not a framework. It composes with DRF's authentication classes rather than replacing them, so the choice between session, token and JWT remains a DRF setting, and djoser supplies the endpoints that issue and revoke the credentials.
Installation and the configuration step the README hands off
Getting the package is one command: pip install djoser. The README then stops and points at the configuration guide on Read the Docs, which means the installation section alone is not sufficient to run anything. That hand-off is worth noticing because it is where most of the real work lives: URL routing, the authentication backend, and the settings that decide which endpoints are exposed. What the README does give in full is the development setup, and it is unusually specific. The project uses uv as its dependency and packaging tool. Cloning and syncing looks like this: git clone git@github.com:sunscrapers/djoser.git, then cd djoser, then uv sync --all-extras --all-groups, which the README says creates a virtualenv with all development dependencies. Tests run with uv run pytest testproject/. There is a Makefile wrapping the same steps as make init and make test, and a test project you can start with make migrate followed by make runserver. If you prefer not to use uv, the README offers pip install .[test] and then cd testproject followed by ./manage.py test. Contributors are asked to run uv run pre-commit install, which wires up Black, Ruff, Docformatter and other checks before each commit. None of this is required to consume the library; it matters if you intend to patch it.
Version constraints are the first thing to check
The requirements section is unusually precise and it is the fastest way to rule djoser in or out. Python must be at least 3.9 and below 4.0, and the README spells out that this includes 3.10, 3.11, 3.12 and 3.13. Django must be at least 3.2, with support stated for 3.2 through 5.2. Django REST Framework must be at least 3.14. The upper bound on Python is a hard cap rather than a soft suggestion, which is normal for a library that has not yet been exercised against a future interpreter. If your project is pinned to an older Django, say 3.1 or earlier, djoser as released will not be a supported combination. If you are on a DRF version below 3.14, the same applies. The release history shows the project is maintained: 2.3.3 in July 2025 and 2.3.4 in August 2026, with a 2.3.4a1 alpha preceding the stable tag by under an hour on the same day. That alpha-then-stable pattern within the same afternoon suggests a quick turnaround on a fix rather than a long soak period, which is worth knowing if you pin exact versions in production.
The authenticate() caveat is the sharpest edge in the README
The README closes with a warning that deserves more prominence than it gets. It says that when using custom authentication and TokenCreateSerializer validation, there is a path that ignores an intentional return of None from authenticate() and tries to find the User using parameters instead. The README adds that this will probably be changed in the future. Read that carefully. Django's authentication contract allows a backend to return None to mean "I decline this credential", which is how a custom backend can refuse a user who is deactivated, locked, or failing a policy check. If djoser's token creation path bypasses that refusal and looks the user up by parameters, then a custom backend that relies on returning None as a security decision may not be honoured at the token endpoint. The README does not say which parameters, does not scope the condition beyond custom authentication plus TokenCreateSerializer, and does not offer a workaround. If you have a custom authentication backend doing anything more than checking a password, this is the first thing to test in your own environment before shipping. It is a documented caveat, not a confirmed vulnerability, and the practical impact depends entirely on what your backend does when it returns None.
How djoser differs from django-rest-registration and django-oauth-toolkit
The README lists two related projects, and the difference in approach is real rather than cosmetic. django-rest-registration solves the same problem, registration and login over REST, but its README is not in front of me, so I can only say that the two occupy the same slot and you should compare their endpoint sets and their handling of account verification directly. django-oauth-toolkit is a different animal entirely: it implements OAuth2 provider behaviour, meaning your Django app issues tokens to third-party clients under the OAuth2 grant model. djoser does not do that. It authenticates your own users against your own API. If you are building a service that other applications will integrate with, where clients need scopes and consent screens and refresh grants, djoser is the wrong tool and the README itself points you at django-oauth-toolkit. If you are building a first-party app where the same team owns the front end and the back end, OAuth2 is overhead and djoser's direct endpoints are the shorter path. The distinction is who holds the client credentials, not which library is more modern.
Licence, maintenance and what upgrading costs
djoser is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code, and it is compatible with the proprietary backends most teams run. This is not legal advice; confirm the notice requirements with your own counsel if you vendor or fork the code. On maintenance, the repository is not archived and the most recent push is dated 2026-08-01, the same day as the 2.3.4 release, so the project is active rather than dormant. The upgrade cost is dominated by the version matrix rather than by API churn: the stated support window spans Django 3.2 through 5.2 and Python 3.9 through 3.13, which is a wide band for a single release line. That breadth is convenient but it also means the library carries compatibility shims across several Django majors, and a future Django release outside the stated range will require a new djoser version rather than a configuration change. If you pin djoser, pin it alongside Django and DRF so the three move together, and read the release notes for each 2.3.x tag before bumping, since the 2.3.4 cycle included an alpha published minutes before the stable release.
Editorial conclusion
Adopt djoser if you are building a Django REST Framework backend for a single page app and want registration, activation, password reset and token or JWT login exposed as endpoints without writing serializers yourself. Do not adopt it if you need OAuth2 provider behaviour, since the README points to django-oauth-toolkit for that, or if you cannot accept the documented authenticate() path that ignores an intentional None return. Verify first that your Django, DRF and Python versions fall inside the stated ranges (Python 3.9 to 3.13, Django 3.2 to 5.2, DRF 3.14 or newer), then read the configuration page at djoser.readthedocs.io before touching settings, because the installation section itself only says to continue there.
Community notes