3 ms·

My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate

My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Allow some or all tokens to "refresh" by calling a particular endpoint (call with valid token and get a token with expiry from now). Optionally add some form of identifier to the token (user_id works great) so that you can push a message out to your servers that looks like this: "All tokens for x expiring before y are invalid". Once time y has passed your server can forget about the message. This will be a very small set (often 0) as very few people use the "log out my devices" features. Logouts should be done client side by deleting the token. If you are worried about your token being sniffed you are either not using HTTPS, or sticking it somewhere stupid.

danielweber 10y ago
> Now all token s auto-invalidate after a certain period. You need to make sure that there is some process that will refuse to keep on re-upping the cookie lifetime. Otherwise an attacker could indefinitely keep the stolen cookie alive.
- merb 10y ago
  You CBS Combine a session cookie with a jwt Token That get sent over a Header
  - Normal_gaussian 10y ago
    Which gives you the worst of both worlds
- Normal_gaussian 10y ago
  If you see a suspicious usage pattern then force a login by invalidating the tokens. Allowing indefinite refreshing is a feature and a drawback of this method.
knz 10y ago
> Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Doesn't JWT already have this - "exp" is a reserved claim for expiration time? https://tools.ietf.org/html/rfc7519#section-4.1.4 https://tools.ietf.org/html/rfc7519#section-4.1.4 4.1.4. "exp" (Expiration Time) Claim The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.
- spydum 10y ago
  Yes but that is more for standard idle time expiration.. The problem being addressed above is for actively invalidating an existing JWT for a user once they already have it (and before the default/original expiry is met).

danielweber 10y ago

> Now all token s auto-invalidate after a certain period. You need to make sure that there is some process that will refuse to keep on re-upping the cookie lifetime. Otherwise an attacker could indefinitely keep the stolen cookie alive.

merb 10y ago
You CBS Combine a session cookie with a jwt Token That get sent over a Header
- Normal_gaussian 10y ago
  Which gives you the worst of both worlds
Normal_gaussian 10y ago
If you see a suspicious usage pattern then force a login by invalidating the tokens. Allowing indefinite refreshing is a feature and a drawback of this method.

knz 10y ago

> Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Doesn't JWT already have this - "exp" is a reserved claim for expiration time? https://tools.ietf.org/html/rfc7519#section-4.1.4 https://tools.ietf.org/html/rfc7519#section-4.1.4 4.1.4. "exp" (Expiration Time) Claim The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.

spydum 10y ago
Yes but that is more for standard idle time expiration.. The problem being addressed above is for actively invalidating an existing JWT for a user once they already have it (and before the default/original expiry is met).