Client Php Laravel Package

Technical Evaluation

Architecture fit. corbado/client-php is a thin HTTP client for Corbado's hosted passkey service, not a Laravel-native package. Expect no ServiceProvider, no publishable config, no facade, no Blade/Inertia scaffolding — integration means wrapping it ourselves. Architecturally that means your auth flow gets a hard runtime dependency on a third-party API on the login hot path, which is a meaningful coupling decision for a Laravel app that otherwise owns its auth stack.

Integration feasibility. Mechanically easy (composer require, a few method calls around registration/login ceremonies). The friction is not the code — it's the surrounding ceremony wiring: relying-party ID and origin configuration per environment, session/state correlation between the browser and the Laravel backend, and attestation policy choices. That work exists regardless of SDK and is where the real effort sits. The SDK being archived makes feasibility time-boxed: it works today, but Composer constraints against PHP/Laravel majors will rot.

Technical risk.

• Archived status (highest). WebAuthn/passkey handling is security-sensitive parsing and verification logic. A frozen SDK receives no CVE response. If we adopt, we inherit that liability permanently.
• Vendor/product risk. Corbado archived the PHP client — likely consolidation onto a hosted flow, a different SDK, or reduced investment in PHP. Verify the API itself is still supported before building on it.
• Small community. 115 stars means few eyes, few Stack Overflow answers, and no ecosystem pressure to keep it compatible. Low bus factor for issues.
• Data & compliance. Credential metadata and user identifiers leave your infrastructure. Confirm this fits our data-residency and DPA posture before a spike, not after.
• Framework upgrade pinning. A dead package in composer.json can block a Laravel major upgrade for the whole app — an underappreciated org-level cost.

Key questions.

1. Why was the repo archived, and what is the vendor's stated supported path for PHP today (replacement SDK vs. hosted redirect flow vs. no PHP support)?
2. Is the underlying Corbado API versioned and guaranteed stable independently of this client?
3. Does it support PHP 8.2+ and Laravel 11/12, or will it constrain our upgrade cadence?
4. What is the threat model: which attestation policy, RP ID scoping, and origin validation does the SDK enforce vs. delegate to Corbado?
5. What are the pricing, SLA, rate limits, and exit terms — and how do we export credentials if we leave?
6. Build-vs-buy: how does this compare to web-auth/webauthn-lib (self-hosted, maintained) or a first-party/community Laravel passkey package?

Integration Approach

Stack fit. Treat it as an external service, not a Laravel package. Put it behind an internal interface (PasskeyProvider) with a single adapter implementation, bind it in a service provider we write, and keep every SDK symbol inside that one namespace. This makes the vendor swappable and lets us stub it in tests. Never call the SDK directly from controllers.

Migration path. Do not make passkeys the primary factor on day one. Sequence: (a) optional passkey enrollment for an internal or low-risk cohort behind a feature flag; (b) passkey as a secondary login option with password/email-OTP always available; (c) only then consider promoting it. This bounds blast radius and gives a clean rollback that doesn't strand users.

Compatibility. Before any code, run a throwaway Composer resolution against our actual composer.json — the likely failure is a pinned Guzzle/PSR-18 version colliding with our HTTP stack, or a PHP constraint that predates 8.2. If it doesn't resolve cleanly against our current Laravel, the decision is effectively made for us.

Sequencing.

1. Compatibility spike (1–2 days): resolve deps, install in a scratch branch, confirm it loads under our framework version.
2. Vendor diligence (parallel): answers to the key questions above; written confirmation of API support status.
3. Functional proof (1 week): staging environment with a real RP ID and test domain; complete registration and authentication ceremonies end-to-end, including error paths and a user-with-no-passkey path.
4. Decision gate: go only if (i) vendor confirms API support, (ii) deps resolve against our stack, (iii) we accept owning the fork. Otherwise pivot to a maintained self-hosted library.
5. Build: adapter + feature flag + fallback auth + audit logging.
6. Rollout: cohort-gated, with passkey success/failure dashboards from day one.

Operational Impact

Maintenance. Adoption means ownership: fork the repo into our org, vendor it as an internal Composer package, and commit to applying dependency and security updates ourselves. That is a recurring cost, not a one-off — budget it explicitly (roughly a few days per year of baseline upkeep, more on PHP/Laravel majors). If nobody owns the fork, don't adopt.

Support. No upstream maintainer for the client. Corbado may still support the API; the SDK is community/frozen. Our team becomes first-line support for all SDK-level issues, and the 115-star community won't help much.

Scaling. The SDK itself is trivial; scaling is a function of Corbado's API. Every passkey ceremony is a network round trip on the authentication path — that's added latency at exactly the moment users are most sensitive to it. Plan explicit timeouts, a circuit breaker, and automatic degradation to password login on provider failure. Cost scales with MAU/authentications, so model pricing at 2–3× current volume, not today's.

Failure modes.

• Vendor outage → passkey login unavailable; fallback auth is mandatory, not optional.
• Silent API change → frozen SDK can't adapt; errors surface as login failures. Pin and monitor.
• Dependency rot → package blocks a framework upgrade, forcing an emergency fork mid-upgrade.
• Credential/API-key handling → secrets in .env/vault, rotation runbook, and per-environment keys.
• Configuration drift → mismatched RP ID/origin between environments produces confusing, hard-to-diagnose failures; codify config as infrastructure.

Ramp-up. Developer ramp-up is genuinely small — the public surface is a handful of calls, so a mid-level dev is productive in a day or two. The real learning curve is WebAuthn domain configuration and operational runbooks, not the SDK. The on-call cost is the bigger hidden item: add a runbook covering "passkey login failing for a subset of users," including how to diagnose provider-vs-config-vs-client issues and how to steer users to fallback auth.