Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Login Laravel Package

alt-three/login

Alt Three Login is a Laravel package for adding social/OAuth authentication to your app. It provides a simple login flow that integrates with Laravel's auth system, giving developers a lightweight starting point for user sign-in and account handling.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. alt-three/login is a thin Laravel 5 service-provider wrapper around a League OAuth 2 server implementation, designed to make a Laravel application act as an authorization server issuing access/refresh tokens to third-party clients. That is a narrow, well-defined architectural role — but it is a role already owned by a first-party solution. Laravel Passport (released 2016, still maintained) occupies exactly this slot with the same underlying League lineage, full grant-type coverage, and framework-version parity. Choosing this package means adopting a lower-capability, unmaintained duplicate of a capability we can get from the framework vendor. Architecturally it is not a fit; it is a substitution for a fit we already have.

Integration feasibility. Technically installable, practically constrained. The package targets Laravel 5.x and a League OAuth 2 server generation pinned to that era. Modern Laravel (10/11/12) ships PHP 8.1+ requirements and League OAuth 2 server v8+, so Composer resolution will almost certainly fail on version constraints, and if forced through, we inherit an unpatched transitive dependency graph. The realistic integration work is a fork-and-revive: re-pin dependencies, port service providers to current container/console conventions, re-validate the token storage schema against our user model, and write the test coverage the package never had.

Technical risk. High, concentrated in one place: this is security-critical infrastructure with no security response capability. An OAuth 2 authorization server handles client registration, redirect URI validation, token issuance, refresh rotation, revocation, and scope enforcement. The archive date (Sept 2018) predates essentially every subsequent OAuth 2.0 Security Best Current Practice update, including the deprecation of implicit and password grants, mandatory PKCE for public clients, and stricter redirect URI matching. Any of those gaps is a potential token-theft or open-redirect vector, and there is no upstream to patch it. Secondary risks: 15 stars and zero dependents means no field validation, no community bug surface, and no one to ask when behavior diverges from spec. The 0.0975 score is consistent with that — treat it as a "do not adopt" signal, not a hidden gem.

Key questions.

  1. What is the actual requirement — issuing tokens to third-party clients, or authenticating our own SPA/mobile app? If the latter, Sanctum is simpler and we should not be running an OAuth server at all.
  2. Which grant types must be supported, and do any of them (implicit, password) exist only because this package's era encouraged them?
  3. Is there an existing token table / client registry already in production from this package? That changes this from greenfield to migration.
  4. Do we need OIDC (ID tokens, discovery, userinfo), which this package does not provide and Passport covers via an adjacent first-party package?
  5. What is our Laravel/PHP target, and is there any constraint forcing us below 8.1?

Integration Approach

Stack fit. Poor against a current stack, adequate only against a frozen Laravel 5 application we have chosen not to upgrade. Because the package's own dependency era is the Laravel 5 era, "use this package" and "stay on an EOL framework" are effectively the same decision. We should not let a 15-star archived package anchor our framework upgrade timeline.

Migration path. Recommend three tracks, in order of preference. (1) Replace with Passport if we genuinely need to be an OAuth 2 authorization server for external clients — same conceptual model, first-party maintenance, documented upgrade guides, and a supported path for token/clients table migration. (2) Replace with Sanctum if the need is first-party token issuance for our own clients — materially less surface area and no OAuth server to operate. (3) Fork and vendor only if there is a hard blocker (custom grant type, bespoke token format, regulatory constraint) that Passport cannot express; in that case we own it fully, including a named maintainer and a security review before first deploy.

Compatibility. Assume breaking. Expect to rewrite the service provider registration, re-verify the published migrations against our schema, and re-test every grant flow. Token format changes will invalidate existing tokens unless we deliberately preserve the storage contract — plan for a forced re-authentication of all clients at cutover, and communicate that to any external integrators.

Sequencing. (a) Inventory current usage and grant types; (b) confirm framework target; (c) spike Passport (or Sanctum) against a staging copy with real client configurations; (d) run both in parallel behind a feature flag if external clients exist; (e) dual-read token validation during transition; (f) cut over, revoke legacy tokens, decommission. Budget the parallel-run window generously — auth cutovers fail loudly and publicly.

Operational Impact

Maintenance. Total ownership transfer. There is no upstream, no issue triage, no CVE feed. Every hour spent on this package is an hour not spent on our product, and the cost recurs at each framework upgrade. This is the single largest line item and it does not amortize.

Support. None. No vendor, no active maintainer, no community of scale. Internal escalation path must be documented before adoption, not after the first incident.

Scaling. Not the primary concern — the League-derived core handles ordinary token throughput fine — but the package's caching and key-management story is thin compared to Passport's, and asymmetric key rotation is manual. Plan for key rotation runbooks we write ourselves.

Failure modes. The dangerous ones are silent: permissive redirect URI matching enabling token exfiltration; scope checks that default to allow rather than deny; refresh tokens that are not rotated or not invalidated on reuse; and a transitive dependency that drifts out of security support without any alerting. None of these produce an error page — they produce a compliant-looking login flow that leaks. Contrast with availability failures, which are noisy and recoverable. Weight the risk model accordingly.

Ramp-up. Low for a developer who knows Laravel's container and Passport's model — a day to read the source, since it is small. The real ramp-up cost is the security review required before we trust it, which is measured in weeks and needs someone who can read OAuth 2.0 BCP against the implementation.

Recommendation. Do not adopt. Treat alt-three/login as a reference for how the problem was solved circa 2018 and nothing more. Score the build as a small-to-medium Passport or Sanctum migration, funded now, rather than a dependency decision deferred to the next upgrade cycle.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
cgv/localized-resource