Bump doorkeeper from 5.9.6 to 5.9.9

[dependabot]

Bumps doorkeeper from 5.9.6 to 5.9.9.

Release notes

Sourced from doorkeeper's releases.

v5.9.9

• Fix: AuthorizedApplicationsController now answers 401 Unauthorized instead of running with a nil resource owner, which listed and revoked every token that has no resource owner — the ones the client credentials flow issues. Affected host applications are those whose resource_owner_authenticator answers nil without halting the request itself; the generated initializer's example redirects and is not affected.
• Fix: AuthorizationsController#destroy now validates the client and redirect URI before producing the deny response, and renders — never redirects — when validation fails. Previously the deny path performed no OAuth-layer validation at all, allowing an open redirect to an attacker-controlled origin with the OAuth state attached. Also reject unregistered response_type values on the authorization endpoint rather than resolving them through the constantize fallback.
• Fix: refuse redirect URIs with a script scheme (javascript, vbscript, data) both when an application is registered and at authorization time, regardless of forbid_redirect_uri. Such a URI is never a legitimate redirection endpoint, and with response_mode=form_post it became the action of the auto-submitting form the authorization server renders on its own origin. Already stored records with such a URI are now refused with invalid_redirect_uri before the consent screen is shown.
• #1938 Fix: a request body ActionDispatch cannot parse (malformed JSON under a JSON content type, say) no longer raises ActionDispatch::Http::Parameters::ParseError out of Doorkeeper::OAuth::Token.from_request and doorkeeper_token. Since 5.9.7 the RFC 6750 §2 multi-method check read the body on every request, so such a request raised even when it carried a valid Bearer header. The body is now treated as carrying no token, the same way ActionDispatch's own #filtered_parameters treats that error.

v5.9.7

• Refuse requests that transmit an access token by more than one method (RFC 6750 §2), instead of silently authorizing with the first configured access_token_methods entry that matched and discarding the other tokens. Such a request now fails closed as carrying no usable token (401 invalid_token); no calling contract changes. The form-encoded body (§2.2) and the URI query (§2.3) count as two methods even though Rails and Rack merge them into a single params hash. The same token repeated across two methods is refused too — §2 forbids the second method, not a disagreement between the two — and a custom callable extractor in access_token_methods keeps the historical first-wins behavior and is never invoked more than once. (The strict invalid_request (400) answer §3.1 prescribes ships with Doorkeeper 6.0.)
• #1925 Internal: pin the development dependency on json below 3.0. json 3 removed the positional options Hash from JSON.parse and the quirks_mode option from JSON.generate, both of which Active Support still uses, so the suite could not run on any supported Rails version.

Changelog

Sourced from doorkeeper's changelog.

Changelog

See https://github.com/doorkeeper-gem/doorkeeper/wiki/Migration-from-old-versions for upgrade guides.

User-visible changes worth mentioning.

main

