Bug Description

The MCP OAuth implementation has an internal inconsistency

• /.well-known/oauth-protected-resource/mcp-server/http advertises the resource as a URL: ${baseUrl}/mcp-server/http.
• The /mcp-oauth/authorize endpoint enforces (via zod URL validation) that any incoming resource parameter must be a URL.
• The same server, however, issues access tokens with aud="mcp-server-api" — a non-URL literal hardcoded in mcp-oauth-token.service.ts.

In other words, the same endpoint that just issued a token would refuse the value of that token's aud claim if a client replayed it as a resource parameter on a subsequent authorize call

The advertised resource format and the issued audience format are inconsistent within the same server.

This breaks any client that follows the OAuth 2.1 / RFC 8707 expectation that an issued token's audience should reflect the requested resource — for example, a MCP gateway that learns the verified token's audience and uses it as the resource value for later authorization requests on behalf of other users.

To Reproduce

1. Complete an OAuth 2.1 flow against the n8n MCP server with resource=${baseUrl}/mcp-server/http (URL form, as required by the authorize endpoint).
2. Inspect the returned access token. Its aud claim is "mcp-server-api", not the URL.
3. Fetch /.well-known/oauth-protected-resource/mcp-server/http. Its resource field is ${baseUrl}/mcp-server/http.
4. Replay the token's aud value as the resource parameter on a new authorize request. The same authorize endpoint rejects it with HTTP 400: {"error":"invalid_request","error_description":[{"code":"invalid_format","format":"url","path":["resource"],"message":"Invalid URL"}]}.

Expected behavior

The issued aud claim should be consistent with the advertised resource URL.

• Set aud to the canonical resource URL (${baseUrl}/mcp-server/http) so the value the server advertises, the value the authorize endpoint accepts as resource, and the value the issued token carries are all aligned.
• Existing tokens with the legacy "mcp-server-api" audience can be honored at verification time during a transition window (RFC 7519 permits multi-value audiences and most JWT verifiers accept array forms), so this can be done without forcing immediate re-authentication of in-flight tokens.

Debug Info

Debug info

core

• n8nVersion: 2.19.5
• platform: docker (self-hosted)
• nodeJsVersion: 24.14.1
• nodeEnv: production
• database: postgres
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: 90d47e3d-ab99-4a18-b06b-871df39c4aaa

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 720 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/147.0.0.0 safari/537.36
• isTouchDevice: false

Generated at: 2026-05-08T03:15:26.701Z

Operating System

Linux

n8n Version

2.19.5

Node.js Version

22.x

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted