Signout should invalidate session server-side | サインアウト後にtoken自身も無効にして欲しい

[eternal-flame-AD]

💡 Summary

The semantics of "sign out" should mean the whole session is invalidated from server side, but the secrets are only cleared (partially) client-side.

This distinction is important when compromise or migration is considered, a couple realistic scenarios:

• A user logging in from a public computer or switching browsers.
• An instance temporarily losing domain and SSL certificates were issued by advertisers or attackers.
• A change in management of a server.
• A server admin receive information that one of their users may have been attacked and are requesting them take action to re-secure their account.

From implementation perspective, user tokens should be derived with cryptographic functions (like AEAD tied to session context) or enriched (like JWT) before being sent to the client, which will enable granular control of invalidating singular sessions.

🥰 Expected Behavior

When user press "sign out":

• All session tokens and cookies should no longer access allow protected resources.
• All other sessions should remain valid.

🤬 Actual Behavior

• The "token" cookie is still not cleared.
• The token itself is still valid.

📝 Steps to Reproduce

No response

💻 Frontend Environment

N/A

🛰 Backend Environment (for server admin)

* Installation Method or Hosting Service: Docker/Podman
* Misskey: 2025.2.1 (fork but tested on vanilla)
* Node: official docker distribution
* PostgreSQL: 17, custom docker container
* Redis: official docker distribution
* OS and Architecture: Linux x86-64

Do you want to address this bug yourself?

• Yes, I will patch the bug myself and send a pull request

[KisaragiEffective]

確かに現状では$iのトークンを無効化することはできず、期限もなかったはずなので無効化できるのは良さそうです。
ただ、「無効化されたトークン」を羅列すると実装が難しくなる可能性があるので、有効なトークンのハッシュをBCryptか何かで持っておいて、トークンを無効化する時はそのリストから取り除く、という手立ての方が良さそうです。

[eternal-flame-AD]

JWT has the "jti" field for identifying token by ID. We can just use that to encode a counter for user and record all (userid, revoked_counter, origial_iat) to identify invalid tokens and potentially do garbage collection.

Yes, the ideal situation is if the token is truly short lived we can just make an in memory list of tokens that are revoked but still possibly in valid period but it is difficult to do retroactively.

[eternal-flame-AD]

We probably can't do bcrypt, it is too expensive to do every time, we can do either just pure ID based matching or HKDF on the existing user secret and a counter.

[BoBeR182]

The misleading sign out, does not invalidate a device. While the sign out from all devices section invalidates a token. Many applications consider to expiry on a authentication token or reuse to be a security vulnerability.