Franceconnect Bundle Laravel Package

Technical Evaluation

Bottom line: release 0.8 materially changes the maintenance story and softens one hard blocker, but not the architecture verdict. This is now a Symfony 6 bundle on PHP 8.1+, not a Symfony 3 artifact — so it is no longer dead code on an EOL framework. It is still a Symfony Bundle, and Laravel has no bundle/container-extension/firewall-authenticator concept, so none of the integration surface transfers. Recommendation is unchanged in direction: re-implement as a Laravel Socialite/league/oauth2-client provider; the bundle remains useful as a specification reference (endpoint URLs, scope set, userinfo→attribute mapping, logout/revocation, FC error codes) and is now a somewhat better reference because it has been touched against modern Symfony security APIs.

What changed in 0.8 (and what it means)

• "Upgrade to Symfony 6" (PR #7, by the original author FlorianKlee) — the headline. Symfony 3 pins are presumably gone; PHP floor rises to ~8.1. This retires the previous "Composer resolution fails outright / PHP constraint <8.1" blocker for a Symfony host, and it means the deprecated UsernamePasswordToken / guard-era authenticator code was probably rewritten to the Symfony 5.3+/6 authenticator system. Caveat: we have PR titles only. No changelog detail, no stated constraint range, no CI/test evidence in the release notes. Treat "Symfony 6" as claimed and unverified until composer.json and the test suite are inspected.
• "Fix for symfony 4.3+ token" (PR #4) — consistent with a 4.4/5.x/6.x support band rather than a hard 6-only jump. Whether it is a range or a single major pin is a key question (see below).
• Proxy proxy_port config change (PR #5) and a doc typo (PR #2) — cosmetic; the proxy knob is mildly relevant if our egress goes through a corporate proxy, but carries no adoption weight.
• Version signal: still 0.8, pre-1.0, single-maintainer-driven, tiny community. Modern framework support does not equal maintained security posture.

Architecture fit — still poor for Laravel (unchanged)

• Bundle registration (Bundle class + DI extension + Configuration tree) and Symfony Security firewall wiring have no Laravel analogue. The 0.8 Symfony 6 rewrite is, if anything, more idiomatic Symfony 6 (new authenticator system, TreeBuilder-based config) and therefore less portable as copy-paste than the old guard-era code.
• The genuinely reusable asset is unchanged: the encoded FranceConnect facts — endpoints, the scope set (openid, given_name, family_name, birthdate, gender, birthplace, birthcountry, preferred_username, email, address), attribute mapping, logout/revocation handling, and FC-specific error codes. That is still worth roughly ~1 day of reading.
• The correct Laravel shape is unchanged: custom Socialite provider behind a thin service class, config in config/services.php, credentials in env/Secrets Manager, a dedicated controller, and an fc_sub column on users.

Integration feasibility — feasible, but still only as a re-implementation (on Laravel)

• Effort estimate holds: ~1–2 weeks to a working sandbox flow, ~2–3 weeks hardened (state/nonce, JWKS caching, logout, account linking, tests).
• New option that 0.8 makes cheaper: if any internal Symfony service must host the FC dance, adopting this bundle (or a BFF wrapping it) is now a plausible rather than absurd choice — the framework-upgrade tax is gone. Budget it as permanently-owned internal software with a named maintainer; MIT permits vendoring.
• The schedule-dominating risk is unchanged and non-engineering: DINUM convention d'engagement, approved client_id/secret, exact-match registered redirect_uris, and FC charter/branding adherence. Multi-week external dependency.

Technical risk — high, but of a different shape than before

• Risk retired: no longer patching EOL Symfony 3 components; composer audit noise from Symfony 3 CVEs should drop. This was the single largest technical objection and it is now substantially mitigated for Symfony hosts.
• Risk unchanged: unmaintained-ish, security-critical surface. OIDC token validation, JWKS handling, state/session logic are precisely where unpatched code is unacceptable. One author, 12 stars, 0 dependents, no community triage.
• Risk added — a fresh, lightly-exercised major upgrade. A Symfony 3→6 jump in a small repo with (as far as the notes show) no CI signal is exactly the kind of change that ships partially-tested authenticator wiring. Assume nothing about the new authenticator path until it is proven against the FC sandbox.
• Spec drift — unchanged and now more urgent. FranceConnect has moved toward OIDC 1.0 semantics (mandatory state/nonce, PKCE, sector-identifier-derived hashed sub, FranceConnect+ / eIDAS assurance levels). A 0.8 release bumping Symfony does not evidence OIDC-migration completeness. Re-verify against current FC integration docs rather than trusting the bundle.
• Identity mapping pitfalls — unchanged. email optional and not necessarily verified; sub can change if the sector identifier is misconfigured, silently producing duplicate accounts. Never key on email; key on fc_sub.

Key questions (updated)

1. New: what does 0.8's composer.json actually declare — a ^4.4|^5|^6 band or a hard ^6.0? Is there a CI workflow and a passing test suite backing the Symfony 6 claim? (30-minute check, gates everything else.)
2. Is this for a French public-facing service? Is FC contractually mandatory, or is a generic OIDC IdP acceptable? Is FranceConnect+ (eIDAS / identity proofing) needed?
3. Do we already hold a DINUM convention and sandbox credentials, and who owns compliance/branding review?
4. Is any part of our estate still on Symfony (legacy app we bridge from), or is the target purely Laravel? If a Symfony service exists, 0.8 changes the build-vs-adopt math there; on Laravel it does not.
5. What is our fallback identity path if FranceConnect is unavailable or the user declines scope consent?

Integration Approach

Stack fit

• Laravel 10/11 + PHP 8.2/8.3 + laravel/socialite (custom provider) or league/oauth2-client. Do not add kleegroup/franceconnect-bundle to a Laravel composer.json — 0.8 does not change this; the blocker is now architectural (bundle/firewall), not version resolution.
• Model: Socialite::buildProvider(FranceConnectProvider::class) → callback controller → resolve/create local user by fc_sub → Auth::login(). Keep the provider stateless and config-driven; store state/nonce in shared session storage (Redis) so multi-instance deploys don't break the callback.
• On a Symfony 6 host, the bundle is now a legitimate candidate; still pin it, vendor-review it, and wrap it behind our own service interface so it stays swappable.

Migration path

• Greenfield Laravel: implement the provider directly; use the bundle (now Symfony 6, so its security wiring is at least readable against current Symfony docs) plus the FC integration docs to confirm endpoints/scopes/errors.
• Legacy Symfony 3 in the estate: the 0.8 upgrade removes the "port the bundle forward" work item — but do not treat that as a reason to keep the Symfony 3 app alive. Preferred pattern remains: (a) a small BFF/OIDC broker owning the FC dance and issuing an internal JWT to Laravel, or (b) an off-the-shelf broker (Keycloak/Authentik) pointed at FC's OIDC discovery document. Both isolate FC churn from application code.
• If a fork is unavoidable: MIT permits it. Cost is now materially lower — no framework major-version uplift required, mainly ongoing care-and-feeding. Still budget it as permanent internal software with a named owner, not as a dependency.

Compatibility

• Hard blockers removed by 0.8: PHP <8.1 constraint (presumed), Symfony 3 component pins (presumed).
• Hard blockers remaining: bundle-only registration, Symfony Security firewall coupling, and the absence of any Laravel-facing surface. Any one of these still fails the integration on Laravel. Net: 0.8 is good news for Symfony hosts, neutral-to-irrelevant for Laravel.

Sequencing

1. (New, cheap, do first) Verify the 0.8 constraint band + CI/test status; skim the Symfony 6 authenticator rewrite for spec-drift gaps.
2. Confirm eligibility + start the DINUM convention in parallel with engineering (long pole, unchanged).
3. Build the provider against the FC integration/sandbox environment; exact-match HTTPS redirect_uri.
4. Define identity mapping: fc_sub as the sole external key; explicit account-linking UX; tolerate absent email.
5. Implement logout, token revocation, error handling (access_denied, invalid_request, _error params).
6. Security review: state/nonce enforcement, JWKS caching + rotation, clock-skew tolerance, managed secrets store.
7. Production onboarding, then a documented fallback-auth decision.

Operational Impact

Maintenance

• Improved but not solved. 0.8 shows the author is still active and willing to modernise — a genuine positive signal that did not exist in the prior assessment. But it is one release after a long gap, on a 12-star/0-dependent repo. If forked: one named owner, quarterly review against FC spec changes (OIDC migration, FC+ assurance levels, endpoint/JWKS rotation), plus composer audit and CI dependency scanning. If re-implemented on Laravel: maintenance collapses to a small provider class + OIDC library updates — still the cheaper path by a wide margin, and still the main argument for re-implementation.
• External churn we don't control is unchanged: DINUM endpoint changes, cert/JWKS rotation, charter/branding updates, periodic re-accreditation.

Support

• Still no vendor, no meaningful community, no issue triage. All incidents are internal: auth runbook, on-call owner, documented FC-outage procedure. Support desk needs scripts for "FC rejected my identity," "I don't want to share my birthdate," and "I have two accounts."
• New: after a Symfony 3→6 rewrite, treat the bundle as freshly changed software for one support cycle — expect a small cluster of integration defects on first adoption that the release notes give no visibility into.

Scaling

• Unchanged: auth volume is low; the bundle is not a scaling concern. Real constraints are shared session/state storage (Redis, not file/sticky), JWKS caching (cache the key set, don't fetch per request), and rate-limit/backoff toward FC endpoints. Symfony 6's own runtime is irrelevant here.

Failure modes

• FC provider outage → login impossible; requires a maintained fallback (local credentials or second IdP) and a graceful error page, not a 500.
• state/nonce mismatch from lost sessions on multi-instance deploys → intermittent, hard-to-reproduce callback failures.
• redirect_uri drift between environments → FC rejects before our code runs.
• Misconfigured sector identifier changes sub → duplicate accounts and orphaned data.
• JWKS/cert rotation or clock skew → silent signature-validation failures.
• New: authenticator-regression after the Symfony 6 rewrite — an unproven auth path that fails closed in staging and open-ish in edge cases; validate explicitly in the FC sandbox before trusting it.
• Scope over-request (e.g. address when unnecessary) → data-minimisation non-compliance and accreditation risk.
• Logout desync → sessions surviving FC-side logout.

Ramp-up

• ~1–2 days to read the bundle and extract endpoints/scopes/error codes (unchanged; the Symfony 6 code is arguably easier to read against current docs).
• ~2–3 weeks for a Laravel engineer to ship a hardened custom provider including tests (unchanged).
• Reduced: the "upgrade a fork to modern Symfony/PHP" work item is essentially gone if a Symfony host is in play — saves roughly the 1–2 weeks previously implied for a viable fork.
• Added: ~half a day for whoever adopts on Symfony to review the 0.8 authenticator rewrite and diff it against FC's current OIDC requirements.
• Unchanged and still binding: DINUM convention, registered redirect URIs, and security sign-off dominate the calendar, well beyond the ~2–3 weeks of code.