Remix.run Logo
kami23 3 hours ago

Hey thanks for the note about the discord!

I have also been finding the MCP auth story to be really lacking was excited to see OAuth 2 support until I tried to get it to work at work and realized our idp implementation didn't support 2.1, and went into the spec and started wondering if anyone had a good experience yet. Luckily most of our environment can settle on a OAuth token env var standard until that's all in order.

eoskx 2 hours ago | parent [-]

A lot of how well it works or won't work depends on your clients, as not all clients have support for things like RFC 9728 (Protected Resource Metadata). Assuming your client has good support for most of the OAuth 2.0 standards that MCP uses (you don't need DCR as you can statically register clients, assuming that is viable for your environment), then it is possible now with most IDPs to get an OAuth 2.0 auth code flow working just fine. You would then do a token exchange to the upstream to ensure to get the appropriate new audience and rescope/downscope as necessary. Gateways can also help here a lot as instead of baking in all of the auth concerns into your MCP Servers and upstreams, you delegate that to the MCP Gateway. Again, gateway here means different things to different vendors, but Kong, for example, has the ability to act as an MCP proxy (gateway), expose tools based on consumer role or group, apply OAuth 2.0 to it and do an upstream token exchange, while also acting as a regular API gateway that can protect an endpoint with OAuth 2.0/OIDC.