One of the benefits of tokens is that you can revoke them when compromised. With InfluxDB 1.8 OSS you don’t have administrative actions in InfluxDB to generate the token, but am I right that we can’t revoke it either? For example by add a username/exp combination to a no-fly list?
My only option seems to change the shared-secret and disable all tokens ever created for it. That’s pretty disruptive.
Hello @rvdheij,
Yes agreed that’s not the case with 3.x though. v3 OSS should land later this year, I recommend giving it a go when it does.
1 Like
At least you’re not yet pushing the date for v3 OSS out… 
Hi @Anaisdg Come see me stand in the corner wearing the donkey hat!
As we can’t revoke the JWT we should generate the token with a short enough expiration that you never need to (like shorter than your expected reaction time on compromised token). And the application using the token to write data should have the logic to request a new token when the old one expires.
I believe I should a tiny web server that can generate the tokens on request. It probably should identify the requester by IP address and use a whitelist to decide. If you have a consistent scheme to determine the InfluxDB username from the system hostname, you could even show users to see whether you’re supposed to give them a token. That tiny web server could run on the same Linux system where InfluxDB is running, so the shared secret does not have to be known outside.
