Add JWT Revocation

[clarkenciel]

Probably need to do some research around jwt revocation strategies.

[fakemonster]

At the end of the day, it seems like there aren't really any "true" revocation strategies other than persisting them somewhere and checking on every request (essentially using them as regular HTTP sessions). We could save storage by saving "revocations" instead of tokens, but we're still checking every time.

From there we can establish some sort of tradeoff by keeping JWTs short-lived, and using the same type of storage to say whether or not we would refresh the token automatically. Then if a token is "revoked," we just don't refresh. This isn't actually revocation, though; if a JWT is compromised it remains valid for its lifetime (hence needing to be short-lived). Essentially we can decrease querying, and in proportion increase time-to-revocation.

[clarkenciel]

this sounds like a good strategy to me since that we don't have any sensitive information stored in this application. 1-day lifetimes seem fair as a starting point, but we'd obviously want to put this kind of configuration in an environment variable or something (someday maybe we'll have an admin panel...). going with the strategy of short lifetimes makes it extra important that we make log-in as seamless as possible.

[clarkenciel]

I could see us going the route of an app like chase bank though. that app seems to have really short ttl for tokens (if i switch away for even a couple minutes i get logged out). the burden of logging back in is somewhat ameliorated by the app being native and leveraging my phone's finger print reader. if we decide that the risks of our longer ttl are too great we may want to drop the lifetime to a minute and just make log in super easy. in a native environment we may be able to leverage whatever background processing facilities are available and in a web environment we may want to look at web workers for this.