Client Php Laravel Package

Product Decisions This Supports

• Passwordless authentication roadmap. Passkeys (WebAuthn/FIDO2) are the highest-leverage replacement for passwords on the login and signup critical path. This SDK lets you put a scoped, testable passkey bet in front of users without committing to a native WebAuthn build.
• Build vs. buy for auth infrastructure. Implementing WebAuthn correctly is not a weekend project — challenge generation, attestation/assertion verification, credential storage and rotation, device sync semantics, account recovery, and the UX for "what if the user's phone is in the other room." Evaluating Corbado forces the real make/buy conversation: do we want auth as a core competency or a vendor line item?
• Conversion and fraud KPIs. Passkeys typically move two metrics in opposite directions in a good way: higher login completion (no reset emails, no forgotten passwords) and lower credential-stuffing / phishing ATO. A POC here produces real numbers to justify or kill the roadmap item.
• Segment and platform decisions. Passkey rollout is inherently uneven — iOS/Android/macOS support, browser fallbacks, hybrid transport via QR, enterprise SSO coexistence. Trialing the SDK surfaces which user segments can go passwordless first and which need legacy fallback for another year.
• Regulatory and trust positioning. Passwordless aligns with the direction of NIST/CISA guidance and reduces the blast radius of credential breaches — useful material for security questionnaires and enterprise sales cycles.

When to Consider This Package

Adopt (in a limited, time-boxed way) when:

• You are already a Corbado customer, or you are running a discovery spike and need to demonstrate passkey UX to stakeholders in days rather than quarters.
• You need to validate the product hypothesis ("will our users actually adopt passkeys?") before funding a real build — the SDK is a cheap instrument for that experiment.
• Your project is a prototype, internal tool, or throwaway demo where a maintenance gap is tolerable.
• You have a hard constraint against native mobile work and need a browser-first path to passwordless.

Look elsewhere when:

• Archived: yes is the deciding factor. This repository is no longer maintained. There will be no PHP version compatibility work, no security patches, no fixes when Corbado's API drifts, and no response to a CVE. Shipping this in a production auth path is a standing risk that will land on someone's plate later, and auth is the one subsystem where "we'll deal with it" is not an acceptable answer.
• You need a vendor with a support commitment. An archived MIT client is a signal about the vendor's investment in this surface area — it does not necessarily mean the hosted service is dead, but it absolutely means the PHP client is not a supported path. Ask the vendor directly, in writing, before you build on it.
• You want self-hostable or portable auth. This is a thin client to Corbado's cloud API. MIT licensing is irrelevant here — the value is in the backend, so there is no meaningful "we'll just fork it" exit. That is a lock-in decision, not a dependency decision.
• Your stack is not PHP or you need multi-language parity. Fine for a PHP-only scope; a liability the moment you add a mobile app or a second backend.
• Community support matters. 115 stars means a thin ecosystem — few Stack Overflow answers, few war stories, no third-party tutorials to lean on when something breaks at 2 a.m.
• You need deep customization of flows, custom recovery models, or nonstandard tenant/identity structures.

How to Pitch It (Stakeholders)

For executives — one paragraph: Passwords are our largest and least productive security surface: they generate reset-ticket volume, bleed conversion at signup, and are the primary vector for account takeover. Passkeys eliminate that category of risk and are becoming table stakes in consumer and enterprise expectations. Corbado's PHP SDK is a fast, low-cost way to measure the passkey opportunity on our own user base — a two-to-three week spike that yields real conversion and support-ticket deltas, not a slide deck. I am recommending it as a bounded experiment, not a platform commitment: the client library is archived and unmaintained, so it is unfit for the production path as-is. The deliverable is a go/no-go decision on passwordless with data behind it, plus a shortlist of maintained alternatives if the answer is go.

For engineering — the honest version: The integration is genuinely light — passkeys are delegated to Corbado's hosted backend, so our surface area is SDK calls around registration and login plus fallback handling. The hard parts are product ones: recovery flows, cross-device enrollment, and deciding what happens when a user loses every device. Two real risks. First, the PHP client is archived as of the last release (March 2025); we would either pin to a fork we own or treat this as evaluation-only and re-evaluate a maintained SDK before production. Second, this makes Corbado a hard dependency in our auth path with no self-host exit — the API is the product. Recommend we scope the spike to a small cohort, keep the password path fully intact behind a flag, and write down the exit criteria before we start, not after.