I'm running a service with ~300 write-authenticated access tokens. It's terrifying.

As part of running such a service, I'd like to be able to cycle API tokens - so that if, heaven forbid, one made an escape attempt and wasn't caught, it'd only be valid for a minimal period of time.

/access-tokens/{accessTokens}/invalidate disables a token completely with no replacement. If it's triggered accidentally, or too hastily, I'm stuck asking 300+ users to go reauth. That's bad UX.

It'd be great to have a method to reset a token, not invalidate it. This way, a service could periodically (every week? day? hour?) get 'new' tokens while invalidating old tokens. It could also be manually triggered if a non-compromising breach is suspected, or if someone's just outright paranoid.

For example, when creating data dumps, I'm super careful. Still, I'm a dog. It'd be great to be able to create the dump, triple-check it, reset all access tokens, then publish it. That way, there's no way to leak valid access tokens.

tl;dr: While I try my best to protect tokens at rest, I know I'm human. It'd be great to have another layer of protection against PEBKAC issues.


You must log in to answer this question.