django-oauth-toolkit

Django OAuth Toolkit (DOT) is an OAuth 2.0 authorization server built directly into Django, giving teams the endpoints, models, and admin integration needed to issue and manage OAuth2 tokens without standing up a separate identity service. It wraps the RFC-compliant OAuthLib library with Django-native models (Application, Grant, AccessToken, RefreshToken, IDToken), views, and migrations, and can equally act as a resource server that protects a Django or Django REST Framework API with token introspection.

Beyond the core OAuth2 grant types, the toolkit implements a wide span of adjacent specs out of the box: OpenID Connect Core and Discovery, PKCE (required by default), RFC 8414 authorization server metadata, RFC 9728 protected resource metadata, RFC 9126 pushed authorization requests, RFC 8628 device authorization grant, and RFC 7591/7592 dynamic client registration. As of 3.4.0 it also implements the authorization-server role required by the Model Context Protocol (MCP) authorization specification, making it a common choice for teams standing up MCP-compatible auth in front of a Django backend.

What You Get

• A full OAuth 2.0 authorization server (authorization code, client credentials, device, and refresh grants) implemented on top of OAuthLib for RFC compliance
• OpenID Connect Core and Discovery support, including ID tokens and the standard /.well-known/openid-configuration metadata endpoint
• PKCE enforced by default, plus RFC 8414/9728 metadata discovery, RFC 9126 pushed authorization requests, and RFC 8628 device flow for input-constrained clients
• Model Context Protocol (MCP) authorization-server support added in 3.4.0, including dynamic client registration (RFC 7591/7592) and Client ID Metadata Documents
• A separable resource-server mode with an RFC 7662 introspection endpoint, so the authorization server and API server can run as distinct Django deployments
• Django admin integration and swappable model base classes (AbstractApplication, AbstractAccessToken, etc.) for teams that need to extend the token/application schema

Common Use Cases

• Turning an internal Django app into an OAuth2 identity provider for first- and third-party client applications
• Protecting a Django REST Framework or django-ninja API with bearer tokens instead of session auth
• Standing up an MCP-compliant authorization server in front of a Django backend for AI agent/tool access
• Splitting authorization and resource servers across services using the token-introspection flow
• Supporting device-flow login for CLIs, TVs, or other browserless clients against an existing Django user base

Under The Hood

Architecture The package is organized as three cooperating layers under oauth2_provider/: authorization_server/ (the OAuth2/OIDC issuing side — views, forms, DCR, CIMD, pushed authorization requests, and an oidc/ subpackage), resource_server/ (token validation via introspection, with its own middleware, backends, and www_authenticate.py), and core/ (shared OAuthLib backend glue, scopes, throttling, and RFC 7523 JWT-assertion support). models.py defines abstract base models (AbstractApplication, AbstractGrant, AbstractAccessToken, AbstractRefreshToken, AbstractIDToken, AbstractDeviceGrant, AbstractPushedAuthorizationRequest) with concrete subclasses, letting consumers swap in custom models via Django’s standard AUTH_USER_MODEL-style settings without forking the library. Because the authorization and resource concerns are physically separated into their own packages, a project can install only the resource-server half when the authorization server lives in a different Django deployment.

Tech Stack Built on Django 4.2 through 6.0 and Python 3.10-3.14, with OAuthLib 3.3+ doing the RFC-level protocol work, jwcrypto for JWT/JOSE handling (ID tokens, private_key_jwt/client_secret_jwt assertions), and requests/urllib3 for outbound calls such as safe URL fetching for client metadata documents. The project uses uv for dependency and workspace management (a tests/app/idp sub-project is a real Django app used as an identity-provider fixture), tox to matrix-test across Django/Python/database combinations (SQLite, PostgreSQL, MySQL, including primary/replica topologies), and ruff for linting.

Code Quality The test suite spans 71 test_*.py modules plus a dedicated tests/e2e/ black-box compliance suite that runs against a live server and is organized by RFC/spec (markers like spec_rfc6749, spec_rfc7636, spec_oidc_core, spec_browser_rp), including Playwright-driven browser tests against a SvelteKit relying-party app for cross-site cookie behavior. pytest-xdist parallelizes the in-process suite with --dist loadfile to respect tests that mutate process-global settings. CI (.github/workflows/test.yml) runs the tox matrix plus a separate ruff check, and the project maintains a documented security-disclosure process with GitHub private vulnerability reporting.

What Makes It Unique Most Django OAuth libraries stop at RFC 6749 core grants; this one keeps pace with the current OAuth/OIDC specification surface — PKCE-by-default, RFC 8414/9728 metadata discovery, RFC 9126 PAR, RFC 8628 device flow, and RFC 7591/7592 dynamic client registration are all implemented and spec-tested, not just documented as ideas. Its early, first-class support for the Model Context Protocol’s authorization requirements is notable given how new that spec is, positioning the toolkit as infrastructure for AI-agent auth rather than only human-facing OAuth flows.