When you set a key to expire in memcached does it actually get deleted when the expiration is up, or does it get deleted once the key is requested (get) and expiration has expired. In other words, does expiration automatically delete the value from memcached, or simply flag it as expired?
Thanks.
Expiration is lazy. If you do a get on an expired key it is deleted. Otherwise it is flagged and when you run out of space in your cache it will be removed to make room for a new item.
Related
I am using a JWT token implementation of this https://jwt-auth.readthedocs.io/en/develop/quick-start/
I need to update the secret key and is there a way to update it without logging out every user? I presume it's not possible to reuse the old token once my secret key is changed. So all my users will be logged off and need to log in again. Is there any way to go around this?
If not, if for security reason, I need to update the secret monthly, that will be pretty troublesome to ask my user to re-login monthly.
Thanks!
If you change your keys it's correct to invalidate all the tokens signed with the old ones as they are to be considered expired.
It's a good practice to let the token expire as well after a certain amount of time. Usually you implement a mechanism based on two tokens, access_token with an expiration of 1h (usually) and a refresh_token with a longer expiration (usually 24h). The second one is used to renew the first one. When the second one expires, the user has to be considered logged out.
What you need is to implement a refresh token mechanism. You can implement it from scratch, for learning purposes, or you could just implement OAuth 2.0 protocol, since it's a flow that it already supports. There are lots of libraries both for server side and client side implementations
https://oauth.net/
Isn't it effective to never let the JWT expire so that user automatically logs in? Is there a security problem with it?
I don't want to use session and or cookie. They are ineffective.
IMO, it is effective in case the token gets stolen. If you have an infinite expiration time, the intruder has access to the protected resource for the lifetime. Think of it this as your password for personal mail. It is often a good idea to change it periodically so that if someone has obtained your password without your knowledge, he won't be able to access your email again after that.
Having said that, it is not compulsory to have the expiration time.
according to this
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. Implementers MAY provide for some small leeway, usually no more than
a few minutes, to account for clock skew. Its value MUST be a number
containing a NumericDate value. Use of this claim is OPTIONAL.
If I've authenticated a REST client and generated a token for them with an expiration date of 2 hours, is it bad practice to keep updating the expiration date every time the make a call (e.g. if they make a call in 1 hour, then the expiration date would move to be 1 hour later than when it was created)?
Or is it best practice to keep the expiration date and just force a re-authentication and then generate a totall new token?
In my experience, the easiest way to implement this is letting the server to auto-refresh the token. You can use an internal policy to check the number of seconds/minutes/hours/days that have occurred from the expiration date to now. If the token's expiration date is less or equal than a number of seconds/minutes/hours/days defined, then the server will generate a new token (and will return it to the client). This is transparent to the client and avoid to re-authenticate and ask for the user's credentials again. However, if the expiration date is greater than the number of seconds/minutes/hours/days defined, then you force the re-authentication.
Other workarounds may work as well but this implementation works for me. Hope this helps you!
I'm in the process of rolling my own JWT token auth, however, I would really like it to be a one time-token – so once it's used, the server generates a new token and the client will have to use that token during the next request/call.
However, it has come to my understanding that JWT is supposed to be 'stateless' – but with the approach of a one time token, I guess I would need to somehow store the valid tokens, since the token will be refreshed once it's used. Or is there any way to avoid storing a value on the server, and still be able to create one-time tokens?
The two main reasons for why I don't want to store any value is first of all scalability (sure, I could have cache-server inbetween to store the values, but it would be nice if that wasn't required), secondly, JWT is supposed to be stateless from my understanding, which it wouldn't be if I need to store a value on the server to be able to validate the token.
Any ideas?
Use the user's current password's hash for signing the JWT token, in this way all tokens generated before a successful password change would get invalidated the next time. I got the idea from here https://www.jbspeakr.cc/howto-single-use-jwt/.
Solutions exist, of course.
As with any distributed system (you mentioned scalability) you have to choose between availability and consistence.
You choose availability. In this case you could maintain a list of already-used tokens that you replicate in a eventually consistent manner between all the endpoints. For example when a token is used the respective endpoint send that token to the other endpoints in the backgound. There is however a (short) time frame when that token can be used a second time by another endpoint until that endpoint is updated.
You choose consistency (you won't allow a token to be used multiple times whatsoever). In this case you use a central database with already-used tokens and you check that database everytime you need to perform an action. Scalability? You could use sharding on the token and have n databases, each one being responsible for a tokens subset.
It depends on your business what solution fits best.
Not really no, a JWT token is valid if it hasn't expired and the signature is correct, commonly people will keep a DB of blacklisted tokens which are usually ones where people have logged out etc.
The only sensible way I can think of is give them a short expiry time and maintain a list of tokens that have already been used, you'd then periodically remove the ones that subsequently expire from the DB.
There are actually some DB's that have a TTL on records (dynamoDB, mongodb) so you'd just put the tokens in and set a TTL for when the token expires.
Update 2022
Just to be clear JWT tokens AREN'T stateless they have claims that, as long as they're signed by the right private key - give you a stateful piece of data that can be reissued by your API to reflect the current state of the user.
You'd just need to handle token re-issue on the consumer.
Like others have mentioned, it depends on your business case. Password resets links can be like mentioned on https://www.jbspeakr.cc/howto-single-use-jwt/.
If you have the Single-Use & Single-Auth scenario, where you might want to invalidate any previously used and unused token, you can store a single nonce and update it on every new token request and also when its used.
If the cookie is between 0 and x minutes away from expiration, I would like to refresh the expires value of that cookie to some set value (if the cookie is already expired, I do not want to refresh it).
How would I accomplish this with CGI::Cookie and CGI.pm?
Cookies sent by the browser do not expose their expiration time; they are either sent or they aren't. To know when it is going to expire, you have to store the expiration time in the cookie value in some parseable form.
If the cookie has been set, then it will be sent to the server. If it has expired, then it won't be.
Just test to see if the cookie exists, and refresh it if it exists.