Symfony Oidc Bundle Laravel Package

Product Decisions This Supports

Authentication build-vs-buy. This package is a strong input to the "build SSO ourselves vs. buy/integrate" decision for any Symfony-based product. It wraps the established jumbojett/OpenID-Connect-PHP library in a Symfony-native security layer, so the realistic comparison is not "integrate OIDC from scratch" (weeks of token validation, JWKS caching, nonce/PKCE, discovery-document parsing) versus "use this bundle" (days), but rather "use this bundle" versus "use a commercial IdP SDK or identity broker."

Enterprise/SSO feature tiering. It directly supports a roadmap decision to make OIDC single sign-on an enterprise-tier or paid-plan capability rather than a custom per-customer project. Multi-client configuration (arbitrary named clients, autowirable per client, overridable well-known URL/client ID/secret) means one codebase can serve several customers, tenants, or IdPs without forking.

Customer-driven integration requests. The README's supported-IdP table (Auth0, Keycloak, Microsoft Entra ID, Microsoft ADFS, OpenConext/SURFconext) is effectively a pre-qualification list for sales engineering: if a prospect uses one of these, the integration is a configuration task, not a scoping exercise. That changes deal qualification and reduces custom-services revenue dependency.

Just-in-time user provisioning. The OidcUserProviderInterface (ensureUserExists / loadOidcUser) makes account bootstrap from identity claims an explicit, ownable product surface: we decide which claim is the identity key (sub by default, configurable to email or any property path), what we persist on first login, and how we distinguish SSO logins from password logins. That is a data-model and onboarding-funnel decision, not just an implementation detail.

Security and compliance posture. Configurable token leeway, JWKS/well-known caching, nonce verification (with an explicit opt-out), PKCE (code_challenge_method: S256), and optional ID-token-only flows give us the knobs to satisfy security review and pass an OIDC questionnaire without bespoke crypto work.

Session and offboarding UX. Remember-me support and the end-session listener (IdP-side logout, with target-path control) enable decisions about session longevity and clean logout — relevant for regulated customers and for reducing support tickets.

Scope correction — framework mismatch. This is a Symfony bundle, not a Laravel package: it requires Symfony 5.4+/6+ with the new authenticator manager and PHP 8, uses YAML firewall configuration, and ships no service provider, facade, Socialite driver, or Laravel middleware. If our product is on Laravel, this package is not directly consumable — the applicable options are a Laravel-native OIDC/Socialite provider, or wrapping the underlying jumbojett/OpenID-Connect-PHP library ourselves. Treat the framework question as the first gate before any other evaluation.

When to Consider This Package

Adopt when:

• The application is on Symfony 5.4 or 6+ with PHP 8 and the new authenticator manager is enabled (or can be).
• The requirement is genuine OIDC (discovery document, ID token, userinfo endpoint) rather than plain OAuth2 or SAML-only.
• We need to support one or more of the listed IdPs — especially SURFconext/OpenConext, Keycloak, Auth0, or Entra ID — and the edge-case documentation (docs/ms-entra-id.md, docs/adfs.md, allow_discovery_access_token_issuer) covers the provider's quirks.
• We want configuration-driven onboarding of new IdPs (new client block plus env vars) rather than new code per customer.
• We need JIT provisioning with a controllable identity key, and multi-client support for tenants.
• Our team is small and we prefer a thin integration over owning token-validation code.

Look elsewhere when:

• The stack is Laravel. No Laravel integration exists; porting effort erases the time-to-market advantage. Use a Laravel-native OIDC/Socialite driver or integrate the base library directly.
• Legacy constraints apply: PHP 7 or pre-5.3-auth-manager Symfony — the v1.x branch is documented but is a maintenance branch, not a forward path.
• Adoption risk is unacceptable. Signals here are mixed: 99 stars and zero dependent repositories indicate very limited external validation; the repository is a mirror of a private GitLab instance, so the roadmap and issue velocity are controlled by a single organization. This is a reasonable dependency for a small team already in the Symfony ecosystem, but not one to build a paid enterprise SLA on.
• Provider support is unproven for our target IdP. Only SURFconext is stated as actually tested; everything else is best-effort configuration.
• We need capabilities beyond login: token introspection, delegated/on-behalf-of flows, refresh-heavy API access, SCIM provisioning, step-up/MFA orchestration, or an admin UI for connection management.
• We require vendor support, indemnification, or an audited security program. Apache-2.0 and a small maintainer set mean we own the risk; budget for pinning versions and a fork-and-patch contingency.
• SAML is the actual customer requirement — this is OIDC-only.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost, permissively licensed (Apache-2.0) piece of plumbing that unblocks enterprise single sign-on for our Symfony application. It replaces what would otherwise be weeks of custom authentication code with configuration: we point it at a customer's identity provider, map one claim to a user account, and they log in. It already speaks the identity providers our prospects most commonly use (Microsoft Entra ID, Auth0, Keycloak, ADFS, SURFconext), which shortens security review and removes a recurring custom-integration line item from sales. The trade-off to acknowledge: it is a thin wrapper maintained primarily by one organization, with limited public adoption, so we should treat it as a vetted dependency we can fork if necessary — not as a vendor-backed platform bet.

To engineering: It is a Symfony bundle (note: not Laravel — if we are on Laravel, this needs a different approach) built on the well-known jumbojett/OpenID-Connect-PHP client, requiring PHP 8 and Symfony 5.4+/6+ with the new authenticator manager. Integration surface is genuinely small: a client config block, an OidcUserProviderInterface implementation (two methods), and an oidc: ~ firewall listener. It handles discovery, JWKS caching, nonce, PKCE, token leeway, multi-client wiring, remember-me, and IdP end-session logout. Recommended guardrails: pin the version, verify behavior against our specific IdP in staging before committing (only SURFconext is officially tested), review the Entra ID and ADFS docs for provider-specific flags, and keep the user-provider logic thin so a future swap to a differently maintained library is contained to one class.