3 ms·
This is a good approach for a lot of things. It's the approach Flask uses for its session data by default. I wouldn't recommend it for authentication in large d
by mmcnickle 13y ago
This is a good approach for a lot of things. It's the approach Flask uses for its session data by default. I wouldn't recommend it for authentication in large deployments though.
One thing that it doesn't allow for is revocation of individual tokens. Invalidating auth tokens centrally is a very useful capability to have.
- sehrope 13y agoYes that's the biggest downfall and also where having a centralized persistent store wins out. The best compromise between the two I've thought of is to have a centralized store that lists revoked tokens. Presumably there wouldn't be that many so storing the recovations alone would be more efficient. Bonus points if you add a Bloom Filter[1] in front of the revocation lookup. In the end it's all about the use case you're solving. If the token's themselves already have a short expiration (ex: password reset token with 5 minutes to live) then revocation isn't really an issue. For something long lived and dangerous (ex: remember me token to log into my bank account) it's much more important. [1]: http://en.wikipedia.org/wiki/Bloom_filter http://en.wikipedia.org/wiki/Bloom_filter
- mmcnickle 13y agoYes, a password reset token is a good example where it would be fine to used a HMACed token, and is exactly how Django handles password resets [1]. [1] https://github.com/django/django/blob/master/django/contrib/auth/tokens.py#L45 https://github.com/django/django/blob/master/django/contrib/...