| > Is there an argument for why non-expiring tokens are a bad idea that I'm missing here? it's a band-aid on other people not being able to secure their system. Band-aid that solves nothing as if token valid for a week or a month leaks you're still fucked. Now no expiry at all is a problem (you don't want someone digging out token from 2 years ago from somewhere to still work), but the node actively using service should be able to re-generate its own one. Then you could also get away by super-short tokens (say week) that app just re-generates every few days. For example app can use tokenN to generate tokenN+1 and have both of them be valid at the same time for a period (so app cluster have time to propagate the new access token before old one expires) And so any leak of old data would be no threat, you wouldn't need to have months-long human-regenerated tokens, and it would be more leak-proof as just having week old token would be inconsequential. Vs "bother someone every 6 months to click thru the stupid panel and put the key in right places just so your infrastructure keeps working". MS already does that in other places, it's aisine |
Which in order to do it would presumably need some meta-token you use to authenticate to get a token. how is that more secure? It sounds like I just need the meta-token instead of the token. So, same amount of security as just a non-expiring token