Skip to content

feat: add RFC 8707 Resource Indicators support#879

Draft
cohendvir wants to merge 2 commits into
ory:masterfrom
cohendvir:feat/rfc-8707-resource-indicators
Draft

feat: add RFC 8707 Resource Indicators support#879
cohendvir wants to merge 2 commits into
ory:masterfrom
cohendvir:feat/rfc-8707-resource-indicators

Conversation

@cohendvir
Copy link
Copy Markdown

@cohendvir cohendvir commented May 25, 2026

Adds support for RFC 8707 Resource Indicators in fosite.

Note: This PR stacks on #880 (copyright year bump). Please merge #880 first — once it lands on master, the diff here will show only the RFC 8707 changes.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 25, 2026

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 08b93e56-8fd9-4170-93cc-559ae26945e7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@CLAassistant
Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

cohendvir added 2 commits May 25, 2026 15:12
Implements RFC 8707 (Resource Indicators for OAuth 2.0) by parsing the standardized "resource" form parameter alongside the existing non-standard "audience" parameter. The "resource" values are validated per RFC 8707 §2 (absolute URI, no fragment) and merged into the RequestedAudience list, so they flow through fosite's existing audience binding pipeline (DefaultAudienceMatchingStrategy and the per-flow audience checks) and end up in the issued token's aud claim with no additional plumbing.

Motivation: the 2026 MCP (Model Context Protocol) spec mandates RFC 8707 to prevent confused-deputy attacks between MCP servers. Several public AS implementations now support it; this aligns fosite with the broader OAuth 2.1 / MCP ecosystem.

Changes: audience_strategy.go merges resource with audience and adds ValidateResourceIndicators helper; access_request_handler.go validates resource before populating RequestedAudience; new unit and integration tests cover merging, de-dup, and invalid input cases.

Backward compatibility: requests with only the "audience" parameter behave exactly as before. The "resource" parameter is opt-in.

Signed-off-by: cohendvir <dvir@honeybook.com>
@cohendvir cohendvir force-pushed the feat/rfc-8707-resource-indicators branch from 6560f1a to 54bfd0b Compare May 25, 2026 08:30
@james-d-elliott
Copy link
Copy Markdown
Contributor

Shouldn't this be in the authorize code / implicit auth handlers and refresh / client credentials / device code access handlers?

@james-d-elliott
Copy link
Copy Markdown
Contributor

Actually looking more closely it's similar to refresh flow, the values requested on the auth endpoint restrict what can be requested on the token endpoint, same for the original request in refresh flows.

The resource value(s) that is acceptable to an authorization server in fulfilling an access token request is at its sole discretion based on local policy or configuration. In the case of a refresh_token or authorization_code grant type request, such policy may limit the acceptable resources to those that were originally granted by the resource owner or a subset thereof. In the authorization_code case where the requested resources are a subset of the set of resources originally granted, the authorization server will issue an access token based on that subset of requested resources, whereas any refresh token that is returned is bound to the full original grant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants