3 ms·

Ill chime in with my $0.02 * Inability to invalidate stateless JWT tokens can be more or less be remedied with a short expiration time of the token and a toke

by vladgur 10y ago

Ill chime in with my $0.02 * Inability to invalidate stateless JWT tokens can be more or less be remedied with a short expiration time of the token and a token refresh flow. If a token is only valid for 5 minutes, and you can only refresh the token during that 5 minute window, it greatly reduces the attack vector. If that risk is too high, you should easily implement state with the same Redis setup that author mentions * a classic CSRF example where youre logged into your app in one tab and you open a malicious link in another tab is not a threat if you, like the author suggests, use cookies for storage, but not for authentication. If you pass a token around in an "Authentication" header and have the server IGNORE the cookie which will inadvertently be sent, the request made in another tab via a malicious website is not going to be authenticated. There are definite Usability and security pros to using Session cookies for storage: * Unlike Session Storage, the cookies are visible by your application if you have two instances of it running in different tabs/windows. * Unlike Local Storage, session cookies get wiped out when the user closes their browser

rahkiin 10y ago
If you give the tokens an expiration time of 5 minutes, the application either needs to auto-request a token every 4-5 minutes automatically using a JavaScript timer, or your session times out way too quickly. If you close the tab, you will be logged out within 5 minutes. That may not be desired in many applications.
- mstade 10y ago
  You don't have to use a timer, you can also do it when you're about to use the token, or after the token has been rejected if you're so inclined. I.e. before you make a request you check the validity of the token and if it's not valid you refresh it; or if you don't do this validation you'd have to deal with the server rejecting your token, doing the refresh, and then trying the original request again.
- vladgur 10y ago
  That correct. You would use the timer to auto-refresh the token. Note: if you close the tab, if you use a session cookie for token storage, its likely to remain, but like you said will become invalid within 5 minutes. If you close the browser however, a Session cookie will be deleted, which mitigates an issue in a shared setting. Depending on the requirements, you can ask a user whether they are using a shared pc or a private pc and choose cookie storage at that point.
jsdalton 10y ago
Yes, I like this approach and it creates the opportunity for a hybrid approach between stateless JWT tokens and stateful sessions: * JWT tokens can have a "short" expiration time, as you suggest, and within that time can be used in a stateless manner -- i.e. they do not need to be validated against a central session store, etc. * The refresh token process can use a more traditional session type configuration, where the token is checked against a central session store. The refresh can be refused if the central "session" has been revoked, e.g. This to me gives you all the benefits of JWT (e.g. you can use federated authentication services) and the benefits of a centralized session store (e.g. easy revocability). The main concern would be if you needed more "immediate" revocability within the stateless time frame. One solution would be to implement a "blacklist" that holds a temporary list of revoked tokens (and a token only needs to live on that list for as long as its expiration window). Alternatively, at that point you could just stick to a traditional session.

by vladgur 10y ago

rahkiin 10y ago

If you give the tokens an expiration time of 5 minutes, the application either needs to auto-request a token every 4-5 minutes automatically using a JavaScript timer, or your session times out way too quickly. If you close the tab, you will be logged out within 5 minutes. That may not be desired in many applications.

mstade 10y ago
You don't have to use a timer, you can also do it when you're about to use the token, or after the token has been rejected if you're so inclined. I.e. before you make a request you check the validity of the token and if it's not valid you refresh it; or if you don't do this validation you'd have to deal with the server rejecting your token, doing the refresh, and then trying the original request again.
vladgur 10y ago
That correct. You would use the timer to auto-refresh the token. Note: if you close the tab, if you use a session cookie for token storage, its likely to remain, but like you said will become invalid within 5 minutes. If you close the browser however, a Session cookie will be deleted, which mitigates an issue in a shared setting. Depending on the requirements, you can ask a user whether they are using a shared pc or a private pc and choose cookie storage at that point.

jsdalton 10y ago

Yes, I like this approach and it creates the opportunity for a hybrid approach between stateless JWT tokens and stateful sessions: * JWT tokens can have a "short" expiration time, as you suggest, and within that time can be used in a stateless manner -- i.e. they do not need to be validated against a central session store, etc. * The refresh token process can use a more traditional session type configuration, where the token is checked against a central session store. The refresh can be refused if the central "session" has been revoked, e.g. This to me gives you all the benefits of JWT (e.g. you can use federated authentication services) and the benefits of a centralized session store (e.g. easy revocability). The main concern would be if you needed more "immediate" revocability within the stateless time frame. One solution would be to implement a "blacklist" that holds a temporary list of revoked tokens (and a token only needs to live on that list for as long as its expiration window). Alternatively, at that point you could just stick to a traditional session.