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.