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.
Redis-backed auth makes the most sense when you need very fast credential/token lookups and don't want user records in the primary SQL database. The package is small and low-adoption, so treat the README, src/, and the test suite as the source of truth before wiring it into production. The 1.5.1 release confirms active maintenance — and confirms the API is still shifting (see the rename below), so budget for upgrade work.
Install and inspect the surface area first:
composer require usmonaliyev/laravel-redis-auth
Open vendor/usmonaliyev/laravel-redis-auth/src and look at the ServiceProvider, the RedisAuthentication trait, and any config/ file. Confirm what it registers (a guard driver, a user provider, a user model/trait, or a facade) before changing config/auth.php.
Publish the config if the service provider exposes one:
php artisan vendor:publish --provider="Usmonaliyev\RedisAuth\RedisAuthServiceProvider"
Verify the exact tag/class in the README — a small package often has only one publish tag.
Add/confirm a Redis connection in config/database.php and .env:
REDIS_CLIENT=phpredis # or predis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
Prefer a dedicated database index (e.g. REDIS_DB=2) and/or a key prefix so auth keys don't collide with cache/queue keys.
Point an auth guard at the package's provider in config/auth.php:
'guards' => [
'api' => [
'driver' => 'redis', // whatever driver name the package registers
'provider' => 'redis-users',
],
],
'providers' => [
'redis-users' => [
'driver' => 'redis', // or the package's provider driver
// model / connection / prefix keys, per the published config
],
],
First use case: if you're upgrading rather than installing fresh, start by grepping for ->connection( and ::connection( on models using the RedisAuthentication trait — that method is now redisAuthConnection() (see Gotchas). Then create one user record via whatever API the package exposes (an artisan command, a model create(), or a repository method) and hit an authenticated route with Auth::guard('api')->attempt([...]) or the documented token flow. Getting one round-trip (write user → issue token → auth:api middleware passes) working is the real smoke test.
If step 5 is fiddly, stop and read the package tests — for a low-adoption package, the test suite is usually the most accurate documentation of expected usage.
Guard + provider wiring. The cleanest integration is to leave your existing web guard on Eloquent and add a separate Redis-backed guard for the API/token surface. That gives you a low-risk migration path: Redis for hot-path auth (sessions, tokens, API keys), SQL for anything relational.
Token-first auth. Typical day-to-day usage in a Redis-auth package is issuing opaque tokens and storing token_hash -> user_id (plus metadata: created_at, expires_at, ip, user_agent) as a Redis hash or string with a TTL. Verify requests by GET on the hashed token, not by scanning. Treat the token as the primary key and avoid secondary indexes unless the package explicitly builds them.
Storing users as hashes. If the package persists user records in Redis, keep the record flat (name, email, password bcrypt hash, roles as a JSON/CSV string). Don't try to model relationships — Redis is a key-value store, and the package almost certainly doesn't provide Eloquent relations. For anything relational, keep the canonical user in SQL and cache only the auth-relevant slice in Redis.
Consume the trait, don't shadow it. The 1.5.1 rename (connection → redisAuthConnection on the RedisAuthentication trait) is a hint about how the package expects to be used: models use RedisAuthentication and call the trait methods directly. If you need a different connection per model, override redisAuthConnection() in your model rather than defining a competing connection() method — that's the documented extension point and it survives minor releases cleanly.
use Illuminate\Foundation\Auth\User as Authenticatable;
use Usmonaliyev\RedisAuth\Traits\RedisAuthentication; // verify namespace in src/
class RedisUser extends Authenticatable
{
use RedisAuthentication;
public function redisAuthConnection(): string
{
return 'redis-auth'; // dedicated connection, not the shared cache one
}
}
Session store coupling. You can combine this with Laravel's redis session driver and redis cache driver so a single Redis instance serves sessions, cache, and auth. That's a good ops story, but isolate key prefixes per concern so a FLUSHDB during debugging doesn't log everyone out.
Middleware and policies. Because the guard returns a user object (or a fake authenticatable), Auth::user(), $request->user(), Gate::allows(), and policies should work normally — authorization logic doesn't need to know Redis is behind it. Keep policies on the user model/trait the package returns, so can: middleware and form requests behave the same as with Eloquent.
Hybrid pattern (recommended for most teams). Keep users in SQL, use Redis only for the auth token/session table. On login, Auth::attempt() against Eloquent, then write a token to Redis via the package. On logout, DEL the token. This gives you fast verification and a simple revocation story without giving up relational data — and it insulates you from trait-level churn like the 1.5.1 rename.
Testing. For feature tests, point the redis connection at a test DB index and flush it in setUp():
protected function setUp(): void
{
parent::setUp();
Redis::connection('default')->flushdb();
}
Or better, use a redis service container in CI (Docker) rather than mocking the client — mocks around guards/Redis tend to leak implementation details into tests. Add one test per trait method you actually call so a future rename fails loudly.
connection() on the RedisAuthentication trait is now redisAuthConnection(). There is no stated deprecation alias, so any model, subclass, or service provider that called or overrode connection() will break on upgrade. Grep your codebase and any vendored copies before bumping composer.json, and check whether you were relying on the trait method or on Eloquent's own connection() — if you weren't overriding it, no action needed.appendonly yes (AOF) or save points for RDB if auth state matters. If Redis is used as a pure cache with maxmemory-policy allkeys-lru, auth keys can be evicted and users silently logged out. Pin the policy (noeviction or volatile-*) and keep auth on a separate instance/index if possible.EXPIRE/SETEX them. Confirm the package sets TTLs on tokens; if not, you will accumulate keys forever. Add a scheduled job or expiry check for tokens if the package stores them without TTL.where on Redis without building indexes yourself. Any "list all users" or "find users by role" feature needs a secondary set (SADD role:admin user_id) and careful maintenance. Don't plan features that need cross-entity joins.KEYS vs SCAN. If the package or your debugging uses KEYS *, it blocks Redis on large datasets. Use SCAN in tooling and never in request paths.REDIS_PREFIX, or a package config key) so local, staging, and production never share auth keys. This is the most common self-inflicted incident with Redis auth packages.serialize(), msgpack) must be consistent. If you inspect keys with redis-cli, expect garbled values for PHP-serialized payloads — that's normal, not corruption.Hash::make and not plaintext. Check the write path explicitly; a low-adoption package may not have hardened this."usmonaliyev/laravel-redis-auth": "1.5.1") rather than using ^, read the changelog before each bump, and consider forking/vendoring if you depend on it in production. There is little ecosystem feedback loop if a Laravel upgrade breaks it.Auth::extend() / Auth::provider() in a ServiceProvider — avoid editing vendor files. For per-model connection control, override redisAuthConnection().redis-cli MONITOR on a dev instance is the fastest way to see what keys the package actually reads/writes, which is often faster than reading source. Use redis-cli --scan --pattern '<prefix>*' to enumerate.SCAN behave differently; confirm the package doesn't rely on cross-slot commands before pointing it at a clustered instance.auth:v1:*) so you can roll back by switching the prefix.How can I help you explore Laravel packages today?