3.4.0 Released! Adding MCP, OAuth 2.1

[dopry]

🎉 3.4.0 was released on 2026-07-23 🎉

with support for running as an MCP Authorization Server and OAuth 2.1 compatible configuration options. See the Changelog for more details, https://github.com/django-oauth/django-oauth-toolkit/releases/tag/3.4.0.

Looking forward

I'm taking on a more active role maintaining DOT. As a part of that I've been strategizing about what DOT needs to stay relevant going forward and to grow the community. I've completed a competitive market analysis and architectural review which have been enlightening.

I believe DOT is mostly used for its Resource Server features with DRF. That's the installed base. The AS side is where it's underinvested, and MCP is what's making that matter now. I believe it isn't seeing adoption as an AS because the AS data model predates most of the modern spec surface, and several specs are hard to implement cleanly against it. ADR 0001 addresses this directly. My hypothesis is that modernizing the AS and bringing it up to par with competing authorization servers, and expanding on the Resource Server functionality, will revitalize the project and increase adoption.

The competitive analysis produced the following tables, which help me understand where DOT sits in the market. Note that 3.4.0 introduced the OAuth 2.1 and MCP authorization support, so we are actively moving toward feature parity. The first table focuses on what I'm calling profiles (suites of specifications), while the second focuses on individual specifications.

Gap Analysis by Profile

