Laminas Authentication Laravel Package

Product Decisions This Supports

• Build vs. buy on authentication plumbing. This package is a credential-verification abstraction, not an auth product. It supports the decision to not hand-roll adapter logic for LDAP, HTTP Basic, Digest, or database-backed credentials, while leaving the product-level auth surface (registration, password reset, MFA, session policy UX) as your own roadmap items.
• Scope boundary for the auth roadmap. Because the package deliberately separates verification (adapters) from identity persistence (session/custom storage), it gives you a clean seam to decide which capabilities you own versus delegate to an IdP. Typical split: you own identity storage and session lifecycle; you delegate federation, MFA, and password policy to a hosted provider.
• Enterprise/B2B readiness decisions. The bundled LDAP and HTTP adapters are the strongest product lever here: they let you commit to "works with the customer's directory" as a roadmap item with modest engineering cost, which is often a deal-qualifier in B2B sales.
• Legacy and M&A integration. For Laminas MVC or Mezzio codebases — including acquired or inherited PHP applications — this supports a "stabilize, don't rewrite" decision: standardize on a supported abstraction rather than freezing bespoke auth code.
• Risk-adjusted platform choice. Weak adoption signals (≈25 stars, low opportunity score) argue for treating this as a component, not a platform bet. The decision it best supports is: adopt behind an internal interface so a future swap to Symfony Security, Laravel's native guard system, or a hosted IdP is a contained change.
• Not a differentiator. Nothing here is a competitive feature. Frame any adoption as cost avoidance and risk reduction, never as product innovation.

When to Consider This Package

Consider it when:

• You are already on Laminas MVC or Mezzio, or your stack is PSR-7/PSR-15-centric with other Laminas components — integration cost approaches zero.
• You need multiple credential sources behind one interface (e.g., local DB users and a customer's LDAP directory) and want that polymorphism without designing it yourself.
• You want structured failure information — the AuthenticationResult object exposes success, code, and messages, which makes auth failures auditable and translatable into user-facing messaging without string-matching exceptions.
• You need a stable, permissively licensed (BSD-3-Clause) dependency with no per-seat or per-MAU cost, in an environment where procurement for a hosted IdP is slow.
• The application is internal, admin-facing, or a back-office tool where the auth surface is intentionally thin.

Look elsewhere when:

• You are on Laravel. The framework already ships a guard/provider system with session persistence, plus Fortify, Breeze, Sanctum, and Passport for the product-level features. Pulling in a second, parallel authentication framework creates two sources of truth for the authenticated user — a persistent source of security bugs. Prefer a custom Laravel guard/provider if you need LDAP-like behavior.
• Your roadmap includes OIDC/OAuth2, social login, passkeys/WebAuthn, MFA, or passwordless. This package covers none of it, and its adapters are oriented toward legacy credential schemes (HTTP Basic, Digest) that most modern security reviews discourage.
• You need password hashing policy, breach-list checks, rate limiting/lockout, audit logging, or session fixation controls. Those are adjacent to this package's scope, and gaps here become findings in a security review.
• Compliance or enterprise procurement requires an IdP with SOC 2 / ISO evidence. Buy the certified thing.
• Team and talent risk matters. A small contributor base means a thinner hiring pool, slower issue response, and a real (if low) chance you inherit maintenance. Weigh this explicitly against the BSD license's freedom to fork.
• You need guaranteed long-term support. A 2025-10 release is a positive signal, but community size — not release recency — predicts five-year survivability.

How to Pitch It (Stakeholders)

To executives: This is a small, free, permissively licensed building block for login plumbing — it verifies credentials and keeps the user's identity in session across requests. It replaces custom auth code we would otherwise write and maintain ourselves, and it gives us LDAP/directory login capability that often comes up in enterprise deals. It is explicitly not a complete identity product: it does not do MFA, single sign-on, social login, or password reset, so it does not remove those items from the roadmap or the budget. The main risk is community size — adoption is thin, so we treat it as a swappable component behind our own interface rather than a long-term platform commitment. Net recommendation: adopt only where we already run Laminas/Mezzio or have a specific LDAP requirement; otherwise the framework-native option or a hosted identity provider is the better commercial call.

To engineering: Clean, narrow contracts — pluggable adapters for verification, pluggable storage for persistence, and a result object that carries codes and messages instead of throwing. That separation makes it testable and lets us wrap it so a future migration is contained. Constraints to plan around: no MFA, no OAuth/OIDC, no rate limiting, no password policy, and the HTTP/Digest adapters should not be used for new internet-facing surfaces. On Laravel, do not stack this alongside the native Auth manager — implement a custom guard/provider instead. Budget effort for the wrapper layer and for the security controls this package intentionally leaves out.