Fas Open Id Bundle Laravel Package

Technical Evaluation

Architecture fit. The package name is the first red flag for a Laravel decision: it is a Symfony bundle, not a Laravel package. That means it ships a Bundle class, a DI extension, YAML configuration under a bundle namespace, and a Symfony Security Authenticator (or the deprecated Guard system). Laravel has no equivalent bundle/extension lifecycle — service providers, container bindings, and middleware/guards are structurally different. Installing it into a Laravel app will not wire anything up; at best it pulls Symfony components into your dependency graph for no functional gain. The bundle is a reasonable fit for a Symfony/API Platform service, which is presumably Intracto's target audience.

Integration feasibility. The underlying capability is real and non-trivial: FAS (the Belgian Federal Authentication Service) is an OpenID Connect provider for eID and itsme, and it requires private_key_jwt client authentication — a signed client assertion JWT plus a registered public key — rather than a plain client secret exchange. Most off-the-shelf Laravel OAuth tooling (laravel/socialite, generic league/oauth2-client providers) does not do private_key_jwt out of the box. So there is genuine value in the package as a reference implementation of the FAS protocol specifics: endpoint paths, scope values, claim mapping for eID attributes, and assertion signing. The code is MIT-licensed, so reading and porting it is unencumbered. That is the realistic integration path in a Laravel codebase — port, don't depend.

Technical risk.

• Abandonment risk is high. 1 star, 0 dependents, last release October 2022, composite score 0.505. There is effectively no community, no issue triage signal, and no evidence of ongoing maintenance. Symfony 6 removed Guard, and Symfony 7 tightened DI/attribute conventions; a 2022 bundle is unlikely to support current Symfony without work, and certainly will not track Laravel's release cadence.
• Security-critical surface. This sits directly on the authentication path and handles private keys, ID token validation, state/nonce, and audience/issuer checks. An unmaintained component here is materially worse than an unmaintained component elsewhere; you inherit the CVE response burden yourself.
• External dependency you cannot code around. FAS requires application registration with the Belgian federal authority, an acceptance-environment certification, and key registration. That procurement/onboarding timeline is typically the critical path, not the integration work.
• Version uncertainty. Symfony version constraints, PHP 8.x support, and whether the bundle validates ID token signatures (JWKS fetch and cache) versus trusting the TLS channel all need confirmation before any decision.

Key questions.

1. Which Symfony/PHP versions are supported, and does it depend on the removed Guard API?
2. Does it implement private_key_jwt with key rotation, or does it assume a static secret?
3. What ID token validation is actually performed — signature, iss, aud, exp, nonce, acr?
4. How are FAS claims (eID identity attributes, assurance level) mapped to a user provider, and how coupled is that to Symfony's UserProviderInterface?
5. Is FAS end-session/logout supported, and is multi-flow (eID vs. itsme vs. assurance levels) configurable?
6. Is the repository archived or merely dormant — and who inside Intracto owns it?

Integration Approach

Stack fit. Poor as a direct dependency in Laravel; good as a protocol reference and a hard fork candidate if any part of the estate is Symfony. If the team is Laravel-only, treat this as documentation with working sample code, not as an installable module.

Migration path. Two viable routes:

• Laravel-native port (recommended). Implement a small internal FasProvider on league/oauth2-client plus firebase/php-jwt for the client assertion, wrapped in a Socialite driver or a custom guard. Port the endpoint constants, scope names, and claim mapping from the bundle. Key material lives in your secrets manager (AWS Secrets Manager / Vault), not on disk as the bundle's keystore config implies.
• Fork the bundle. Only justified if you already run Symfony services and want a shared auth contract. Even then, pin to a specific commit, vendor the fork internally, and assign an owner.

Do not attempt to mount the bundle inside Laravel via a compatibility shim. The DI and Security integration points diverge too far; you would spend more effort on the shim than on the port.

Compatibility. Validate against the current Laravel LTS and PHP version in your estate, and confirm the JWT library choice supports the RSA signing and key sizes FAS mandates. Confirm clock-skew tolerance — assertion iat/exp windows are narrow and are a common source of acceptance-environment failures.

Sequencing.

1. Protocol spike (1 week). Read the bundle source, extract FAS endpoints, scopes, assertion format, and claim set. Produce an internal spec.
2. FAS registration kickoff in parallel (external, weeks–months). Submit the application, request acceptance-environment credentials, register the public key. Start this on day one; it gates everything.
3. Provider implementation (1–2 weeks). Client assertion signing, token exchange, ID token validation, JWKS caching.
4. Laravel guard + user provisioning (1 week). Attribute mapping, account linking policy, session issuance.
5. Acceptance-environment certification, then production cutover with BOSA sign-off.

Operational Impact

Maintenance. Owned entirely by you in the Laravel scenario — which is the correct outcome, since the upstream package shows no maintenance signal. Budget for a named owner and a documented procedure for key rotation and FAS endpoint/scope changes. If you fork instead, you have added a second maintenance obligation with no upstream to rebase onto.

Support. No vendor SLA and no community. Escalation for protocol questions goes to the FAS authority's onboarding channel; escalation for bundle behaviour goes to reading the source. Factor that into support-tier planning — this is not a component to hand to a first-line team without runbooks.

Scaling. Authentication volume is low relative to typical application traffic; the real scaling concerns are (a) JWKS/key material distribution across horizontally scaled instances — cache it, don't fetch per request; (b) secrets-manager latency on cold start; (c) session store choice for the post-login session. None of these are bundle-specific, but all of them become your problem when you port.

Failure modes.

• FAS unavailable → no local login fallback. If FAS is the only identity source, an outage is a full login outage. Decide explicitly whether a break-glass local admin path exists and how it is secured.
• Key/passphrase mismatch or expired certificate → total auth failure with opaque errors from the assertion step. Instrument this specifically.
• Clock skew → intermittent, environment-specific assertion rejections that are painful to diagnose.
• Redirect URI drift between registered and deployed config → failures only in the environment where config diverged.
• Silent upstream decay → no patches arrive; you discover a dependency CVE during an unrelated audit.

Ramp-up. Steep for the domain, moderate for the code. The team needs OpenID Connect fluency (private_key_jwt, ID token validation, nonce/state) and Belgian eID/FAS onboarding knowledge, plus the Symfony-to-Laravel translation overhead. Assume 3–4 weeks of engineering for a competent two-person team, dominated by the spike and acceptance testing, plus the external registration timeline which you do not control. Do not plan a go-live date that depends on FAS approval until that approval has a named contact and a written timeline.

Bottom line. Adopt the knowledge, not the dependency. The package fills a real gap — FAS private_key_jwt integration is not something Laravel tooling gives you — but at 1 star, 0 dependents, and a 2022 release, it fails any reasonable supply-chain test for an authentication-critical path. Port the protocol details into a small, owned Laravel module with tests against the FAS acceptance environment.