Legend: ✅ Meets · 🟡 Partial · 🟣 Enterprise add-on · ❌ Gaps · N/A (role doesn't apply). Point-in-time 2026-07; DOT scored from source.

Profile / role	DOT	Authlib	Keycloak	Ory Hydra	WSO2	Okta	Auth0
OAuth 2.0 (classic)	✅	✅	✅	✅	✅	✅	✅
OAuth 2.1	✅	🟡	✅	✅	🟡	🟡	🟡
OpenID Connect	✅	✅	✅	✅	✅	✅	✅
Native apps (RFC 8252)	🟡	🟡	🟡	✅	🟡	✅	✅
FAPI 2.0	❌	❌	✅	❌	✅	❌	🟣
MCP authorization	✅	❌	🟡	❌	🟡	❌	🟡
Resource-server role	✅	✅	N/A	N/A	N/A	N/A	N/A
Client / relying-party role	N/A	🟡	N/A	N/A	N/A	N/A	N/A

Gap Analysis by Specification

Legend: ✅ Full · ⚙ Opt-in (off by default) · 🟡 Partial · 🟣 Add-on/plugin · ❌ None · ❓ Unverified. Included in = profiles the spec belongs to — bold = required, plain = optional. Point-in-time 2026-07; DOT scored from source.

Specification	Included in	DOT	Authlib	Keycloak	Ory Hydra	WSO2	Okta	Auth0
RFC 6749 — OAuth 2.0 core	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, Native, RP, RS	✅	✅	✅	✅	✅	✅	✅
— Implicit grant (deprecated)	OAuth 2.0, OIDC	✅	✅	✅	✅	✅	✅	✅
— Resource-owner password (deprecated)	OAuth 2.0	✅	✅	❌	✅	❌	✅	✅
RFC 6750 — Bearer usage	all	✅	✅	✅	✅	✅	✅	✅
RFC 7009 — Revocation	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, RP	✅	✅	✅	✅	✅	✅	🟡
RFC 7636 — PKCE	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, Native, RP	✅	✅	✅	✅	✅	✅	✅
RFC 7662 — Introspection	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, RS	✅	✅	✅	✅	✅	✅	❌
RFC 8252 — Native apps	OAuth 2.0, OAuth 2.1, MCP, Native, RP	🟡	❌	🟡	✅	🟡	✅	✅
RFC 8414 — AS metadata	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, Native, RP, RS	✅	✅	✅	✅	✅	✅	✅
RFC 8628 — Device grant	OAuth 2.0, OAuth 2.1, MCP, Native	✅	✅	✅	✅	✅	✅	✅
RFC 7591 — Dynamic client registration	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, RP	⚙	✅	✅	✅	✅	✅	✅
RFC 7592 — DCR management	OAuth 2.0, MCP, RP	⚙	✅	✅	✅	✅	✅	❌
RFC 7519 — JWT	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, RP, RS	🟡	✅	✅	✅	✅	✅	✅
RFC 7523 — private_key_jwt	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, RP	❌	✅	✅	✅	✅	✅	✅
RFC 9068 — at+jwt access tokens	OAuth 2.0, OAuth 2.1, FAPI, MCP, RS	❌	✅	🟡	🟡	✅	🟡	✅
RFC 9126 — PAR	OAuth 2.0, OAuth 2.1, FAPI, MCP, RP	❌	❌	✅	❌	✅	✅	🟣
RFC 9396 — RAR	OAuth 2.0, OAuth 2.1, FAPI, MCP	❌	❌	❌	❌	✅	❓	🟣
RFC 9449 — DPoP	OAuth 2.0, OAuth 2.1, FAPI, MCP, RP, RS	❌	❌	✅	❌	✅	✅	✅
RFC 8705 — mTLS client auth	OAuth 2.0, OAuth 2.1, FAPI, RS	❌	❌	✅	❌	✅	❌	🟣
RFC 8707 — Resource indicators	OAuth 2.0, OAuth 2.1, FAPI, MCP, RP, RS	✅	❌	🟡	❌	❓	❌	🟡
RFC 9728 — Protected resource metadata	OAuth 2.0, OAuth 2.1, FAPI, MCP, RP, RS	✅	❌	🟡	❌	❓	❓	🟡
RFC 9700 — Security BCP	OAuth 2.0, OAuth 2.1, OIDC, FAPI, MCP, Native, RP, RS	✅	🟡	🟡	🟡	🟡	🟡	🟡
OIDC Core	OIDC, FAPI, RP	⚙	✅	✅	✅	✅	✅	✅
OIDC Discovery	OIDC, FAPI, RP	⚙	✅	✅	✅	✅	✅	✅
OIDC Dynamic Registration	OIDC, MCP, RP	🟡	✅	✅	✅	✅	✅	✅
OIDC RP-Initiated Logout	OIDC, RP	⚙	✅	✅	✅	✅	✅	✅
OIDC Session Management	OIDC, RP	❌	❌	✅	❌	✅	❓	🟡
OIDC Front-Channel Logout	OIDC, RP	❌	❌	✅	✅	✅	✅	✅
OIDC Back-Channel Logout	OIDC, RP	❌	❌	✅	✅	✅	❌	🟣
CIBA	OIDC, FAPI	❌	❌	✅	❌	✅	🟡	🟣
CIMD — Client ID Metadata Document (draft)	MCP, RP	🟡	❌	🟡	❌	❓	❌	❌

Architectural Review

The Architectural Review has identified issues with the data model in the AS that need to be addressed, and issues in the code structuring that bundle Authorization and Resource Server code in the same modules. There are plans in motion to address both.

ADR 0001 seeks to address shortcomings in the data model that will resolve structural blockers to implementing the full suite of specifications above. It is ongoing work at the moment.

There is an open PR to reorganize the modules to be grouped by role to minimize the surface area imported in each role and to make clear to developers exactly what component they're working with. I get tripped up by this context and it is a recurring theme in the issue queue.

The work here is ongoing. I am updating it as I triage the issue queue and work on bugs.

Roadmap

Right now I have a broad strokes Roadmap which is reflected in the current milestones.

3.4.0 I was feature focused, I chose MCP as a primary focus. MCP requires OAuth 2.1 with PKCE for remote servers, there was demand, and contributors had already opened PRs. It was the clearest place to turn spec work we already had into something people need now.

3.4.1 - I want to use this release to clean up the bugs in the issue queue and to inform architectural decisions for 4.x.

3.x - these will be feature releases that won't conflict heavily with the breaking changes being planned for 4.x in ADR 0001, and refactorings with deprecated backwards compatibility layers that will be removed in 4.x.

4.x - this will land the major model refactors from ADR 0001 where I plan to resolve circular deps between tokens, audit history, token security, scope tracking and narrowing, performance, etc. These are issues that are impossible or hacky to implement with the current data model. This series will continue with feature implementation, with a plan to complete the OIDC, FAPI 2.0, and Native feature suites as much as possible, and to begin development of the Relying Party namespace in order to better compete with django-allauth and Authlib.

Conclusion

There is a plan, there is movement. It is a lot. We welcome participation. We want to build a Python competitor to closed source and SaaS Authorization Servers that can hold its place in the market. We've been moving fast.

PRs should arrive with tests passing, lint clean, and the obvious review comments already addressed. How you get there is up to you. I've been running an agent to do the work and using copilot to do adversarial review, working PRs until there are no comments. I even added a claude skill to do this. It's been very effective at identifying bugs and getting work done.

Help Wanted

We'd really like to find co-maintainers who have capacity to actively help with the project. If you have years of experience with OAuth and Django, and are obsessive about security and code quality, hit me up. The general roadmap to becoming a maintainer is implement features, fix bugs, review PRs, and earn trust.