Mcp Oauth Bundle Laravel Package

Product Decisions This Supports

Whether to ship MCP connectivity at all — and how fast. This package is the "last mile" for letting third-party AI clients (Claude, IDE agents, internal copilots) authenticate against your product's MCP server. That makes it the enabler for a decision like: do we let external agents read/write our customers' data this quarter, or next year? Without an OAuth story, MCP integrations stall at "paste a static token," which is a non-starter for anything multi-tenant.

Build vs. buy vs. borrow for the authorization server. OAuth 2.0 authorization servers are commodity protocol but non-commodity risk. The realistic options are: (a) managed IdP — Auth0/WorkOS/Stytch/Cloudflare, (b) hand-rolled token endpoints, (c) this package on top of league/oauth2-server and an MCP bundle. This is a genuine PM trade-off between ~2 weeks of integration and an ongoing vendor line item plus a second source of truth for identity. If you already have an IdP, adopting this likely means running two token issuers — usually the wrong call.

Scoping and pricing surface. Resource-bound tokens and configurable scopes are the mechanism by which you decide what an agent can touch: read-only vs. write tools, per-tenant isolation, per-plan entitlements. This directly feeds packaging decisions ("MCP access included on Team and above; write scopes on Enterprise") and usage metering for agentic traffic.

Onboarding UX for agent connections. OAuth discovery metadata and CIMD (client ID metadata documents) reduce manual client registration — the difference between "open a support ticket to get a client ID" and self-serve connect. That's a support-cost and activation-funnel decision, not just an engineering one.

Consent and audit as roadmap items. The moment tokens are resource-bound, you inherit obligations: consent screens, token lifetimes, revocation, and an audit trail of what an agent did. Budget these explicitly rather than discovering them in a security review.

The 1.2 login-redirect config is a smaller but real product decision. Post-authentication destination handling affects the OAuth consent round-trip and deep-linking back into the client app. It also introduces user-controlled redirect input, so it is a security-review gate, not a nice-to-have: enable it behind a flag with a host allowlist, and decide precedence explicitly (query param → session intended URL → default).

Flag before committing engineering time: the package is published as a Symfony bundle (mcp-oauth-bundle, built on mcp-bundle and league/oauth2-server-bundle), while the accompanying assessment describes Laravel middleware, guards, and Artisan commands. The Laravel-facing documentation also reads as a generic login-redirect feature rather than MCP OAuth. Resolve which runtime you're actually adopting — and whether the Laravel path is first-class or aspirational — before it lands in a roadmap.

When to Consider This Package

Reasonable fit when:

• You run a PHP application and want OAuth-protected MCP endpoints without standing up a separate identity provider — particularly if you are already on Symfony with league/oauth2-server-bundle, where this is a thin, idiomatic add-on rather than a new subsystem.
• You are prototyping or running an internal/partner-only MCP integration where a small dependency is tolerable and you can vendor, pin, and patch it yourself.
• Discovery metadata and resource-bound tokens are things you'd otherwise hand-roll badly; getting the tedious spec corners for free is real value.
• You can absorb the maintenance: one maintainer, ~2 stars, a September 2026 release, and no visible security-disclosure process. That is fine for a spike, uncomfortable for a revenue path.

Look elsewhere when:

• You need SSO/SAML/SCIM, certified compliance posture, an SLA, or a vendor who answers a security questionnaire. This fails procurement.
• You already operate an IdP. Don't add a second token issuer; extend the one you have.
• You need dynamic client registration at scale, fine-grained consent management UI, or enterprise admin controls — none of that is in scope here.
• You are Laravel-first and cannot confirm a maintained Laravel integration path. Adopting a Symfony bundle into a Laravel roadmap is a staffing and support decision, not just a composer line.
• Demand is unvalidated. A low opportunity signal plus low adoption means you should not let a package's existence substitute for evidence that customers want agent access.

Suggested posture: a timeboxed spike, not an adoption. One to two sprints behind a feature flag, with explicit exit criteria: does it satisfy the OAuth flow end-to-end, does it survive a threat model (open redirect, token lifetime, allowlist, revocation, audit logging), and what does the fork cost if the maintainer disappears?

How to Pitch It (Stakeholders)

For executives — one paragraph: Customers increasingly expect to connect their own AI assistants and agents to our product. Doing that safely requires standard OAuth, and this package provides most of that plumbing for a PHP stack instead of a quarter of engineering. The upside is speed to an agentic-integration story and a self-serve connect flow; the cost is a dependency on a very small open-source project. The recommendation is a short, low-cost spike behind a flag — not a commitment — with a managed identity provider as the fallback. Low-cost experiment, reversible, no lock-in, because everything here is standard protocol.

For engineering — the pitch: You get OAuth 2.0 authorization and token endpoints, discovery metadata, client ID metadata documents, and resource-bound tokens on top of league/oauth2-server, configured rather than written. The work you'd otherwise spend on protocol edge cases goes into your MCP tools instead. It is standard OAuth underneath, so the exit is clean: our clients are spec-compliant either way. Two caveats to size honestly — verify the Laravel vs. Symfony runtime story first, and treat the 1.2 redirect parameter as untrusted input requiring an allowlist.

For security and compliance — the ask: Review before pilot. Specifically: open-redirect handling in the login flow, token lifetimes and revocation, scope granularity per tenant, and what we log about agent actions. The maintainer shipping a redirect allowlist is a mildly positive signal, but a two-star, single-maintainer project needs an internal owner and a pinned version regardless.

For product and design — the pitch: This is what makes an "Connect your AI assistant" button possible, including the consent and discovery flow that users actually see. It also gives us the scopes we need to gate capabilities by plan and to answer "what did the agent do?" after the fact.