Phalcon credential expiration and session invalidation strategy

Credential expiration & session/token invalidation in Phalcon 5.x

Implement a password_changed_at column, destroy the session when the password field changes, and use middleware to verify JWT blacklists before ACL evaluation. The recommended storage for both session and JWT revocation is Redis, as it integrates with Phalcon's session adapter and provides fast key-value access.

Likely explanation

The framework does not ship built-in expiration logic, so you must add a timestamp and hook into the request lifecycle. Centralizing the check in a single place avoids scattering code across controllers.

Confirmed facts

• Phalcon 5.x requires a manual password_changed_at column; login code must compare it with the current time.
• Model events such as beforeUpdate (or afterUpdate) fire when the password field is modified, allowing you to call $this->session->destroy() to invalidate the current session.
• JWT token revocation is not automatic; you must maintain a blacklist of token identifiers (jti) and query it in a request-level middleware before signature verification.
• Phalcon's EventsManager and Micro middleware (e.g., beforeRequest) provide entry points to run the checks once per request.
• Redis works best for the blacklist because it can be shared with the session store, reducing latency compared to relational databases or APCu.

Steps to centralize the logic

1. Add a password_changed_at datetime column to the user table (if not present).
2. In the User model, define a beforeUpdate event that checks if ($this->passwordChangedAt && $this->passwordChangedAt < time()) { $this->session->destroy(); } and re-assign the session key.
3. Create a JWT middleware (e.g., beforeRequest) that extracts the token's jti, queries Redis for its presence in the blacklist, and aborts the request if found.
4. Configure Phalcon's session adapter to use Redis (e.g., new \Phalcon\Session\Adapter\Redis) so that session destruction and blacklist lookups share the same backend.
5. Test: change a user's password, verify that the existing session is cleared, and that subsequent requests reject the old JWT.

Missing diagnostic

Confirm that you can add a password_changed_at column to the user schema; if this is not possible, an alternative signal (e.g., a separate "password_version" integer) must be used to detect changes.