Auth Redis Storage Bundle Laravel Package

Product Decisions This Supports

• Token lifecycle infrastructure (build vs. buy): This package covers a well-understood but deceptively fiddly slice of auth infrastructure — token revocation (blacklisting) and "is this token still valid" tracking — with Redis SETEX doing the expiry bookkeeping for you. For most teams this is a buy/adopt rather than build: writing a correct blacklist with TTL semantics, key namespacing, and user-ID association is a week of work plus forever of edge cases.
• Auth feature roadmap: Unlocks or de-risks near-term roadmap items that depend on server-side token state — logout-everywhere, forced session revocation, admin "kill this user's sessions," password-change invalidation, refresh-token rotation with reuse detection, and per-token audit of the issuing user.
• Architecture direction: The DDD split (Domain contracts + Infrastructure Redis implementation) means the storage backend is a swap-in decision, not a lock-in. If you later need database-backed, DynamoDB, or multi-region Redis, you implement the interface rather than rewrite calling code. That's a meaningful hedge worth calling out in architecture reviews.
• Operational posture: TTL-based auto-cleanup means no cron job, no reaper process, no unbounded key growth — a small but real reduction in on-call surface.
• ⚠️ Platform correction — read before scoping: The release notes describe a Symfony bundle (Symfony DI container, configuration system, Symfony Flex recipe, TokenBlacklistInterface/RedisActiveTokenStorage), not a Laravel package. There is no Laravel service provider, no config/auth.php integration, no facade, no queue/Redis-connection abstraction aligned with Laravel's Redis facade. If this assessment was requested under the assumption this is a Laravel package, that assumption is wrong and the roadmap impact on a Laravel codebase is zero without an adapter layer. Do not put this on a Laravel sprint until someone confirms the target framework.

When to Consider This Package

Adopt it when:

• You are on Symfony (this is the gating condition) and already have a Redis client service wired into the container.
• You need stateless-token revocation — JWT JTIs, refresh token UUIDs — where "valid signature" is not the same as "still authorized."
• You want explicit logout / forced revocation semantics that survive across stateless API instances.
• You need a cheap "issued and not revoked" check on the hot path, and Redis latency is acceptable for your auth flow.
• You want a Flex-recipe install — low integration cost, minimal config (point it at your Redis client service, set prefixes).
• You value the QA posture: unit + integration tests, PHPStan, PHP CS Fixer, PHPMD, PCOV coverage, Docker dev environment. For infrastructure code sitting on your auth path, that's a reasonable proxy for "won't wake me at 3am."

Look elsewhere when:

• You are on Laravel. Nothing here is Laravel-native. You would be writing the integration yourself against Symfony-shaped interfaces — at which point you are most of the way to building it, and should evaluate Laravel-native alternatives or a thin in-house implementation.
• You need token issuance. This package manages state, not credentials. It does not mint, sign, or validate JWTs. It is one layer, not a solution. Pair it with a token issuer (LexikJWT, etc.).
• Redis is not already in your stack, or is not HA. Adding Redis as a hard dependency on the auth path is an availability decision, not just a caching decision. Auth checks now fail if Redis fails — understand your fallback behavior before committing.
• You need persistence/auditability. Redis with SETEX is ephemeral by design. If compliance requires a durable record of revocations, blacklist entries vanishing at TTL is a feature here, not a bug — but it is the wrong tool for an audit trail.
• You need fine-grained policy (scopes, roles, per-resource revocation, token families). This is binary state per token identifier. Sophisticated authorization needs more.
• v1.0.0 is the first stable release. No migration history, no long tail of production users, no track record. Reasonable to adopt for non-critical paths now; consider a bake period before it sits on your primary auth path.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, focused, first-stable-release component that lets users and administrators reliably end a session — logout everywhere, revoke a compromised token, force re-authentication after a password change. It is infrastructure, not a product feature, and its value is risk reduction: it closes a common and easily-exploited gap in token-based auth, where a "logged out" token remains technically usable until it expires. Integration cost is low and it comes with a credible test and quality toolchain. One caveat that matters commercially: despite being scoped to us as a Laravel package, this is a Symfony bundle. If our stack is Laravel, this does not apply to us as-is and should not enter a Laravel roadmap without an adapter — I'd want that resolved before we spend further evaluation time.

For engineering (technical summary): v1.0.0, first stable. Two contracts and two Redis implementations: TokenBlacklistInterface/RedisTokenBlacklist for explicit invalidation of token identifiers before natural expiry, and ActiveTokenStorageInterface/RedisActiveTokenStorage for marking identifiers active for their intended lifetime with optional user-ID association and a "should this still be considered valid" check. Both use Redis SETEX, so expiry and cleanup are delegated to Redis — no reaper process. Configurable global key prefix plus per-concern suffixes for shared-Redis collision safety. DDD-shaped: Domain interfaces, Infrastructure implementations — the backend is replaceable. Symfony DI and config integration, Flex recipe provided. Ships with unit and integration tests, PHPStan, PHP CS Fixer, PHPMD, PCOV coverage, and a Docker dev environment.

Engineering caveats to air now, not later: (1) Framework mismatch — Symfony bundle, not Laravel; confirm target stack. (2) Redis is on the auth hot path — decide the degraded-mode behavior when Redis is unavailable, because the default is fail-closed and you need to agree that's intended. (3) Ephemeral by design — TTL expiry means no durable revocation audit; if compliance asks for one, that is a separate store. (4) Maturity — v1.0.0 with no production track record; recommend a bake period on a non-primary auth path before it guards anything critical. (5) Scope — this manages token state only; it does not issue or cryptographically verify tokens, so budget for the issuer/verifier alongside it.