Bump django-oauth-toolkit from 3.2.0 to 3.4.0

[dependabot]

Bumps django-oauth-toolkit from 3.2.0 to 3.4.0.

Release notes

Sourced from django-oauth-toolkit's releases.

3.4.0

The headline of this release is first-class support for the Model Context Protocol (MCP) authorization server role. MCP's authorization spec is built on a stack of modern OAuth RFCs, and this cycle landed the whole stack: Authorization Server Metadata (RFC 8414) and Protected Resource Metadata (RFC 9728) for discovery, Dynamic Client Registration (RFC 7591 / RFC 7592) and OAuth Client ID Metadata Documents (CIMD) so clients can register themselves, Resource Indicators (RFC 8707) for audience-bound access tokens, and the OAuth 2.0 Security Best Current Practice (RFC 9700) together with the RFC 9207 iss parameter. The RFC 9700 compliance gates double as a configurable OAuth 2.1 security posture — they can reject the implicit and password grants and enforce S256-only PKCE (legacy behavior by default in 3.4, scheduled to flip to compliant in 4.0). The new ALLOW_LOCALHOST_LOOPBACK setting smooths the ephemeral-port loopback callback used by native clients such as Claude Code, MCP Inspector, and mcp-remote.

Beyond MCP, the release adds a Django Ninja integration alongside the existing DRF support and support for RP-Initiated Registration, lifts the 255-character cap on refresh tokens (mirroring the access-token checksum scheme), makes cleartokens reclaim revoked refresh tokens sooner, and harmonizes Bearer Authorization header parsing across the middleware.

