Dealing with token revocation.

[scolby33]

When acquiring an authentication token, it is issued with a short expiration time. I intend to implement a method to obtain longer-lasting credentials (several months or a year?) for use in dumb automated systems (IFTTT, in particular) that can't deal with authenticating or renewing tokens. This raises the question of what to do with long-lasting tokens (or any tokens) that escape and need to be revoked.

The token implementation we're using (JWT) does not require storing state on the server--all the required authentication information is stored in the token and cryptographically signed. That means when a token is revoked based on its unique identifier, the server has no way to know how long the validity period of the revoked token is. This would require storing the token revocation state indefinitely, which seems wrong to me.

Perhaps we place an upper limit on the length of time that a token can be valid for (a year?) and store revocation information for one year from the revocation date? Comments are welcome.

[cthoyt]

you definitely aren't the first person to think about this (unrelated, I've never thought about this)

there must be a better way to deal with revocation states - maybe the token can store that information itself? Or am I misunderstanding?

[scolby33]

The server issues a bearer token. That is, whoever has that sequence of bits gets the access. Once the token is issued, the server can forget about it, because it can verify that it's real at any time by checking the signature on the token.

If you revoke the token because a bad guy has got his hands on it, you can't do anything to his copy of the token. This revocation process is basically telling the server cops to not let this guy in, no matter what he says.

[cthoyt]

I think the solution is to build a wall