These credentials do not match our records. – Sanctum token persistence after password change
0 reputation · 03 Mar 2024, 13:27 UTC
0 reputation · 03 Mar 2024, 13:27 UTC
When a user updates their password in a Laravel Jetstream application, the goal is to immediately invalidate any existing Sanctum API tokens and authenticated web sessions so that leaked or stale credentials cannot continue to be used, aligning with a least‑privilege security model.
Jetstream’s default Fortify implementation does not automatically revoke tokens or sessions upon a password change, leaving previously issued credentials valid until their natural expiry. This behavior can be altered by custom Fortify features or event listeners, but the documentation does not clarify whether token revocation is intentionally omitted or configurable.
Is there a built‑in configuration flag to enable automatic token revocation on password change? How can developers safely hook into the password‑change event to delete Sanctum tokens without overriding Jetstream’s core? Does Fortify provide an observable event that can be used to invalidate both API tokens and web sessions?
32775 reputation · 03 Mar 2024, 17:17 UTC
No built‑in configuration flag exists in Fortify, Jetstream, or Sanctum to automatically revoke Sanctum API tokens or web sessions when a user changes their password.
PasswordUpdated event after a successful password update; it receives the updated $user instance.$user->tokens()->delete() (all personal access tokens) or $user->currentAccessToken()->delete() (the token used for the request).Auth::logoutOtherDevices($password), which requires the user’s current plaintext password.PasswordUpdated event in EventServiceProvider. The listener can call $user->tokens()->delete() to revoke all API tokens. If you need to invalidate the current web session, call $request->session()->invalidate() and regenerateToken().Auth::logoutOtherDevices($password), use the Fortify::updateUserPasswordsUsing callback in FortifyServiceProvider. This callback receives the user, the new password, and the current password before the change is persisted, allowing you to revoke tokens and sessions safely.php artisan event:list to confirm the PasswordUpdated event is registered.personal_access_tokens table; rows for that user should be removed.sessions rows for the user are deleted (except possibly the current session).Does your application use Sanctum for first‑party SPA authentication (cookie‑based) or only for API tokens? This determines whether revoking all tokens with $user->tokens()->delete() is appropriate or whether selective revocation is required.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.