Session security hardening
Suspending a user now ends their session immediately instead of waiting for the next login. Small in code, meaningful for access control.
What shipped
Suspending a user who is already logged in now ends their session right away. That user's refresh-token family is revoked, so residual access is capped at, at most, the lifetime of the access token still in hand: minutes, not the whole life of the session.
Why it matters
"Suspended" has to mean suspended now. When an operator disables a user, the expectation is obvious: that person loses access. A system that only enforces the suspension at the next login leaves a window where someone already marked as suspended keeps working.
This release closes that window. The status check, which previously lived only on the login path, now also applies when a session is renewed. The result is behavior that matches intent: suspend, and it's over.
The bigger picture
Security changes like this are rarely large in lines of code, this one is tiny. What matters is the guarantee it establishes. Every SDK release tightens the gap between what access control promises and what it does, and this is one of the ones that makes the promise literal.