I am building a system for a product which requires authentication and authorization. Naturally I have chosen using OAuth 2.0 as it is a commonly used protocol and has proven to be useful.

I am considering implementing tokens without storage - as described here: http://bshaffer.github.io/oauth2-server-php-docs/overview/crypto-tokens/

This would save me a lot of trouble with token storage, and of course means I have to go to the DB only for the initial login (when I issue the token).

Since I am not seeing this in common use - Are there any substantial cons to this approach? Is this a big security compromise?

I understand that I won't have some functionality (like logout deleting the token), but I feel this will have very big benefits when it comes to scaling the application.

2 Answers 2


The use of encrypted OAuth tokens is good approach to satisfying the security requirements in RFC-6749 section 10. Encrypted OAuth tokens are in common use, Facebook is a good example.

OAuth tokens expire based on the expires_in parameter. Which means that a given token would be valid for a short time after the user logs out, which is very low risk issue that majority of applications ignore. Once the user logs out, session riding attacks like XSS and CSRF should not be possible even if the OAuth token is still valid.


Auth tokens only really seem to make sense to me when their lifespan is kept short. As far as I can tell, this scheme does not alter the fact that an intercepted token can be replayed which would seem to be the problem with all simple token-based approaches? (or maybe it is just late and I've not read it properly :)

Certainly, I'd want to make sure that each client had an independent token so that risks were limited to individual clients.

To help reduce the exposure of the tokens, I would make the client app delete the token on expiry if possible & keep the lifespan short.

My own experiments with token based authentication have led me to realise that tokens should be validated against the client origin (e.g. at least IP address) periodically to try and prevent interception & replay. You could keep that information in the token (since it is encrypted - obviously don't try that with non-encrypted tokens) but the problem can be that the tokens get rather large which can be quite an overhead on communications.

At the end of the day, you will have to make some decisions based on the risks you are prepared to take. Personally, for reasonably secure systems, I think that I would rather use a high-performance, low-overhead NoSQL data store for most cases.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .