v26.4.7
v26.4.7
Support resource indicators and MCP
Ory Hydra now supports OAuth 2.0 resource indicators (RFC 8707), enabling access tokens targeted to Model Context Protocol (MCP) servers.
Self-hosted Ory Hydra keeps resource indicators turned off by default. To turn them on, set
feature_flags.resource_indicators_enabled: true. We intend to remove this flag and turn resource indicators on for everyone
before April 1, 2027.
New Ory Network projects have resource indicators turned on. Existing projects keep them turned off until you turn on Enable
OAuth2 for MCP in the Ory Console OAuth2 general settings, or set
services.oauth2.config.feature_flags.resource_indicators_enabled to true through the project API.
MCP clients register through dynamic client registration (DCR). Set the MCP server URLs that these clients may request tokens for
in Default audiences in the Ory Console OpenID Connect settings, or with
services.oauth2.config.oidc.dynamic_client_registration.default_audience through the project API. Ory assigns this list when a
registration omits audience or sends null. Explicit audiences, including an empty list, take precedence. Dynamic client
registration updates keep their previous behavior and do not apply defaults. For self-hosted Ory Hydra, configure the list with
oidc.dynamic_client_registration.default_audience.
Breaking changes
While resource indicator validation is on, Hydra validates the previously ignored resource parameter. Values must be absolute
URIs without fragments and exact client audience allow-list entries. Authorization code exchange, device code exchange, and
refresh also require an exact entry in the existing grant. Invalid or unauthorized values fail with invalid_target; prefix
matches no longer suffice for resources.
If resources are requested, custom consent apps must include at least one approved exact URI from requested_resources in
grant_access_token_audience, even when consent is skipped. Apps may approve a subset of the requested resources. Granting none
of them causes the authorization flow to fail with invalid_target; no authorization code is issued. Only echoing
requested_access_token_audience can cause this failure because it does not include the requested resources.
In @ory/client, OAuth2Api.oAuth2Authorize now takes a request parameters object as its first argument and Axios request
options as its second. Replace oAuth2Authorize(options) with oAuth2Authorize({}, options). Both oAuth2Authorize and
oauth2TokenExchange accept resource as an array:
await oauth2.oAuth2Authorize({ resource: ["https://calendar.example.com"] }, options)
await oauth2.oauth2TokenExchange({
grantType: "authorization_code",
code,
redirectUri,
resource: ["https://calendar.example.com"],
})
In the functional OAuth2ApiFp API, oAuth2Authorize and oauth2TokenExchange take resource as the argument before options.
Read the resource indicator guide, the configuration instructions, and the dynamic client registration guide.
Upgrade order matters for this release if you run Hydra yourself
Upgrade to v26.4.4 before this release — do not skip it. Finish rolling out v26.4.4 on every Hydra instance before you apply this release's migrations; a process older than v26.4.4 that handles a client delete request against this release's schema leaves rows behind that nothing can clean up.
On PostgreSQL, apply the migrations in a quiet window. Each of the nine migrations requires an ACCESS EXCLUSIVE lock on both the
table it alters and hydra_client. Long-running transactions can delay these locks, causing new queries against the affected
tables to queue until the migration transaction finishes.
Rolling back re-adds database constraints that check every existing row, so a down migration fails while any token, consent
session, or login flow references a client ID that has no client row. Before rolling back, run hydra janitor --clients to finish
pending deletions, then delete the rows that still reference no client. The
revert guide
lists the tables and the statement to use.