Openid Connect Provider Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on identity infrastructure. This bundle is a "buy" lever for one specific decision: whether to become an OpenID Connect Provider (OP) rather than merely consume one. It wraps league/oauth2-server-bundle and adds the OIDC-specific surface — discovery (/.well-known/openid-configuration), JWKS, ID token issuance, and RP-initiated logout. A PM should treat it as an accelerant for provider-side identity work, not general-purpose auth.

• Roadmap scoping: "Sign in with Us." It unlocks the product conversation about exposing your app as an identity provider to third parties — partner portals, SPAs, mobile clients, sister products, or an internal SSO hub. The Authorization Code and Implicit flows plus discovery mean a client can integrate without bespoke documentation or manual endpoint contracts.

• The client-onboarding model — newly a real choice as of 0.3.0. Earlier releases forced static, config-file clients, which capped the product at "a handful of known partners." 0.3.0 adds support for custom clients, meaning client records can come from your own storage (database, entity, admin-managed table). That turns onboarding from a code change per client into a workflow you build. It still does not give you dynamic client registration, a consent screen, or self-service signup — but it converts a hard architectural blocker into a scoped product epic, which is a materially different roadmap conversation.

• Deprecating a homegrown token/auth layer. If there's an existing internal auth system issuing tokens by hand, this is the smallest credible replacement path on Symfony: standards-compliant primitives instead of a bespoke JWT implementation that becomes a security liability. That's a debt-reduction decision with a measurable risk reduction, not just a refactor.

• SSO / session-termination requirements. RP-initiated logout (added in 0.2.0, hardened in 0.2.1 and 0.2.5) is the sleeper feature. If enterprise buyers or security reviews ask "does logging out of the IdP actually end the session at the RP?" — this bundle answers that, and it's the kind of checkbox that blocks deals late in procurement.

• Key-rotation and crypto-hygiene posture. 0.3.0 adds the kid value to the JWKS output, which is the small change that makes multi-key and rotation scenarios viable: clients can distinguish which key signed a token instead of assuming a single static key. For a PM this matters as an operational commitment — "we can rotate signing keys without breaking every relying party" is a security-review answer you can now give, and a runbook you now have to actually own.

• Compliance and interoperability positioning. OIDC conformance is a prerequisite in regulated and enterprise sales cycles. Adopting a spec-following implementation lets you make standards claims in security questionnaires without commissioning an audit of your own crypto.

• Multi-tenancy and custom claims as a scoped extension point. UserClaimsResolveEvent is where product differentiation lives — enriching tokens with roles, org IDs, entitlements, or email_verified. This is a decision about what your identity contract exposes, which is genuinely a product concern, not just an engineering one.

• What it does not decide. It does not give you user management, consent screens, client self-registration, MFA, or a policy engine. The new custom-clients capability is storage flexibility, not onboarding UX — someone still has to design the registration flow, validation rules, and abuse controls if you expose it. A PM who reads "OIDC provider" and assumes a turnkey identity platform will mis-scope the roadmap by an order of magnitude. Price those as separate epics.

When to Consider This Package

Consider adoption when:

