4 ms·

Add 'issuing date' to the token, revoke all before a given issue date by a single date field in your auth table. Effectively clears all tokens. Would that work,

Add 'issuing date' to the token, revoke all before a given issue date by a single date field in your auth table. Effectively clears all tokens. Would that work, if done up front?

ceejayoz 7y ago
Every time you have to revoke a user's access, the entire organization has to log in again?
- Fellshard 7y ago
  Per user field.
  - ceejayoz 7y ago
    You've given up the benefits of a stateless token if you're looking in the database to check it's state all the time.
    - Fellshard 7y ago
      That is always the key point it comes back to. Thanks.
robmccoll 7y ago
Optimization if revocation isn't common: - Keep a last revocation time somewhere that is cheap to frequently poll (Redis) or broadcast it to all your nodes - Keep a revocation table - Use iat and exp with your JWTs - On revocation update the table and the last revocation time. - On validation, only check the revocation table if iat < last revocation time. If you have to check the table, reissue the JWT with the same claims and exp but updated iat.
jrockway 7y ago
You have to check this date on every request. I think, on some level, you can make a revocation database scale better than a validity database. You store the revocation in some durable datastore. Then you have some service in front of this that calculates the entire set of revoked tokens, and pushes that to each auth gateway. Then the auth gateway can check if a token is revoked without putting any load on a database. It has to do this for every request, but you can scale the auth gateway horizontally rather easily. (When an auth gateway starts, it gets a copy of the full revocation table again.) On some level, you do need the ability to push revocations to your auth server, because when you hit the kill switch on a session, you really want it to close all their open TCP connections (HTTP/2, Websockets, SSH, etc.) Having said that, starting simple is the best approach. I used MySQL to store sessions at my last job. Every request went from Envoy -> ext_authz -> authentication/authorization service -> MySQL and this whole flow added only 1-3ms of latency per request. Someday you will hit scaling limits of using MySQL for this, but it's a long way in the future. Do the simple and reliable thing first, then make it complicated later.
- abathur 7y ago
  I'm bearish on JWTs in many cases for reasons enumerated here and elsewhere. But I do use them in one place with a revocation scheme similar to this. On init, instances build an in-memory bitwise blacklist that token IDs are checked against. This arrangement probably already implies this, but just in case: this is at a very small scale where the complexity of pushing revocations isn't justifiable, power granted to the token-holder is limited and easy to clean up if misused, and revocations are so rare that restarting instances to update the blacklists is tolerable).
- DenisM 7y ago
  > 1-3ms of latency per request. Is that a big problem in practice? I always wonder about the tangible benefits of this approach.
  - jrockway 7y ago
    Yeah, I am quite OK with these numbers. The sessions-in-a-database-table is fast, simple, and accurate.

Add 'issuing date' to the token, revoke all before a given issue date by a single date field in your auth table. Effectively clears all tokens. Would that work, if done up front?

ceejayoz 7y ago

Every time you have to revoke a user's access, the entire organization has to log in again?

Fellshard 7y ago
Per user field.
- ceejayoz 7y ago
  You've given up the benefits of a stateless token if you're looking in the database to check it's state all the time.
  - Fellshard 7y ago
    That is always the key point it comes back to. Thanks.

robmccoll 7y ago

Optimization if revocation isn't common: - Keep a last revocation time somewhere that is cheap to frequently poll (Redis) or broadcast it to all your nodes - Keep a revocation table - Use iat and exp with your JWTs - On revocation update the table and the last revocation time. - On validation, only check the revocation table if iat < last revocation time. If you have to check the table, reissue the JWT with the same claims and exp but updated iat.

jrockway 7y ago

You have to check this date on every request. I think, on some level, you can make a revocation database scale better than a validity database. You store the revocation in some durable datastore. Then you have some service in front of this that calculates the entire set of revoked tokens, and pushes that to each auth gateway. Then the auth gateway can check if a token is revoked without putting any load on a database. It has to do this for every request, but you can scale the auth gateway horizontally rather easily. (When an auth gateway starts, it gets a copy of the full revocation table again.) On some level, you do need the ability to push revocations to your auth server, because when you hit the kill switch on a session, you really want it to close all their open TCP connections (HTTP/2, Websockets, SSH, etc.) Having said that, starting simple is the best approach. I used MySQL to store sessions at my last job. Every request went from Envoy -> ext_authz -> authentication/authorization service -> MySQL and this whole flow added only 1-3ms of latency per request. Someday you will hit scaling limits of using MySQL for this, but it's a long way in the future. Do the simple and reliable thing first, then make it complicated later.

abathur 7y ago
I'm bearish on JWTs in many cases for reasons enumerated here and elsewhere. But I do use them in one place with a revocation scheme similar to this. On init, instances build an in-memory bitwise blacklist that token IDs are checked against. This arrangement probably already implies this, but just in case: this is at a very small scale where the complexity of pushing revocations isn't justifiable, power granted to the token-holder is limited and easy to clean up if misused, and revocations are so rare that restarting instances to update the blacklists is tolerable).
DenisM 7y ago
> 1-3ms of latency per request. Is that a big problem in practice? I always wonder about the tangible benefits of this approach.
- jrockway 7y ago
  Yeah, I am quite OK with these numbers. The sessions-in-a-database-table is fast, simple, and accurate.