It also carries a batch of security fixes: an unauthenticated open redirect from the authorization endpoint (prompt=none), HS256 ID tokens being signed with the hashed client secret, cleartext tokens and codes exposed in the Django admin, client secrets written to debug logs, and predictable device-flow user_code generation. Longstanding operational bugs are fixed too, including a multi-database migrate deadlock (#1591) and duplicate unique indexes that broke fresh installs on Oracle and strict MySQL (#1656).

Before upgrading, read the breaking-changes section below: most items are makemigrations steps for swapped models, but applications using the HS256 signing algorithm now require hash_client_secret=False.

WARNING - POTENTIAL BREAKING CHANGES

• Applications using the HS256 signing algorithm must now be configured with hash_client_secret=False. Previously such applications signed ID tokens with the hashed client secret, producing tokens that relying parties could not verify. Application.clean() now raises a ValidationError for HS256 + hash_client_secret=True, and Application.jwk_key raises ImproperlyConfigured at signing time if the secret is hashed. To migrate an affected application, recreate it (or reset its secret) with hash_client_secret=False so the plaintext secret is stored and can be used as the shared HMAC key.
• Changes to the AbstractRefreshToken model require doing a manage.py migrate after upgrading.
• If you use a swapped refresh token model (OAUTH2_PROVIDER_REFRESH_TOKEN_MODEL) you will need to update your custom model with manage.py makemigrations. If your table already contains refresh tokens you must also backfill token_checksum with a data migration — adapt the batched backfill loop from forwards_func in oauth2_provider/migrations/0015_refreshtoken_token_checksum.py (dropping its swapped-model guard, the early return, and resolving your own model instead) and keep the same operation order: add nullable checksum → drop the old ("token", "revoked") unique constraint → widen token to TextField → backfill → make checksum non-nullable → add the ("token_checksum", "revoked") unique constraint.
• If you use a swapped application model (OAUTH2_PROVIDER_APPLICATION_MODEL), run

... (truncated)

Changelog

Sourced from django-oauth-toolkit's changelog.

[3.4.0] - 2026-07-23

The headline of this release is first-class support for the Model Context Protocol (MCP) authorization server role. MCP's authorization spec is built on a stack of modern OAuth RFCs, and this cycle landed the whole stack: Authorization Server Metadata (RFC 8414) and Protected Resource Metadata (RFC 9728) for discovery, Dynamic Client Registration (RFC 7591 / RFC 7592) and OAuth Client ID Metadata Documents (CIMD) so clients can register themselves, Resource Indicators (RFC 8707) for audience-bound access tokens, and the OAuth 2.0 Security Best Current Practice (RFC 9700) together with the RFC 9207 iss parameter. The RFC 9700 compliance gates double as a configurable OAuth 2.1 security posture — they can reject the implicit and password grants and enforce S256-only PKCE (legacy behavior by default in 3.4, scheduled to flip to compliant in 4.0). The new ALLOW_LOCALHOST_LOOPBACK setting smooths the ephemeral-port loopback callback used by native clients such as Claude Code, MCP Inspector, and mcp-remote.

Beyond MCP, the release adds a Django Ninja integration alongside the existing DRF support and support for RP-Initiated Registration, lifts the 255-character cap on refresh tokens (mirroring the access-token checksum scheme), makes cleartokens reclaim revoked refresh tokens sooner, and harmonizes Bearer Authorization header parsing across the middleware.

It also carries a batch of security fixes: an unauthenticated open redirect from the authorization endpoint (prompt=none), HS256 ID tokens being signed with the hashed client secret, cleartext tokens and codes exposed in the Django admin, client secrets written to debug logs, and predictable device-flow user_code generation. Longstanding operational bugs are fixed too, including a multi-database migrate deadlock (#1591) and duplicate unique indexes that broke fresh installs on Oracle and strict MySQL (#1656).

Before upgrading, read the breaking-changes section below: most items are makemigrations steps for swapped models, but applications using the HS256 signing algorithm now require hash_client_secret=False.

WARNING - POTENTIAL BREAKING CHANGES

• Applications using the HS256 signing algorithm must now be configured with hash_client_secret=False. Previously such applications signed ID tokens with the hashed client secret, producing tokens that relying parties could not verify. Application.clean() now raises a ValidationError for HS256 + hash_client_secret=True, and Application.jwk_key raises ImproperlyConfigured at signing time if the secret is hashed. To migrate an affected application, recreate it (or reset its secret) with hash_client_secret=False so the plaintext secret is stored and can be used as the shared HMAC key.
• Changes to the AbstractRefreshToken model require doing a manage.py migrate after upgrading.
• If you use a swapped refresh token model (OAUTH2_PROVIDER_REFRESH_TOKEN_MODEL) you will need to update your custom model with manage.py makemigrations. If your table already contains refresh tokens you must also backfill token_checksum with a data migration — adapt the batched backfill loop from forwards_func in oauth2_provider/migrations/0015_refreshtoken_token_checksum.py (dropping its swapped-model guard, the early return, and resolving your own model instead) and keep the same operation order: add nullable checksum → drop the old ("token", "revoked") unique constraint → widen token to TextField → backfill → make checksum non-nullable → add the ("token_checksum", "revoked") unique constraint.
• If you use a swapped application model (OAUTH2_PROVIDER_APPLICATION_MODEL), run

... (truncated)

Commits

• 48132d3 chore: 3.4.0 release (#1764)
• 2c34e2a docs: replace m2r2 with myst-parser to drop the mistune dependency (#1761)
• 76cc44b chore(deps): bump cryptography in the uv group across 1 directory (#1760)
• a5e5032 docs: migrate m2r to m2r2 and build docs in CI (#1758)
• ea8f2f0 chore(deps): bump the npm_and_yarn group across 1 directory with 7 updates (#...
• de8e735 Fix 500 error when client_id or username contains a NUL byte (#1754)
• 0c9240b Fix ReadWriteScopedResourceMixin.new() rejecting any constructor argument...
• c5f2b9d Add section in docs about migrations testing (#1717)
• 11b36e4 Extract HttpRequest creation to own method (#1660)
• 82fc862 Fix wildcard redirect URI validation for Netlify double-dash deploy previews ...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)