Support RFC 8707 Resource Indicators (getResourceServerInfo callback) #365

New issue

Open

opened 2026-04-10 01:06:18 -05:00 by nkissick-del · 1 comment

nkissick-del commented

2026-04-10 01:06:18 -05:00

(Migrated from github.com)

Describe your idea for an enhancement:

VoidAuth's underlying node-oidc-provider exposes a features.resourceIndicators hook, but getResourceServerInfo is not implemented. This means the resource parameter sent by OAuth clients (per RFC 8707) is silently ignored and tokens are issued without an aud claim scoped to the requested resource server.

It would be useful if VoidAuth allowed administrators to configure allowed resource URIs (e.g. per OIDC app), so that:

The resource parameter is validated against an allowlist
Issued tokens include an aud claim matching the resource origin
Tokens can optionally be scoped per resource server

This is relevant for MCP (Model Context Protocol) deployments where clients like claude.ai send resource=https://mcp.example.com in the authorization request, and for any multi-service setup where audience-restricted tokens improve security.

Describe alternatives you've considered:

Ignore it — this is what I'm doing now. VoidAuth silently drops the resource parameter and issues unscoped tokens. Works fine functionally, but tokens aren't audience-restricted.
Strip the parameter at the reverse proxy — nginx rewrite to remove resource from query args before forwarding to VoidAuth. Same outcome as above but more explicit.
Use a different OIDC provider — not practical when VoidAuth handles ProxyAuth + OIDC in one package.

Additional context:

https://datatracker.ietf.org/doc/html/rfc8707
https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#featuresresourceindicators
The MCP specification's OAuth flow sends resource by default, so this will become more common as MCP adoption grows

### Describe your idea for an enhancement: VoidAuth's underlying node-oidc-provider exposes a features.resourceIndicators hook, but getResourceServerInfo is not implemented. This means the resource parameter sent by OAuth clients (per RFC 8707) is silently ignored and tokens are issued without an aud claim scoped to the requested resource server. It would be useful if VoidAuth allowed administrators to configure allowed resource URIs (e.g. per OIDC app), so that: 1. The resource parameter is validated against an allowlist 2. Issued tokens include an aud claim matching the resource origin 3. Tokens can optionally be scoped per resource server This is relevant for MCP (Model Context Protocol) deployments where clients like claude.ai send resource=https://mcp.example.com in the authorization request, and for any multi-service setup where audience-restricted tokens improve security. ### Describe alternatives you've considered: - **Ignore it** — this is what I'm doing now. VoidAuth silently drops the resource parameter and issues unscoped tokens. Works fine functionally, but tokens aren't audience-restricted. - **Strip the parameter at the reverse proxy** — nginx rewrite to remove resource from query args before forwarding to VoidAuth. Same outcome as above but more explicit. - **Use a different OIDC provider** — not practical when VoidAuth handles ProxyAuth + OIDC in one package. ### Additional context: - https://datatracker.ietf.org/doc/html/rfc8707 - https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#featuresresourceindicators - The MCP specification's OAuth flow sends resource by default, so this will become more common as MCP adoption grows

notquitenothing commented

2026-04-15 19:05:44 -05:00

(Migrated from github.com)

Unfortunately I have no experience with this feature of OIDC. If this can be implemented without breaking existing flows I would encourage anyone to take a look and submit a PR if they can get it working.