> Anyone with access to the secret token can now generate their own urls without fail or evidence. With a DB you need to at least insert a row and thus leave ev

> Anyone with access to the secret token can now generate their own urls without fail or evidence. With a DB you need to at least insert a row and thus leave evidence (especially if you are auditing db activity) And they wouldn't be valid. It's much simpler to invalidate them provided that you don't need information from the DB, than reading from the DB. > No way to individually invalidate anyone. Example: What if ONE account's db tokens were exposed. Should be able to invalidate those tokens, not ALL tokens. Of course you design it in such a way, that you can change one of the inputs, which will by definition invalidate the tokens. > Not necessarily easier than one "expiring token" mechanism that is re-used throughout the system. The point is to seperate this boilerplate logic from your core business logic. > I don't feel great about exposing all my private security checks in url parameters. Why give users clues on how I do security? I can provide that in a better, more meaningful way. Any serious security systems assume that an attacker already know 100% of the workings of the system. You should not rely on obscurity, but on your secret - in this case the crypto key. > No way to easily invalidate all tokens of specific nature. Again, if this is a requirement, then make such a global parameter an input to the token generation. It's still much simpler than doing it "the old fashioned way".