Django OAuth Toolkit: an OAuth2 authorization server inside your Django project
OAuth2 goodies for the Djangonauts!
At a glance
- What is it?
- Django OAuth Toolkit adds OAuth2 endpoints, models and token logic to an existing Django app rather than a separate identity service. Version 3.4.0 also covers the MCP authorization server role, with PKCE required by default.
- Who is it for?
- Adopt Django OAuth Toolkit when your users, sessions and permissions already live in a Django project and you want the authorization server in the same process, database and deployment. Do not adopt it if you need a standalone identity product with its own admin surface and vendor support, or if you cannot take on migrations and token table growth.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 21 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 23, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Django OAuth Toolkit fills for Django teams
Django ships authentication for browsers and sessions, not an OAuth2 authorization server. If an external client, a mobile app, a CLI or an AI agent needs a token scoped to one of your users, the standard answer is to run a separate identity service and keep it in sync with your user table. Django OAuth Toolkit takes the other route: it is an OAuth2 authorization server that lives inside the Django project you already operate. The project describes itself as providing "the endpoints, models, and logic to issue and manage OAuth2 tokens from your existing Django project, instead of standing up and operating a separate service".
That framing sets the audience. It is for teams with an existing Django codebase, an existing user model and an existing deployment pipeline, who want to hand out tokens without adding a second system to monitor. It is not aimed at people who have no Django application yet, and it is not a hosted service. The pyproject metadata classifies it as Production/Stable and lists django, oauth, oauth2, oauthlib, authorization-server, oidc, mcp and pkce as keywords, which is a fair summary of the surface area: the package is about the authorization server role first, with resource server support as a second use.
How the authorization server is wired into a Django project
The mechanism is a Django application named oauth2_provider. Adding it to INSTALLED_APPS brings in models for clients, grants and tokens, and those models are ordinary Django models backed by your database. There is no separate token store and no sidecar process. The README states that the package "makes extensive use of the excellent OAuthLib", so the protocol parsing and validation work is delegated to that library while Django supplies persistence, the ORM and the request cycle.
The URLconf is the second half. The README's example includes oauth2_provider.urls under a prefix, conventionally o/, which exposes the authorization server endpoints. Because those are Django views, they inherit your middleware, your settings and your logging, and they run in the same worker pool as the rest of the site. The package can also act as a resource server to protect a Django or Django REST Framework API, which means the same install can both issue tokens and verify them on incoming requests.
Version 3.4.0 extends this with the authorization server role required by the Model Context Protocol authorization specification. According to the README, PKCE is required by default from that release, and the authorization server metadata (RFC 8414) and protected resource metadata (RFC 9728) discovery endpoints are included in the default URLconf. Dynamic Client Registration (RFC 7591/7592) and Client ID Metadata Documents are opt-in through the DCR_ENABLED and CIMD_ENABLED settings. The README points to the 3.4.0 release discussion for the supported specifications and current gaps, which is a signal that MCP coverage is not complete.
Installing Django OAuth Toolkit and mounting the endpoints
The README gives a short install path. The package is on PyPI, so pip is the documented route. The README does not describe a source checkout or a container install for production use; the Dockerfile and docker-compose files in the repository exist to build the test identity provider and relying party images, not to ship your application.
pip install django-oauth-toolkitAfter installation, register the application so Django loads its models and migrations.
INSTALLED_APPS = (
...,
'oauth2_provider',
)Run your normal migration command so the oauth2_provider tables are created. Then mount the authorization server URLs. The README uses the prefix o/ and imports the package's urls module directly.
from oauth2_provider import urls as oauth2_urls
urlpatterns = [
...,
path('o/', include(oauth2_urls)),
]With that in place, the OAuth2 endpoints are served from your own host under /o/. What you should see after the migration is a set of new tables in your database and, at request time, responses from the token and authorization endpoints. The README does not walk through registering an application client in the Django admin or through a full authorization code exchange, so treat the first working token as something you confirm against the full documentation on Read the Docs rather than from the README alone.
PKCE by default and what that changes for existing clients
Making PKCE required by default in 3.4.0 is the kind of change that looks small in a changelog and is not small in practice. PKCE binds an authorization request to a later token request using a code verifier and its derived challenge. Clients that were written against an earlier release and never sent a code_challenge will not complete the flow against a 3.4.0 server unless the requirement is relaxed in configuration.
That is a deliberate trade. The README frames the change as part of supporting the MCP authorization specification, where PKCE is expected. For a new deployment this is the right default. For a project upgrading from a pre-3.4 line with mobile or single-page clients already in the field, the upgrade is a client-side change as much as a server-side one, and the release discussion linked from the README is the place the project documents which specifications are supported and where the gaps remain. If your clients cannot be updated on the same schedule as your server, plan the upgrade around that constraint rather than around the Python dependency.
Where Django OAuth Toolkit is the wrong choice
The package assumes Django. That is the whole point, and it is also the boundary. If your services are written in other languages and Django is only a small part of your estate, an authorization server embedded in one Django app makes that app a dependency of every token issuance in the organisation, including for teams that never touch Python. A standalone identity service exists precisely to avoid that coupling.
The second limitation is operational. Tokens, grants and clients are rows in your database. The README does not describe a pruning or retention policy for expired tokens, and the repository listing does not point at one in the top-level files. That leaves cleanup as something your team owns. On a busy installation the token tables grow continuously, and the migration history grows with each release. Neither is unusual for a Django app, but both mean the upgrade cost is not zero and is paid in migrations and database maintenance rather than in a subscription.
The third is scope. The README presents the package as an OAuth2 authorization server that is rfc-compliant by way of OAuthLib, and mentions OpenID Connect only through the oidc keyword in the package metadata and the MCP discussion. Anyone who needs a full OpenID Connect provider with a certified conformance profile should read the documentation carefully before assuming that coverage, because the README does not claim it.
Django OAuth Toolkit compared with django-allauth
The most common comparison for this package is django-allauth, and the two solve different halves of the problem. django-allauth is about your users signing in to your site through other providers: it consumes OAuth2 and OpenID Connect from Google, GitHub and similar services. Django OAuth Toolkit is the inverse. It makes your Django project the provider, issuing tokens to clients that want access to your users' data.
A project can need both, and in that case they are not alternatives so much as neighbours: allauth handles inbound social login, Django OAuth Toolkit handles outbound authorization for third-party clients. Choosing between them only makes sense once you know which direction the trust flows. If the question is "let my users log in with Google", Django OAuth Toolkit is the wrong tool. If the question is "let a partner application call my API on behalf of my users", it is the right one, and allauth is irrelevant to that job.
Maintenance, licensing and the upgrade bill
The repository is not archived, and the last push was on 2026-09-02. Releases in the recent line are 3.3.0 on 2026-07-06, 3.4.0 on 2026-07-24 and 3.4.1 on 2026-08-21, so the cadence is roughly monthly across that window. The README includes a "Help Wanted" section asking for maintainers, reviewers and PR submissions, and notes that an independent review is required before a PR can be merged. That is worth reading as a statement about capacity: the project is asking for people, which usually means the current maintainers are the constraint on how fast issues and reviews move.
On licensing, the README states the package is released under the terms of the BSD license, with full details in the LICENSE file, and the pyproject classifier says "License :: OSI Approved :: BSD License". The repository metadata reports the license as NOASSERTION, which is a tooling artefact rather than a second licence; the LICENSE file is the authoritative text and is worth reading directly if your organisation has rules about which BSD variant it accepts. That is a description of what the files say, not legal advice.
Upgrade cost is the practical question. Each release can carry migrations for the oauth2_provider tables, and 3.4.0 changed a protocol default. The repository pins supported versions explicitly: Python 3.10 through 3.14 and Django 4.2 through 6.0 per the README, with oauthlib 3.2.2 or later in the requirements section and oauthlib >= 3.3.0 plus jwcrypto >= 1.5.0 in pyproject dependencies. A team on an older Django or Python has to move those first.
Editorial conclusion
Adopt Django OAuth Toolkit when your users, sessions and permissions already live in a Django project and you want the authorization server in the same process, database and deployment. Do not adopt it if you need a standalone identity product with its own admin surface and vendor support, or if you cannot take on migrations and token table growth. Before committing, verify that your Python and Django versions appear in the supported list, that your database can hold the oauth2_provider tables, and that the grant types you plan to expose are the ones the documentation covers for your release.
Frequently asked questions
Is there a library for OAuth in Python, and is Django OAuth Toolkit one?
Yes. Django OAuth Toolkit is an OAuth2 authorization server for Django, built on top of OAuthLib, and it provides the endpoints, models and token logic inside an existing Django project. It is aimed at Django teams rather than at Python projects in general.
Can Django OAuth Toolkit handle JWT authentication in Django?
The package depends on jwcrypto and lists oidc among its keywords, but the README does not document JWT access tokens or a JWT validation flow. The README's stated scope is OAuth2 token issuance and the resource server role, so check the full documentation on Read the Docs before assuming JWT support.
Is Django OAuth Toolkit a free OAuth provider?
It is released under the BSD license according to the README, and it is installed from PyPI with pip. You run it yourself inside your own Django deployment, so there is no hosted provider and no per-token fee, but you carry the operational work.
How do I do OAuth2 authentication in Python with Django OAuth Toolkit?
Install the package with pip, add oauth2_provider to INSTALLED_APPS, run your migrations, and include oauth2_provider.urls in your URLconf under a prefix such as o/. The README shows exactly those steps; the client registration and full authorization code exchange are covered in the Read the Docs documentation instead.
Community notes