• The platform is Symfony-native (PHP 8.2+, Symfony 7.4/8.0 per prior releases; note 7.2/7.3 and PHP 8.1 were explicitly dropped in 0.2.3–0.2.4, and 0.3.0's "Complete symfony 8.0 removal from workflows" entry means the support matrix should be re-read from composer.json, not from changelogs — version discipline matters) and already uses or is willing to adopt league/oauth2-server-bundle — this bundle is an extension of that dependency, not a substitute for it.
• You need provider-side OIDC: discovery, JWKS, ID tokens, end-session. If you only need to consume an IdP (Google, Okta, Entra), this is the wrong package entirely — use a client library.
• Your client population is manageable, and you're willing to own the client lifecycle yourself. Custom clients support (0.3.0) means you can back clients with a database rather than YAML, but there is still no dynamic client registration — no metadata documents, no registration_endpoint, no automated trust. If you need self-service onboarding, you are building it on top.
• You need claim customization through Symfony's event system and are comfortable owning that logic.
• You accept pre-1.0 status (0.3.0), TBD documentation, and — as of the last check — 9 GitHub stars with zero dependents. That last data point is the one to weight heaviest: near-zero production evidence means near-zero external validation of edge cases. Budget for reading the source, not the README.

Look elsewhere when:

• You're on Laravel. This is a Symfony bundle, full stop. Laravel integration means bridging Symfony's container and bundle bootstrapping into a Laravel app — brittle, unsupported, and an ongoing maintenance tax with no upstream help. For Laravel, evaluate laravel/passport + ronvanderheijden/openid-connect, league/oauth2-server directly, or a dedicated IdP. Do not let "it's PHP so it's close enough" carry this decision. Nothing in 0.3.0 changes this.
• You need enterprise-grade identity. If the requirement includes MFA, consent management, dynamic registration, PKCE-hardened public clients, token exchange, or 4PI, a single-maintainer pre-1.0 bundle is not the answer. Keycloak, Ory Hydra, Authentik, or a managed IdP will be cheaper than the engineering you'd layer on top.
• You need scale or HA guarantees. No published performance characteristics, no production references.
• You need PKCE out of the box. Still not surfaced in this bundle; it must be configured through the underlying OAuth2 bundle. For SPA and mobile clients this is a security-critical gap to verify before committing. The 0.3.0 changelog does not address it.
• You're pinned to league/oauth2-server-bundle:^1. 0.3.0 adds support for the ^2 line. Verify which major you're on and whether the upgrade is a prerequisite — this is the most likely source of unplanned migration work in this release, and it lands on your team, not the maintainer's.
• You need commercial support or SLAs. Single maintainer, MIT license, no vendor behind it. That's a bus-factor conversation your risk register should reflect.
• Your team lacks OAuth2/OIDC fluency. The bundle's thin documentation assumes you already know the specs. The learning cost sits with the team, not the package.

Adoption shape I'd recommend: time-boxed spike (1–3 days) validating discovery, an authorization-code round trip, end-session against a real client, and — new for 0.3.0 — a custom-client record served from your own storage plus a key-rotation rehearsal. Add a written exit plan if the maintainer goes quiet. Treat it as a dependency you may need to fork; MIT makes that viable, which materially lowers the risk.

How to Pitch It (Stakeholders)

Executives — one paragraph: "We have an opportunity to make our platform a standards-compliant identity provider — the thing other apps integrate with to let users sign in — instead of building that capability ourselves. This is an open-source component that provides the protocol endpoints; the alternative is roughly a quarter of engineering time replicating a well-defined spec, with a permanent security-maintenance tail. The latest release also lets us manage which external applications are allowed to connect through our own systems rather than a fixed config file, which is what makes partner onboarding repeatable instead of a bespoke project each time. It's MIT-licensed with no per-seat or per-auth costs, so it also removes a future vendor line item versus Okta or Auth0. The trade-off is honest: it's a small, young, single-maintainer project in a Symfony codebase, so it's a good fit if our stack and requirements line up, and a poor fit if they don't. I'm recommending a short validation spike before we commit it to the roadmap."

Framing to use: faster time-to-market on SSO and partner integrations; manageable client onboarding rather than one-off integrations; lower auth-related technical debt; standards compliance that shortens enterprise security reviews; no new vendor dependency or recurring license cost. Framing to avoid: calling it an "identity platform," implying it replaces an IdP, or implying the new client support means "self-service registration" — it does not.

Engineering — the brief: "This is a Symfony bundle that extends league/oauth2-server-bundle with OIDC-specific endpoints: discovery, JWKS, ID token issuance, and RP-initiated logout. If you're already running the OAuth2 server bundle, this is additive config plus routes. Concrete work: install the underlying bundle first, register the routes, tune the ajgarlag_openid_connect_provider config (endpoint route names, cancel_logout_default_path), and implement a UserClaimsResolveEvent listener to populate sub, email, and any custom claims.

What changed in 0.3.0 and why it matters to us:

• Custom clients (PR #28). Client records no longer have to be static config — we can source them from our own storage. This is the unlock for any product plan involving client onboarding beyond a fixed partner list. It is not dynamic client registration; we'd own the creation flow, validation, and revocation.
• kid in JWKS (PR #30). Enables key rotation and multi-key setups. Good security hygiene; also means we now own a rotation runbook.
• league/oauth2-server-bundle:^2 support (PR #39). Confirms this is tracking the current upstream major. Check which major we're on before scoping — this is where migration time hides.
• Service-referencing cleanup (PR #34) and workflow changes (PR #40). The latter removed Symfony 8.0 from CI; read composer.json for the actual supported Symfony range rather than trusting the changelog or the prior release notes.

What's good: small surface area, MIT, active maintenance — releases land steadily and track the ecosystem. Recent cycles have been correctness fixes to ID token claim defaults, nonce handling, sid comparison on logout, and suppressing ID tokens on the client-credentials grant — the fixes you'd write yourself six months in.

What to check before we commit:

1. PKCE — still not surfaced here; must be configured in the underlying bundle. Confirm before any public client ships.
2. Dynamic client registration — not supported, and custom clients doesn't close that gap. If the product needs self-service onboarding, that's a custom build on top of the new extension point.
3. league/oauth2-server-bundle major version — confirm whether we're on ^1 (and need the ^2 upgrade) or already on ^2.
4. Docs are TBD — plan on source-reading. Budget a day.
5. Bus factor of one, near-zero stars/dependents as of last check. Assume we may fork. Get a written note on what we'd do if upstream stalls.
6. Laravel is not supported. If any part of the roadmap is Laravel, this is a non-starter for that surface and we should not pretend otherwise.

Ask: a 1–3 day spike — code-flow round trip, discovery doc validation, end-session against a real client, one custom-client record from our own storage, and a signing-key rotation rehearsal — with a go/no-go and a fork contingency. If it passes, this is 2–4 weeks of integration, not a quarter, plus a separate estimate for whatever client-onboarding UX we decide we want."