• [#PR ID] Description of the change.

6.0.0.rc2

Please make sure you read the Upgrade guides and changelog below before the update since this version includes breaking changes.

• #1951 Fix: the built gem no longer contains vendor/bundle. The gemspec globed all of vendor/, which swept in the bundle installed by the release workflow; 6.0.0.rc1 is a 44.4 MB download against 154 KB for 6.0.0.beta2.
• Fix: AuthorizedApplicationsController now answers 401 Unauthorized instead of running with a nil resource owner, which listed and revoked every token that has no resource owner — the ones the client credentials flow issues. Affected host applications are those whose resource_owner_authenticator answers nil without halting the request itself; the generated initializer's example redirects and is not affected.
• Fix: AuthorizationsController#destroy now validates the client and redirect URI before producing the deny response, and renders — never redirects — when validation fails. Previously the deny path performed no OAuth-layer validation at all, allowing an open redirect to an attacker-controlled origin with the OAuth state attached. Also reject unregistered response_type values on the authorization endpoint rather than resolving them through the constantize fallback.
• Fix: refuse redirect URIs with a script scheme (javascript, vbscript, data) both when an application is registered and at authorization time, regardless of forbid_redirect_uri. Such a URI is never a legitimate redirection endpoint, and with response_mode=form_post it became the action of the auto-submitting form the authorization server renders on its own origin. Already stored records with such a URI are now refused with invalid_redirect_uri before the consent screen is shown.
• #1932 Fix: keep the scope originally granted by the resource owner on refresh tokens (RFC 6749 §6), so a chain narrowed on one refresh can return to its granted scope. Tracked in a new refresh_token_scopes column; existing installations opt in with rails generate doorkeeper:refresh_token_scopes.
• #1933 Warn at boot when the implicit or password grant flow is enabled: both are deprecated by RFC 9700 (OAuth 2.0 Security BCP) and removed from OAuth 2.1, and may be removed in a future Doorkeeper release.
• #1915 Fix: fetching a client's jwks_uri now falls back to the other addresses returned by DNS when the first one cannot be connected to.
• #1934 The refresh_token grant now consults custom_access_token_expires_in (with Doorkeeper::OAuth::REFRESH_TOKEN as the context grant type) for the TTL of the refreshed access token. A callable that returns nil for this grant, or no callable at all, keeps inheriting the TTL of the token being refreshed as before. A callable that returns a value unconditionally now applies to refreshes as well.
• #1935 Add opt-in public_client_access_token_expires_in configuration option: a ceiling for the lifetime of access tokens issued to public (non-confidential) clients by any grant, refresh_token included, as OAuth 2.1 Section 2.4 requires the exposure of tokens issued to unauthenticated clients to be limited. Confidential clients are not affected.
• #1938 Fix: a request body ActionDispatch cannot parse (malformed JSON under a JSON content type, say) no longer raises ActionDispatch::Http::Parameters::ParseError out of Doorkeeper::OAuth::Token.from_request and doorkeeper_token. Since 5.9.7 the RFC 6750 §2 multi-method check read the body on every request, so such a request raised even when it carried a valid Bearer header. The body is now treated as carrying no token, the same way ActionDispatch's own #filtered_parameters treats that error.
• #1950 Document hash_token_secrets / hash_application_secrets fallback: as a migration-period setting that should be removed once every row is hashed, and warn at boot for as long as one is configured. While a :plain fallback is active the stored value is itself a valid credential, so those columns need protecting as carefully as plaintext ones.
• #1953 Fix: public_client_access_token_expires_in now also holds under reuse_access_token and with String TTLs, and the refresh_token grant hands custom_access_token_expires_in and resource_indicator_validator what every other grant does.

6.0.0.rc1

Please make sure you read the Upgrade guides and changelog below before the update since this version includes breaking changes.

• Require Ruby >= 3.2 in the gemspec, matching the CI matrix (3.2 / 3.3 / 3.4 / 4.0). Ruby 2.7, 3.0 and 3.1 have reached end-of-life.
• Fix: the client_secret_basic strategy now requires a client_id sent in the request body to name the same client as the Authorization: Basic header — the RFC 7521 §4.2 agreement check private_key_jwt already applies to an assertion's issuer. A request presenting Basic credentials for one client and a client_id for another was authenticated as the Basic client, silently discarding the other identity. A bare client_id is not a client authentication method of its own, so the RFC 6749 §2.3 multiple-methods check does not (and should not) count it.
• #1906 Internal: exempt Doorkeeper::Config from Metrics/ClassLength with a directive on the class itself instead of raising the cop's global ceiling, so adding a configuration option no longer trips the limit.
• #1907 Fix: a resource parameter no longer produces a 500 at the authorization endpoint when resource_indicator_validator is configured without the doorkeeper:resource_indicators migration. Such a request is now answered with server_error, as the token endpoint already did, and the missing migration is warned about at boot.
• #1909 Add Rails 8.1 to CI test matrix.
• #1910 Add opt-in validate_client_before_resource_owner_authentication configuration option: the authorization endpoint validates client_id and redirect_uri before authenticating the resource owner, so users are not sent through login for a request that can only fail.
• #1916 Fix broken Coveralls coverage reporting.
• #1918 The api_only controller specs no longer load the real controller sources, which detached the coverage of every other example that ran them and made the reported coverage depend on the random example order.
• #1923 Fix: the fallback secret upgrade no longer writes the matched secret back over a value stored in the meantime, which could undo a concurrent #renew_secret and leave the superseded secret valid. Active Record writes the upgrade conditionally on the column still holding the value that matched; other ORMs can implement the new write_upgraded_secret hook. The Active Record write is a single update_all statement, so model callbacks and validations no longer run on this upgrade (timestamps and optimistic locking are still maintained).
• #1925 Internal: pin the development dependency on json below 3.0. json 3 removed the positional options Hash from JSON.parse and the quirks_mode option from JSON.generate, both of which Active Support still uses, so the suite could not run on any released Rails version.
• #1926 [BREAKING] Fix: private_key_jwt client authentication no longer accepts an audience derived from the request's Host header, which let a client assertion minted for another authorization server be replayed here. A server that configures neither issuer nor Rails' default_url_options[:host] now has no acceptable audience and refuses every assertion, and is warned about it at boot.
• [BREAKING] Refuse requests that transmit the access token by more than one method (RFC 6750 §2) with an invalid_request error, instead of silently authorizing with the first method that yielded a token and discarding the rest. The form-encoded body (§2.2) and the URI query (§2.3) count as two methods even though Rails and Rack merge them into a single params hash, and the same token repeated across two methods is refused too — §2 forbids the second method, not a disagreement between the two.
  • Only the built-in extraction methods take part in the check; a custom callable in access_token_methods keeps the historical first-wins behavior and is never invoked more than once.
  • Doorkeeper::OAuth::Token.from_request / .authenticate raise Doorkeeper::Errors::MultipleAccessTokenMethods. Doorkeeper.authenticate and every doorkeeper_token helper (Rails, Grape, and Doorkeeper's own controllers) keep their token-or-nil contract, so doorkeeper_authorize! renders the refusal through a new doorkeeper_bad_request_render_options(error:) hook (head 400 unless you override it).
  • Upgrade note: under handle_auth_errors :raise these requests raise Doorkeeper::Errors::InvalidRequest, a sibling of Doorkeeper::Errors::InvalidToken rather than a subclass — an existing rescue Doorkeeper::Errors::InvalidToken does not cover it.

... (truncated)

Commits

• 6f65d41 Backport gemspec to avoid vendor/bundle
• 1879ce4 Release 5.9.9 🎉
• 9403233 Merge commit from fork
• 6d711eb Merge commit from fork
• 7504992 Refuse redirect URIs with a script scheme
• de57e75 Merge commit from fork
• 0960bd7 Merge back release workflow for 5.9 branch
• 9cafb36 Validate the client and redirect URI on the authorization deny path
• f6ec046 Refuse authorized applications requests with no resource owner
• e72e53f Merge pull request #1939 from doorkeeper-gem/chore/bump-5.9.8
• 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)

[greptile-apps]

PR author is in the excluded authors list.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	gem/​doorkeeper@​5.9.6 ⏵ 5.9.9	+1

View full report