[lightedman]

"Soon, that'll be ~7 days, so even less of a concern."

If you aren't authorizing and revoking immediately after delivering data, you're doing it wrong and opening yourself up to attack.

Source: Four penny auction websites using the same code were compromised by me (at their request - hired hacker.) I took their entire auction winnings after they gave me authorization to test their systems. It took me less than 20 minutes.

I walked away with $300,000 because in my contract I told them I keep whatever I compromise and steal. They agreed.

If you can't handle rapid token usage/generation, don't even bother using tokens. Token revocation is one of the harder things out there to get done properly. You're better off with a challenge/auth EVERY SINGLE REQUEST at the expense of page loading times.

[pfg]

Again, this isn't about tokens. We're talking about a private account key (like, an actual RSA or ECC key), which is associated with FQDNs for which the holder of an account key has the ability to issue certificates.

I'll try to phrase this as an example: Let's say you run an online store for music downloads. One implementation might be to send the user an email with a download link, identified by a token. In this case, it would make sense for this token to expire after the user successfully downloaded the file, and doing otherwise would probably be bad for your business. On the other hand, if your online store involves a login process you need to complete before you can actually download the file (the file being the domain authorization in this example), that's fine and you might not want to limit the user to one download.