Bump django-oauth-toolkit from 3.2.0 to 3.4.1

[dependabot]

Bumps django-oauth-toolkit from 3.2.0 to 3.4.1.

Release notes

Sourced from django-oauth-toolkit's releases.

3.4.1

This release is dominated by security hardening of redirect URI matching, token revocation and refresh token handling. Several entries below change behavior that was previously accepted, and they are spread across Fixed and Security: the "Upgrading to 3.4.1" section of the Upgrading guide collects everything you need to act on in one place, so start there. Of particular note: redirect URIs are now matched exactly per RFC 9700 §2.1, so a request may no longer carry query parameters, path parameters, credentials or a fragment that the registered URI does not have; REFRESH_TOKEN_EXPIRE_SECONDS, where set, is now enforced when a refresh token is presented rather than only by the cleartokens sweep; and the built-in templates now link a stylesheet shipped with the package instead of a CDN, so run collectstatic or the pages render unstyled.

Added

• #681 Redirect URI mismatches are now diagnosed on the oauth2_provider logger at DEBUG, reporting the requested URI, every registered candidate it was compared against, and which component of each one differed (scheme, hostname, port, path, query). The same detail is emitted for post_logout_redirect_uri and for the token endpoint's comparison against the URI recorded on the grant. The error response is unchanged: the registered URIs are never disclosed to the requester, only to the server's log. See "Debugging redirect URI mismatches" in the documentation. Note that AbstractApplication.redirect_uri_allowed() and post_logout_redirect_uri_allowed() now call the new check_redirect_to_uri_allowed() (same verdict, plus the mismatch reasons) instead of redirect_to_uri_allowed(), so code that wrapped or patched the latter to influence those methods must target the former.
• #634 A system check (oauth2_provider.W011) that warns when the AccessToken and RefreshToken models are swapped into different apps, and a new "Extending the token models" documentation section explaining how to swap the interrelated token models together.
• #1623 Documentation ("Content Security Policy and the authorization form") on completing the authorization-code flow under a strict form-action Content Security Policy, which Chromium enforces against the post-authorization redirect to the client's redirect_uri.
• #410 Documentation ("Resource scope syntax") clarifying that TokenHasResourceScope checks each required_scopes entry suffixed with the READ_SCOPE/WRITE_SCOPE setting value (defaults read/write, e.g. music:read, music:write), so a bare music scope is rejected; with the default settings-based scopes backend the suffixed scopes must be declared in SCOPES.
• #1157 An "Upgrading" documentation page collecting the breaking changes and upgrade steps for every release that needs them — 2.0, 3.0 and this release — linked from the documentation index, so upgrade guidance is discoverable outside the CHANGELOG. A release that asks nothing of you has no section there, so a gap between two versions is an answer rather than an omission.
• #452 Documentation ("Custom scopes backend") explaining how to replace the default settings-driven scopes backend via SCOPES_BACKEND_CLASS, including a worked model-based example that stores scopes in the database.
• #1045 Tutorial ("Managing applications and tokens in the Django admin") walking through the admin site for applications and issued tokens, including client-secret hashing, credential masking, and that tokens cannot be created by hand.
• #403 Translatable (gettext_lazy) verbose_name labels on every field of the Application, Grant, AccessToken, RefreshToken, IDToken and DeviceGrant models, so the Django admin and the authorization UI can be localized. Migration

... (truncated)

Changelog

Sourced from django-oauth-toolkit's changelog.

[3.4.1] - 2026-08-21

This release is dominated by security hardening of redirect URI matching, token revocation and refresh token handling. Several entries below change behavior that was previously accepted, and they are spread across Fixed and Security: the "Upgrading to 3.4.1" section of the Upgrading guide collects everything you need to act on in one place, so start there. Of particular note: redirect URIs are now matched exactly per RFC 9700 §2.1, so a request may no longer carry query parameters, path parameters, credentials or a fragment that the registered URI does not have; REFRESH_TOKEN_EXPIRE_SECONDS, where set, is now enforced when a refresh token is presented rather than only by the cleartokens sweep; and the built-in templates now link a stylesheet shipped with the package instead of a CDN, so run collectstatic or the pages render unstyled.

Added

• #681 Redirect URI mismatches are now diagnosed on the oauth2_provider logger at DEBUG, reporting the requested URI, every registered candidate it was compared against, and which component of each one differed (scheme, hostname, port, path, query). The same detail is emitted for post_logout_redirect_uri and for the token endpoint's comparison against the URI recorded on the grant. The error response is unchanged: the registered URIs are never disclosed to the requester, only to the server's log. See "Debugging redirect URI mismatches" in the documentation. Note that AbstractApplication.redirect_uri_allowed() and post_logout_redirect_uri_allowed() now call the new check_redirect_to_uri_allowed() (same verdict, plus the mismatch reasons) instead of redirect_to_uri_allowed(), so code that wrapped or patched the latter to influence those methods must target the former.
• #634 A system check (oauth2_provider.W011) that warns when the AccessToken and RefreshToken models are swapped into different apps, and a new "Extending the token models" documentation section explaining how to swap the interrelated token models together.
• #1623 Documentation ("Content Security Policy and the authorization form") on completing the authorization-code flow under a strict form-action Content Security Policy, which Chromium enforces against the post-authorization redirect to the client's redirect_uri.
• #410 Documentation ("Resource scope syntax") clarifying that TokenHasResourceScope checks each required_scopes entry suffixed with the READ_SCOPE/WRITE_SCOPE setting value (defaults read/write, e.g. music:read, music:write), so a bare music scope is rejected; with the default settings-based scopes backend the suffixed scopes must be declared in SCOPES.
• #1157 An "Upgrading" documentation page collecting the breaking changes and upgrade steps for every release that needs them — 2.0, 3.0 and this release — linked from the documentation index, so upgrade guidance is discoverable outside the CHANGELOG. A release that asks nothing of you has no section there, so a gap between two versions is an answer rather than an omission.
• #452 Documentation ("Custom scopes backend") explaining how to replace the default settings-driven scopes backend via SCOPES_BACKEND_CLASS, including a worked model-based example that stores scopes in the database.
• #1045 Tutorial ("Managing applications and tokens in the Django admin") walking through the admin site for applications and issued tokens, including client-secret hashing, credential masking, and that tokens cannot be created by hand.
• #403 Translatable (gettext_lazy) verbose_name labels on every field of the Application, Grant, AccessToken, RefreshToken, IDToken and DeviceGrant models, so the Django admin and the authorization UI can be localized. Migration

... (truncated)

Commits

• db6c4f5 chore: 3.4.1 release (#1820)
• 9c70975 fix: enforce device grant confirmation ownership (#1819)
• 28bf64c perf: revoke refresh token families as a set on reuse detection (#1810)
• f797b8a fix(validators): stop honoring revoked refresh tokens in the grace window (#1...
• 11024a0 chore(deps): bump cryptography in the uv group across 1 directory (#1807)
• 1e19d4d Log why a redirect URI failed to match (#1814)
• 4f18e0e feat(templates): serve default styles from a bundled stylesheet (#1815)
• ae05be9 feat(models): make model field labels translatable (#1812)
• 2b1a322 fix(models): associate Application validation errors with their fields (#1811)
• 0915396 fix(dcr): honour hashed token storage for registration access tokens (#1799)
• 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)