don't people use JWT because they don't want to have some external dependency like a database. i'm not sure what using JWT + storing authentication state in a database gives you. couldn't it just be easier to store the authentication state in the database and give the user a 128 bit random token pointing to the state. if you are worried about someone compromising the DB you can also key the lookup by cryptographic hash instead of the storing the plaintext token.
To echo the other response, we use jwt and only periodically check the DB. We "soft expire" and renew the tokens every 15 minutes. Which means that a user could conceivably work for 15 minutes without hitting the auth tables at all. After that 15, we don't require that their token be replaced, but a "soft expired" token will require checking the DB on each call.
Then of course a hard expire from the DB (as in, it no longer exists) will cause an auth rejection.
But the best part is having a few bits of key data like user id stored in the key that can be trusted without calling the database.
We use JWT because the user data is already stored upront (w/out needing to check a database) and it’s a well defined storage mechanism. With Vault we check only the token ID not the full token, so it’s not a heavyweight select. On the other hand we have 3d party (used internally) systems using the same mechanism (e.g. Drone).
But then you have to handle expiration and revocation synchronously. Is the extra network + cpu to unmarshall a token that much of a savings over 1 redis call on the server for the user details?
Which storage backend are you using for Vault? With MySql you could use scheduled events (no need to run/manage your own process), a created_at column in the Vault table and a scheduled check for created_at+ttl and have the DB to remove the tokens once the lease is expired. Also, if you were to use an etcd backend you could configure it to have it removed once the lease is expired. The only drawback is that the tokens TTL's are global and you can't set per user.
don't people use JWT because they don't want to have some external dependency like a database. i'm not sure what using JWT + storing authentication state in a database gives you. couldn't it just be easier to store the authentication state in the database and give the user a 128 bit random token pointing to the state. if you are worried about someone compromising the DB you can also key the lookup by cryptographic hash instead of the storing the plaintext token.
To echo the other response, we use jwt and only periodically check the DB. We "soft expire" and renew the tokens every 15 minutes. Which means that a user could conceivably work for 15 minutes without hitting the auth tables at all. After that 15, we don't require that their token be replaced, but a "soft expired" token will require checking the DB on each call.
Then of course a hard expire from the DB (as in, it no longer exists) will cause an auth rejection.
But the best part is having a few bits of key data like user id stored in the key that can be trusted without calling the database.
We use JWT because the user data is already stored upront (w/out needing to check a database) and it’s a well defined storage mechanism. With Vault we check only the token ID not the full token, so it’s not a heavyweight select. On the other hand we have 3d party (used internally) systems using the same mechanism (e.g. Drone).
But then you have to handle expiration and revocation synchronously. Is the extra network + cpu to unmarshall a token that much of a savings over 1 redis call on the server for the user details?
The Helm chart with role binding and service account support to deploy Vault is open sourced as well.
We do something very similar, tho we don't use JWT, just a token, and store the userID in the KV store.
How do you handle cleaning up the vault KV store? We have a separate process that runs around cleaning up old tokens, but am open to a better way.
Vault does the expiration/cleaning up for you.
You are mistaken: "Even will a ttl set, the secrets engine never removes data on its own. The ttl key is merely advisory." - https://www.vaultproject.io/docs/secrets/kv/index.html
Which storage backend are you using for Vault? With MySql you could use scheduled events (no need to run/manage your own process), a created_at column in the Vault table and a scheduled check for created_at+ttl and have the DB to remove the tokens once the lease is expired. Also, if you were to use an etcd backend you could configure it to have it removed once the lease is expired. The only drawback is that the tokens TTL's are global and you can't set per user.
Consul. But good to know about these backends!
Yeah, for us etcd is OK as we are running on Kubernetes.
Interesting, but you could just rely on short expiry with refresh as well.
Nice! I'm looking at doing something similar