5 ms·

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

tracker1 7y ago
Usually in one of those scenarios, you will try to hold, say a fired employee for that long in order to deactivate all their accounts and access anyway... in reality it's not much of an increased risk... You still could blacklist, but realistically most areas don't need a dedicated revocation check. Some critical areas might, depending on the space.
bearjaws 7y ago
Meanwhile on sales call with Microsoft: "Authentication takes a few minutes to replicate throughout our systems so a SLO request should be resolved within a few minutes". Stakeholder: Ok sounds good
- tracker1 7y ago
  +1 on this... it can be up to a 30 minute lag in some orgs... oh, you have access to those systems for a while until things sync up... similar for LDAP/AD sync with Nix/windows.
  - to11mtm 7y ago
    Which makes sense when I think about how some of the more trigger happy orgs made a point of shutting peoples accounts of as they were being walked into a room...
spookthesunset 7y ago
For parts of the site where you need to boot somebody instantly... just hit up the authentication server on every request to validate the session. For parts of the site where it doesn’t matter so much, wait for the token to expire.... It isn’t all or nothing.
- mwilliaams 7y ago
  I did exactly this on the last implementation of JWT I did. Common actions wouldn’t hit the database if the token was less than an hour old, but actions like changing email address or password would always check the database.
  - user5994461 7y ago
    This just made me realize. There is an even simpler way to achieve the same result without a database. The token includes the time when it was created (iat attribute) so critical actions could check that the token is less than 3 minutes old.
    - mwilliaams 7y ago
      Yeah that’s what I did, with iat info. But I did that for every request, and critical actions always hit the db.
throwaway3157 7y ago
I actually have this conversation a lot, and the answer is usually "okay" and rarely "nope". Stakeholders have to weigh many more pros and cons.
- ubu7737 7y ago
  This is just a terrible security hole and I really think all stakeholders should reconsider it. If you give every attacker a 3-15 minute window of opportunity, and you ship tokens to anonymous users, you are playing with fire.
toyg 7y ago
Authentication and authorization are different things, if the latter is done properly a bit of waiting for the former is no biggie.
schnable 7y ago
This tradeoff comes up all the time on highly scaled systems, and stakeholders rarely if ever say "nope" in my experience.

tracker1 7y ago

Usually in one of those scenarios, you will try to hold, say a fired employee for that long in order to deactivate all their accounts and access anyway... in reality it's not much of an increased risk... You still could blacklist, but realistically most areas don't need a dedicated revocation check. Some critical areas might, depending on the space.

bearjaws 7y ago

Meanwhile on sales call with Microsoft: "Authentication takes a few minutes to replicate throughout our systems so a SLO request should be resolved within a few minutes". Stakeholder: Ok sounds good

tracker1 7y ago
+1 on this... it can be up to a 30 minute lag in some orgs... oh, you have access to those systems for a while until things sync up... similar for LDAP/AD sync with Nix/windows.
- to11mtm 7y ago
  Which makes sense when I think about how some of the more trigger happy orgs made a point of shutting peoples accounts of as they were being walked into a room...

spookthesunset 7y ago

For parts of the site where you need to boot somebody instantly... just hit up the authentication server on every request to validate the session. For parts of the site where it doesn’t matter so much, wait for the token to expire.... It isn’t all or nothing.

mwilliaams 7y ago
I did exactly this on the last implementation of JWT I did. Common actions wouldn’t hit the database if the token was less than an hour old, but actions like changing email address or password would always check the database.
- user5994461 7y ago
  This just made me realize. There is an even simpler way to achieve the same result without a database. The token includes the time when it was created (iat attribute) so critical actions could check that the token is less than 3 minutes old.
  - mwilliaams 7y ago
    Yeah that’s what I did, with iat info. But I did that for every request, and critical actions always hit the db.

throwaway3157 7y ago

I actually have this conversation a lot, and the answer is usually "okay" and rarely "nope". Stakeholders have to weigh many more pros and cons.

ubu7737 7y ago
This is just a terrible security hole and I really think all stakeholders should reconsider it. If you give every attacker a 3-15 minute window of opportunity, and you ship tokens to anonymous users, you are playing with fire.

toyg 7y ago

Authentication and authorization are different things, if the latter is done properly a bit of waiting for the former is no biggie.

schnable 7y ago

This tradeoff comes up all the time on highly scaled systems, and stakeholders rarely if ever say "nope" in my experience.