Unless you are entering your credentials every time you perform an action on a website (click a button, navigate a page, submit a form), your session (or JWT in this case) is stored on your client and is accessible by your client.
So XSS can still extract usable tokens, regardless of the “remember me”.
JWTs have an access token (short lived) and a refresh token (long lived).
The refresh token allows the client to request a new access token without requiring further credentials (this is usually a stateful action and allows the server to check for banned accounts etc before issuing a new access token. It essentially “debounces” a lot of database activity, and still allows for a lot of authorisation of users).
However the access token is valid until it expires (unless servers run a stateful blocklist of tokens, which is unlikely).
The TTL of an access token defines the attack window.
5 minute tokens are more secure, however result in a lot more database hits due to more token refreshes.
30 minutes is still decent. A lot use 4 hours.
But once an access token is issued, it’s valid for its entire lifetime.
Maintaining a blocklist of invalidated access tokens (allowing instant user account blocking, instead of having to wait for access tokens to expire) is doable - because the tokens it has to store are short lived the dataset should be small and light.
This can even be done in-memory, with a 5m database poll to update the block list.
However, this becomes difficult to manage over distributed systems.
And it still leaves a 5 minute window.
The other way to invalidate JWTs is by rotating the secrets used to create them.
This will mean the server will not trust JWTs created with the old secrets. It’s a pretty nuclear option.
However this affects all tokens, so everyone has to reauthenticate.
It’s not the “remember me” checkbox.
Unless you are entering your credentials every time you perform an action on a website (click a button, navigate a page, submit a form), your session (or JWT in this case) is stored on your client and is accessible by your client.
So XSS can still extract usable tokens, regardless of the “remember me”.
JWTs have an access token (short lived) and a refresh token (long lived).
The refresh token allows the client to request a new access token without requiring further credentials (this is usually a stateful action and allows the server to check for banned accounts etc before issuing a new access token. It essentially “debounces” a lot of database activity, and still allows for a lot of authorisation of users).
However the access token is valid until it expires (unless servers run a stateful blocklist of tokens, which is unlikely).
The TTL of an access token defines the attack window.
5 minute tokens are more secure, however result in a lot more database hits due to more token refreshes.
30 minutes is still decent. A lot use 4 hours.
But once an access token is issued, it’s valid for its entire lifetime.
Maintaining a blocklist of invalidated access tokens (allowing instant user account blocking, instead of having to wait for access tokens to expire) is doable - because the tokens it has to store are short lived the dataset should be small and light.
This can even be done in-memory, with a 5m database poll to update the block list.
However, this becomes difficult to manage over distributed systems.
And it still leaves a 5 minute window.
The other way to invalidate JWTs is by rotating the secrets used to create them.
This will mean the server will not trust JWTs created with the old secrets. It’s a pretty nuclear option.
However this affects all tokens, so everyone has to reauthenticate.