- What does overtrue/laravel-passport-cache-token do?
- It caches Laravel Passport access tokens in your configured cache store so bearer-token authentication can validate from memory instead of querying the oauth_access_tokens table on every request. It is a drop-in caching decorator around Passport's token repository and does not change token issuance, grants, scopes, or your auth flow. The main benefit is fewer per-request database reads on high-traffic authenticated APIs.
- How do I install and configure it in a Laravel application?
- Install it with Composer using overtrue/laravel-passport-cache-token, then publish the package config. Set the cache store, TTL, and key prefix explicitly rather than inheriting defaults, and consider registering the provider behind an environment flag so it can be disabled per environment. No changes to your Passport guards or token issuance should be required.
- Which Laravel and Passport versions does this package support?
- Release 3.2.0 adds Laravel 10 support, while Laravel 9 users see no functional change from that release. The package targets Laravel 9 and 10 applications using Passport and a shared cache. Before upgrading, confirm the resolved Passport constraint matches production, because the exact Passport version matrix such as Passport 10 versus 11+ should be verified rather than assumed.
- Is it compatible with existing Laravel Passport guards and middleware?
- Yes. It slots in at the resource-server boundary and is intended to remain compatible with Passport's existing guards and middleware. It does not fork Passport or alter authorization-server behavior such as grants, scopes, refresh flow, or token issuance. You can remove it by unregistering the service provider.
- Which cache stores can I use with this package?
- The package supports any configured Laravel cache store, including Redis, Memcached, database, and file drivers. For multi-node applications, use a shared store such as Redis or Memcached rather than per-node file or array caches. Per-node caching can cause authentication behavior to diverge between instances.
- How does the cache TTL affect token revocation and security?
- The TTL defines the maximum time a cached token can remain usable, so it is a security-relevant staleness window. The package claims automatic invalidation for revoke and refresh flows, but you should confirm it hooks your logout, password-change, and admin-forced termination paths. Set the TTL deliberately and keep it bounded by the token's own expiry.
- What happens if Redis or the cache store is unavailable?
- The provided overview and release notes do not clearly state whether cache writes and reads fail open or fail closed when the store is down. Fail-closed behavior produces authentication errors during a cache outage, while database fallback preserves availability with a latency spike. Resolve this in a spike or with the maintainer before relying on it in production.
- Is it safe for multi-node and multi-tenant deployments?
- Use a cache store shared across all application nodes, and scope cache keys by environment and tenant. Set the key prefix explicitly so different environments or tenants cannot collide. If key derivation changes between package versions, expect a thundering-herd revalidation on upgrade, so test upgrades carefully.
- Will it actually reduce database load for a high-traffic API?
- Yes, its main purpose is to remove one indexed read against oauth_access_tokens from the hottest authenticated request path. That matters most when you have meaningful bearer-token traffic and the database read is a bottleneck. For low-volume APIs or stacks with per-node file caches, the benefit may be limited and the added cache layer may not be worth the operational risk.
- How is the package maintained, and what should I consider before choosing it?
- It is a single-maintainer community package, and Laravel 10 support arrived through a community pull request rather than maintainer work. That makes bus factor, support window, and security-review responsiveness important questions. Alternatives include no token caching, a custom decorator around Passport's token repository, or another token-caching layer; choose based on your revocation guarantees and cache topology.