RFC 8707 implementation: audience vs resource

Product Feedback
,
1

Hi,

I was testing my auth0 configuration with MCP Inspector and ran into a discussion on github.

The keyword audience was only used to the description of the concept. It is not a registered parameter. The registered parameter is resource. I guess most MCP client only supports the resource parameter.

This makes integrating with popular cloud LLM provider difficult. How will auth0 address issue?

Thanks

2

Hi @davidshen84 :waving_hand:.

You’re right, Auth0 has supported the audience parameter as the way to signal the aud claim in access tokens since ~2017 (long before RFC 8707’s resource parameter was adopted). However, the audience parameter is included in the IANA registry for OAuth Parameters, so its presence is acknowledged by the registry (though it’s primarily called out in specs like Token Exchange).

For now though, it appears like much of the MCP tooling has converged on resource parameter. In the short-term, you’ll need to try to override that parameter when possible.

Longer-term, we’re advocating for broader inclusion of the audience parameter in tooling, and have future plans to allow Auth0 tenants to use the resource parameter instead of audience.

1 Like
3

Hi Josh,

Thanks for the reply.

As for “try to override”, do you have any recommendations?

If we implement our own chatbot, we are in control of the MCP Client. Changing the parameter name is easy. But if we are integrating our MCP server into other’s chatbot, such as Claude web or Claude desktop, they are in control of the MCP client. How can one override the parameter in this case?

Thanks.

2 Likes
4

Hey @josh.cain! :waving_hand:

Just dropping in to voice my support for including resource for the same reason as above. I was trying to think through how to work around this but, because aud is a core claim and the consent needs to happen before the token is minted, this would need to be on on the initial authorize URL and not in Actions. Client side with a UL template does not appear to be possible (and is kind of hacky too).

Any other creative ideas here? Thank you!

5

Hey @joshcanhelp, good to see you around here!

@davidshen84 yep, you’re spot on. A potential workaround could be to use the default audience tenant setting. However, that has limitations (you only get one) and implications for tenant-wide token issuance, so you’ll need to be cautious.

I’ve seen POC-style work doing things like rewriting parameters at the edge, but that style approach is obviously not recommended for production use. At the end of the day, I think the most ideal solution will indeed be Auth0’s support of resource.

2 Likes
6

@josh.cain, I understand that it would be nice if MCP tooling community would start to leverage audience as well, however since time is moving fast in the MCP space, can you share any thoughts about the timing for the future plans to allow Auth0 tenants to use the resource parameter instead of audience. Right now it is a blocker for leveraging Auth0 for auth. for us, and I imagine it could be so for others.

7

@josh.cain You brought up RFC-8693 so I went and read up on both RFC-8693 and RFC-8707.

Both RFCs were published within a month of each other and both talk about using a resource parameter while RFC-8693 also include the audience parameter. Importantly, RFC-8693 indicates that both parameters are valid and allowed in the same request. The resource parameter is defined as the more restrictive URI format while audience is a “logical”, IdP-unique, identifier. I also went back and cross-checked the aud claim from RFC-7519 (JWTs) and its defined as a StringOrURI (or array of StringOrURI).

So, with all of that out of the way, why doesn’t Auth0 simply allow both resource and audience like RFC-8693 envisioned for token exchange and solve the problem for everyone?

I get that Auth0 only supports a single audience parameter while RFC-8707 acknowledges it’s possible to include multiple resource parameters. Auth0 could simply not allow both paramters like it presumably doesn’t allow multiple audience parameters today. Is there some security issue with allowing such a thing? It seems like resource, in the context of Auth0 at least, is simply a more restrictive way of passing audience.

8

I found this shortly after my previous post, but in case someone else ends up here in the future, there is now a setting to enable support for both parameters.