- What does omouren/mcp-oauth-bundle actually do?
- It adds OAuth 2.0 authorization to Model Context Protocol servers built on Symfony, sitting on top of mcp-bundle and league/oauth2-server-bundle. The bundle handles the MCP-specific pieces of the authorization spec: discovery metadata, Client ID Metadata Documents (CIMD), and resource-bound access tokens. In practice that means you can protect your MCP endpoints and authenticate AI tool users without hand-rolling the OAuth flow.
- How do I install omouren/mcp-oauth-bundle in a Symfony app?
- Install it with Composer via composer require omouren/mcp-oauth-bundle. You also need mcp-bundle and league/oauth2-server-bundle present and configured, since this bundle layers MCP authorization behaviour on top of them. With Symfony Flex the bundle registration is usually automatic; otherwise enable it in config/bundles.php. After that, publish or configure the OAuth client storage, signing keys, and scopes your server needs.
- Is this a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package, and it is designed to plug into a Symfony MCP server stack. Developers coming from Laravel Passport or Sanctum will recognise the concepts, but the wiring here is Symfony dependency injection and YAML/PHP config rather than Laravel service providers. If you are on Laravel, you would need a Laravel-specific MCP and OAuth integration instead.
- Which PHP and Symfony versions does it require?
- Because it is a thin layer over mcp-bundle and league/oauth2-server-bundle, its PHP and Symfony version floor follows those dependencies. Check the require block in the package's composer.json before upgrading your application, and pin a version that matches your framework constraints. Running composer why omouren/mcp-oauth-bundle is a quick way to see what pulled it in and what it conflicts with.
- What is CIMD and how does client registration work with this bundle?
- CIMD stands for Client ID Metadata Document: instead of pre-registering every MCP client, a client uses an HTTPS URL as its client_id that resolves to a JSON metadata document describing it. The bundle resolves and validates that document so your server can trust the client identity without manual onboarding of each AI tool. This removes a lot of the friction of dynamic client registration while still keeping a verifiable identity chain.
- What are resource-bound tokens and why should I care?
- Resource-bound tokens use resource indicators so an access token is audience-restricted to one specific MCP server resource URL. That stops a token minted for one server from being replayed against another, which closes off a common confused-deputy and token-reuse problem in multi-server MCP deployments. The bundle handles binding tokens to the resource your client actually requested.
- How does OAuth discovery work for MCP clients?
- MCP clients need to find out which authorization server protects a resource and where its endpoints live, so the bundle exposes protected resource and authorization server metadata at the standard well-known locations. A client hitting your MCP endpoint can discover the authorization server, token endpoint, and supported capabilities without hard-coded configuration. That is what makes generic MCP clients able to connect to your server without custom setup on their side.
- How do I protect an MCP endpoint with the bundle's middleware?
- You register the MCP route inside your Symfony application and let the bundle's middleware validate the bearer token, its audience binding, and its scopes before the MCP handler runs. Requests without a valid resource-bound token are rejected with the appropriate OAuth error response, which MCP clients use to trigger the authorization flow. Because it integrates with league/oauth2-server-bundle, token validation rules and scopes follow the configuration you already have there.
- How do I test OAuth-protected MCP endpoints?
- The usual approach is a Symfony functional test that requests a token from your token endpoint and then calls the MCP route with that bearer token, asserting on both the happy path and the 401/403 cases. Keep separate tests for a missing token, an expired token, and a token minted for a different resource so the audience checks are actually exercised. Mocking the OAuth layer is possible but hides exactly the behaviour this bundle exists to provide, so prefer real token issuance in tests.
- Is it production-ready, and what alternatives exist?
- The bundle is a small, focused layer, so the security weight sits mostly on league/oauth2-server-bundle, which is mature and widely deployed. Before production, review the repository's issue tracker and recent commit activity, pin a specific version, and make sure your signing keys and token lifetimes are configured deliberately. The main alternatives are implementing the MCP authorization spec yourself on top of league/oauth2-server, or using a hosted identity provider with resource indicators, both of which mean more custom code than adopting this bundle.