Username Authenticator Extension Laravel Package

Product Decisions This Supports

Feature scope: username-based login. The package targets the "can users sign in with a username instead of an email?" question — a small but product-visible decision that touches onboarding copy, error states, account recovery, and support load. This extension is a reference point for that decision inside the Visiosoft/OpenClassify (Streams Platform) ecosystem, not a general-purpose Laravel auth library.

Identity model on the roadmap. Choosing a username as a first-class identifier (rather than an email alias) unlocks marketplace handles, seller profiles, and pseudonymous participation. It also constrains future work: uniqueness rules, reserved-word lists, rename policy, and how email changes interact with login. Treat this as an input to the identity-model decision, not just a login-screen tweak.

Build vs. buy — leaning build. With zero stars, zero dependents, and no release since October 2021, this is effectively unmaintained. The honest PM framing is: buy is not on the table; borrow the pattern is. Budget roughly a few days of engineering to implement an equivalent custom authenticator (user provider + guard wiring) directly in your app, with tests and current framework support.

Use cases where it earns its keep. Classifieds and marketplace platforms (the OpenClassify lineage), community/forum products, migrations off legacy systems where usernames are already canonical, and privacy-sensitive products that don't want an email address displayed as the login identifier.

Secondary signal. The existence and abandonment of niche extensions like this is itself useful competitive/ecosystem intelligence: it tells you the upstream platform's auth surface is extensible, and that the community around it is thin enough that you should assume you own maintenance.

When to Consider This Package

Consider it when:

• You are already running Streams Platform / PyroCMS / OpenClassify and need username auth without touching core.
• You want a worked example of how that platform registers a custom authenticator — reading the service provider is likely higher value than installing it.
• Your team accepts vendoring or forking, pins the dependency, and has a named owner for security patches.
• Your PHP/framework versions match the 2021-era constraints, or you're prepared to port.

Look elsewhere when:

• You're on greenfield Laravel — use Fortify, Breeze, or Jetstream and add a username column with a custom attempt() call. That is the whole feature.
• You need dual login (email or username), case-insensitive uniqueness, reserved words, or rename history handled out of the box.
• You need MFA, passkeys, social login, rate limiting, or audit logging as part of the auth story.
• You require maintained dependencies, a security response commitment, or current Laravel/PHP support — none of which this offers.
• Auth is revenue-critical with an SLA. Zero adoption means zero community eyes on the code.

Verification step before any decision: read the composer constraints and the service provider. The name suggests scope; the code determines whether it's a drop-in authenticator, a UI field addition, or a stub.

How to Pitch It (Stakeholders)

To executives (one paragraph): There is a small open-source extension that lets users log in with a username rather than an email. It is free, but it has no users, no maintainers, and no updates since 2021, so we should not adopt it as a dependency. It is still useful: it confirms the feature is straightforward to build ourselves, gives us a reference implementation, and costs days rather than a quarter. Recommendation: build the capability in-house, use this only as a pattern, and treat the roadmap decision — do we want usernames to be a first-class identity in our product? — as the real item to decide.

To engineering: Treat this as sample code. Expect to write the guard/provider wiring ourselves, add tests, handle case-insensitive collisions and reserved names, and decide the recovery flow when a user forgets a username (this is the part teams underestimate). Estimate: a few days for a clean implementation in current Laravel, plus design time on rename policy.

To product/design: The visible win is a friendlier, less email-exposing login and marketplace-style handles. The visible cost is a new class of support tickets: "I forgot my username," impersonation-adjacent handles, and rename requests. Decide those policies before shipping the field.