Why is no_expiry "strongly advised against"?

Question

In the docs on user auth, it says

This request is responded to with either an error (HTTP status code 400) or an access token of the form access_token=...&expires=1234. expires will only be set if scope does not include no_expiry, the use of which is strongly advised against unless your app truly needs perpetual access.

^{Emphasis mine.}

With expiration turned off you could request write access once and then keep it for later uses, instead of asking every time it expires. It would make applications much simpler, and the user could revoke permissions anytime.

So why do the docs say that no_expiry shouldn't be used unless required?

Answer 1

It is a security best practice. Tokens should be short-lived. They should be so short-lived that once captured the damage caused/cost to restore by a compromised token should be minimal. This means that based on the specific context short-lived might be minutes, sometimes hours.

For no_expiry tokens this becomes irrelevant. The token, once obtained, remains valid. The attacker can now do whatever they want, for as long as they want, only to be stopped when the owner notices that the token must have been leaked and revoke the access.

It is true that having to re-issue tokens is more complexity on the implementation end of things, but in the end you're protecting your users from potential mishaps they might not even be aware of.

If you have the means to keep the access_token private / on-premises and can guarantee it will not leak, ever and the usage of the token is only for your personal use, by all means, ask for a no_expiry access_token. If you build an app or userscript that you intend to make public and have other users use it, for the protection of their data, stick with short-lived tokens and handle expired tokens in your app or script.