The shorter tokes are useless by themselves; but if combined with proactive security, they can make a real difference. Some concrete examples, based on the plac

The shorter tokes are useless by themselves; but if combined with proactive security, they can make a real difference. Some concrete examples, based on the places I worked in, which provide support for at least not having infinite expiration: - Attacker steals Google token from regular employee.. What can they do? No, they can't "make themselves admin, or wire all your bitcoin to their account" because such things are not available for regular employees. Nor can they use email to take over account because all stuff that matters uses corporate SSO without automated password resets. So all they have access to corporate google drive, which has few terabytes of not so-valuable-stuff + important documents somewhere. With long-living token, the attacker has plenty of time to browse around and download valuable stuff, perhaps even do it slowly so it can fly under radar. But with the shorter token, this does not work: downloading everything will take too much time / trip the alarms, and manual browsing is not fast enough. (I can imagine some sort of sophisticated AI system which auto-downloads interesting docs, but I am sure most attackers have nothing like this) - Attacker steals AWS credentials -- again, they either have to be fast and get detected (there are alarms on unusual high download rate) or go slow and worry about token expiration. Even if they manage to steal important data, at least the expiration will force them to use faster methods more likely to trip the alarm. Even with the full machine compromise, the short-lived tokens are useful. A npm package which steals all tokens once, at the install time, will likely go undetected. A npm package which installs a persistent backdoor will be much easier to detect.. So having a long-lived token makes attackers' lives much easier.