[mmcnickle]

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]

Yes 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

[mmcnickle]

Yes, 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/...