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
Hi @davidshen84 
.
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.
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.
Hey @josh.cain!
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!
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.