Multimodal Php Laravel Package

Product Decisions This Supports

• Build vs. buy on authentication. The capability inventory here is the honest scope of "auth we'd otherwise build": session + cookie, Paseto V4 tokens with atomic refresh rotation, seven OAuth providers, magic links, TOTP 2FA with backup codes, OIDC server mode, adaptive session risk scoring, multi-tenancy (orgs/teams/invitations), and a plugin hook bus. That's roughly 1–2 engineer-quarters of work plus a permanent security-maintenance tax. Use this list as the denominator in any build-vs-buy spreadsheet — it argues strongly for buying or for Laravel-native primitives, not for hand-rolling.
• Roadmap sequencing for "table-stakes" login features. Social login, passwordless links, and 2FA are now baseline expectations in most B2B and consumer categories. This package is evidence that they're commodity infrastructure, not differentiators: they should sit in "must ship by GA," not in a differentiated roadmap lane.
• Enterprise/SSO tiering. The OIDC server capability (authorization code + PKCE, discovery document, JWKS, RS256 ID tokens) is the strategic item here. It's the technical precondition for selling "we are your identity provider" SSO deals, or for letting customers' IdPs federate into yours. If an enterprise tier is on the roadmap, confirm the chosen vendor/stack supports provider-mode, not just client-mode — many cheap options don't.
• B2B vs. B2C packaging. The organizations/teams/members/invitations model directly supports per-seat and per-org pricing decisions. If multi-tenancy is in scope, this is a requirements item to carry forward even though the package itself isn't.
• Security posture as a purchase criterion. The 0.1.0 changelog is a useful audit checklist applied to a real codebase: tokens hashed at rest, account-takeover fixes for OAuth email verification, SQL column allow-lists, mandatory PKCE for public clients, TOTP anti-replay, rate limiting that refuses to silently no-op. Any alternative you evaluate should be scored against these. Notably, this package required a hardening pass in 0.x — a reminder that "it has a security section in the README" is not evidence.
• The decision this actually forces: route selection, not feature selection. This artifact is archived, deprecated, and superseded by betterauth/symfony-bundle v1. The real product decision is (a) managed identity provider, (b) Laravel-native stack, or (c) the successor bundle if you're a Symfony shop — and the deprecation itself is the strongest available datapoint on single-maintainer dependency risk.

When to Consider This Package

• Effectively never for new work. It is marked DEPRECATED and archived, with 1 GitHub star and 0 dependents. Shipping it means shipping an unmaintained dependency. Even a greenfield prototype shouldn't start here — you'd be writing migration work on day one.
• Consider the successor, conditionally. betterauth/symfony-bundle v1 is the maintained home for this core. It's worth a look when you are a PHP 8.2+ / Symfony shop, want self-hosted auth with no per-MAU bill, specifically want Paseto rather than JWT, and have appetite for a young, single-maintainer project where you may become the de facto maintainer.
• For a Laravel codebase specifically, look elsewhere. There is no Laravel bundle in the integration table — only Symfony. The core is framework-agnostic, but that means you own the wiring: service provider, middleware, guards, route protection, cookie/session bridging. The bundled PDO repositories also target MySQL/MariaDB despite the README's "any SQL database" claim; on Postgres or SQLite you're implementing against 28 interfaces yourself. Laravel's own Sanctum / Passport / Fortify / Socialite, or a managed provider, is the lower-risk path.
• Look elsewhere when any of these are true: you need a vendor SLA or security questionnaire answered; you need SOC 2 / ISO evidence; you need Postgres or SQLite without writing storage; you need an actively maintained release train (this repo's last release is 2026-06-21 and it's archived); you need community support volume; or you can't absorb the breaking changes already logged in 0.x (plaintext ephemeral tokens invalidated on deploy, completeTwoFactorLogin() signature change, RateLimiter now requiring a shared PSR-6 cache).
• If it's already in your codebase, treat this as a migration ticket, not a keep-or-drop debate: inventory which of the 28 interfaces and which providers you actually use, then map to the Symfony bundle, to Laravel-native, or to a managed provider. Budget for the token-hashing migration noted in the 0.1.0 changelog.
• Rough signal on the scoring: a composite score of ~6.9 with an opportunity score of ~12.6 reads as "solid engineering, near-zero market pull." Interesting as a reference implementation and as a requirements rubric; not as a dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): Authentication is commodity infrastructure with a permanent security-maintenance cost, and this package proves the scope is large but the market for another self-hosted PHP auth library is thin. The specific library is deprecated and archived, superseded by a Symfony bundle, with a single maintainer and no downstream users — so I'm not recommending adoption. I'm recommending we use its capability list as our requirements baseline and pick a route: a managed identity provider for speed and compliance coverage, or Laravel's native auth stack if we want zero vendor spend and accept owning the security surface. The one strategic item worth protecting in whichever route we choose is OIDC provider mode, because that's what unlocks enterprise SSO deals later.

For engineering (the ask): Don't adopt this artifact. DO use it as a checklist when we evaluate the alternatives — session + stateless token + hybrid in one config; Paseto V4 local encryption over JWT if we care about token opacity; Argon2id with opportunistic rehash; atomic refresh-token rotation with reuse detection that revokes the family; timing-safe anti-enumeration on both login and password reset; mandatory PKCE S256 for public OIDC clients; TOTP with anti-replay and rate limiting that fails loud rather than silently no-op'ing; and a documented risk-scoring model with explicit allow / log / reauth / terminate thresholds. If a candidate can't answer those, it's not cheaper — it's deferred work.

What would change the recommendation: the successor bundle shipping a maintained Laravel integration with Postgres support and more than one active maintainer. Failing that, this stays a reference document, not a dependency — and I'd rather spend the integration budget on a route with a support contract than on re-implementing 28 storage interfaces.