usmonaliyev/laravel-redis-auth
Laravel Redis Auth adds Redis-backed authentication to Laravel, enabling fast, scalable user login and auth data storage through Redis instead of a traditional database user provider. It integrates with Laravel’s auth guard and provider system.
Architecture fit. Laravel’s auth stack is contract-driven (UserProvider, Guard), so a Redis-backed provider can slot in at the provider layer without rewriting guards. The "authorization" half of the package is the weaker claim: Gates and Policies assume Eloquent models with relationships, and moving identity to Redis breaks relationship traversal, joins, and relational RBAC unless roles/permissions are denormalized into Redis values. Fit is therefore narrow — high-throughput, low-relational auth (token/session-centric, stateless or edge deployments) — and poor for products whose authorization logic queries related tables. Release 1.5.1 does not change this calculus; it is a naming refactor inside the provider trait only.
Integration feasibility. Feasible in principle (custom provider registration in config/auth.php, likely a bundled user model), but the package’s maturity signals remain weak: 7 stars, 0 dependents, a single maintainer, score 0.035, and the prior release was September 2024. There is still no evidence of a Laravel version support matrix, CI, or security review. Integration effort is low on paper and high in practice because the team will end up owning and auditing the code. 1.5.1 adds a concrete data point on release discipline: a public method (connection) was renamed to redisAuthConnection in a patch release. That is a semver-breaking change for any consumer that extended the trait, overrode the method, or called it directly, shipped without a major/minor bump or a stated deprecation path. Treat version numbers from this package as advisory, not as a compatibility contract.
Technical risk. High, concentrated on the security-critical path. Specific risks: durability (Redis is commonly deployed as cache, not source of truth), silent data loss under eviction policies, compatibility drift with Laravel 11/12 auth scaffolding (Breeze/Fortify/Jetstream/Sanctum), concurrency correctness for tokens, and bus factor of one. Password hashing presumably stays in-app, which is fine, but password reset, email verification, 2FA, and account lockout flows need explicit verification. The 1.5.1 rename introduces two additional risks: (a) upgrade breakage if your codebase or any local patch references connection() on the trait, and (b) the rename is most plausibly a collision fix — connection() is a hazardous method name to mix into a model, since Eloquent already exposes connection semantics — which implies trait-composition hazards existed and may exist elsewhere in the provider. Confirm whether a backwards-compatible alias was left behind and whether the rename is purely internal or reachable from user-facing extension points.
Key questions.
Illuminate\Contracts\Auth\UserProvider cleanly, or fork core auth behavior?maxmemory-policy, AOF/RDB, replication, and cluster mode?connection → redisAuthConnection rename a breaking change, is there an alias, and under what versioning policy are public trait methods changed? What collision motivated it, and are other trait methods similarly exposed to collision with Model/Guard members?Stack fit. Adopt only if you are already Redis-operational and have a genuine throughput or statelessness driver. If the motivation is "make auth faster," standard Laravel + Sanctum with Redis for sessions/cache already delivers most of the benefit while keeping SQL as source of truth. This package is a poor fit where reporting, GDPR erasure workflows, complex RBAC, or admin tooling depend on relational user data.
Migration path. Do not cut over directly. Sequence: (1) spike in a sandbox against your exact Laravel/PHP/Redis versions, pinned to a specific tag or commit rather than a version range; (2) contract and security review of the provider and serialization code; (3) harden Redis (persistence, replication, noeviction, backups) before it becomes tier-0; (4) dual-write users to Redis and SQL with SQL authoritative; (5) shadow-read from Redis and diff against SQL to validate parity; (6) canary a small percentage of logins behind a feature flag; (7) full cutover with a tested rollback to the SQL provider; (8) soak, then decide whether SQL remains authoritative indefinitely.
Compatibility. Verify against your current auth scaffolding, Sanctum/Passport, queue/notification flows, and both predis and phpredis clients. Confirm cluster-mode behavior and key namespacing if you shard. Given 1.5.1, do not float the dependency: lock to an exact version, review every diff before bumping (the rename would have been invisible in a ^1.5 upgrade until runtime), and vendor/fork on first sign of unresponsiveness. If you have already forked, absorb the rename deliberately and search your codebase and any local patches for connection( call sites on the provider before upgrading.
Sequencing. Treat Redis HA and backup/restore drills as a prerequisite, not a follow-up. Run the spike and security review in parallel in one sprint, then dual-write plus shadow-read in the next, then canary. Do not decommission the SQL auth path until at least one full incident drill and a backup restore have succeeded against the Redis-backed path. Add a standing step to your upgrade runbook: diff the package's public trait surface across versions, since patch releases cannot be assumed safe.
Maintenance. Effectively an internal fork from day one. With one maintainer, 7 stars, and sparse releases, assume you own upgrades, Laravel compatibility patches, and security fixes. 1.5.1 confirms the concern rather than allaying it: the package is still alive, but a breaking rename in a patch release means upgrade diffs must be read line by line, not trusted to semver. Assign a named code owner and add dependency-review and SAST coverage around the auth path.
Support. No commercial backing; community-only issue response. Escalation is "fix it ourselves." This is acceptable only with an internal owner who understands the provider internals.
Scaling. Redis scales well for reads and token throughput, but user records live in memory, so cost grows linearly with user count and is materially higher per user than a SQL row on disk. Plan capacity, sharding/cluster topology, and AOF rewrite headroom early. Persistence tuning adds latency and operational surface.
Failure modes. Redis outage equals total authentication outage — a tier-0 blast radius that must appear in the incident runbook. Eviction policies can silently delete accounts; enforce noeviction or a carefully scoped policy and alert on evictions. Non-persistent Redis means identity loss and mass lockout. Failover can produce split-brain or stale reads. Key-schema changes require online migration discipline. Token replay risk if TTLs and rotation aren't atomic. Add a packaging failure mode: a silently pulled or renamed public method breaks login at deploy time with no compile-time warning, and rollback depends on having pinned the previous tag.
Ramp-up. The team needs depth in Redis operations (persistence, replication, failover, memory management) and Laravel auth internals (guards, providers, session/token lifecycle). Estimate one to two sprints for the spike plus hardening for a small team, plus ongoing on-call ownership. Recommend proceeding only with an explicit decision that Redis becomes a tier-0 identity store, or scoping the package to token/session caching while SQL remains authoritative.
How can I help you explore Laravel packages today?