6 ms·

I would add two pros of jwts (I guess oauth 2 and oidc more specifically) 1. It standardizes your auth system. While sessions auth is mostly implemented in the

by bebop 2y ago

I would add two pros of jwts (I guess oauth 2 and oidc more specifically) 1. It standardizes your auth system. While sessions auth is mostly implemented in the same way across systems, learning oauth and oidc gives you a standard across the industry. 2. Jwts give an easy path to make “front end” applications and api authentication work in the same way. This in theory reduces your security surface area as all of your authnz code can be shared across your offerings.

andoando 2y ago
3. Easy to implement. 4. Dont need to hit db. 5. Can store some information with the claim which is very convenient
- pests 2y ago
  How do you revoke tokens if a one gets leaked without hitting a db? How long are your users vulnerable to attack?
  - moomoo11 2y ago
    Use low TTL and put rate limits and other mechanisms in place?
    - jjice 2y ago
      I think you're right, but it seems like you get into a tricky territory that'll never be great (as everything with security has compromised). Too long is an issue for attacks, but convenient for users. Too short and you have to do an initial re-auth over and over again, partially defeating the benefits. Even if the TTL is short, there are plenty of ways to compromise a token and use it immediately in an automated system. If you're using JWTs, I'd lean shorter TTLs and embrace this as a potential concern. Not sure what the best re-auth frequency is though. I'd be really interested to see other's thoughts on that.
      - moomoo11 2y ago
        But the token is used over SSL and the only way to get it afaik is to hijack the client device or somehow hijack the server. The first scenario is pretty rare and the second is pretty easy to avoid. I don’t think that’s really an edge case that’s concerning for 99% of applications.
        pests 2y ago
        > the only way to get it afaik is to hijack the client device or somehow hijack the server. Yet we have millions of passwords in dumps across the internet. Maybe hijacking the client or server is more common than thought?
        moomoo11 2y ago
        I think you're conflating a few things. Passwords being leaked is due to noobs and idiots in charge of systems, and probably not using an actual auth provider. It really isn't that hard. 1. Send secure information over SSL. If some noob-tier dev decides that's too advanced for them, congrats I guess for being stupid. 2. Store passwords with hashing and salting. If you use an auth provider, like auth0 or firebase even, they will do this for you because they're not noobs. A noob-tier dev who stores plaintext passwords in a database with insecure connection and postgres:postgres is again stupid af. Most of those leaked passwords are because of this. And don't think some Fortune 500 is not stupid. They outsource their development to Accenture or Detoilette, or any of the other outsourcers where they pay some "Software Architect" $8/hr to secure banking information (while charging the client $150/hr). I'm not throwing shade, but these companies are cheap af and throw bodies at the problem instead of experience and brains. I have direct experience with this, so I know how bad it is. Don't confuse people being stupid (very common, 90% of any population) with a failure in a technology that others who don't understand it claim makes it inferior or something. The internet and all the technology you use today is glued together by the <10% of people who actually understand computers, networking, and problem solving. Just because a noob-dev uses session tokens doesn't mean it will be any secure if they fail those 2 points I mentioned. Those are so deadass simple to mitigate, anyone who purposefully skips on them should be named and shamed, and receive a 10 year cooldown from being a software developer.
  - bebop 2y ago
    Yes, this is the trade off. If you are working in an industry where you need to be highly sensitive for data access even for short periods of times then oauth/oidc/jwts are probably not for you. If you really need an emergency escape hatch you can always rotate your singing keys and jwks and invalidate all of your tokens and force everyone to sign back in.
  - andoando 2y ago
    Good point. If a short session time isnt good enough, you can use a simple key store to check for revoked tokens. Youll be hitting a db but its somewhat better since its just a very small db of revoked tokens. Its hard for me to imagine though with like a 30 min or even few hour long token, under what circumstances you'd actually revoke tokens. If your db got leaked, you can rotate the key and invalidate all tokens. Otherwise, itd have to be something like you have some post login fraud detection in place. Cause jwt or not, if a user just signed in and a hacker got their auth token, what are you going to do? Sure you need to check the db to revoke it, but the problem is how would you know the tokens been compromised?
    - deleted 2y ago
      [deleted]
    - mrkeen 2y ago
      > If a short session time isnt good enough, you can use a simple key store to check for revoked tokens. It's not bad solution per se, but it does negate JWT's main value proposition, which is to not need such a store.
  - xorcist 2y ago
    Another way to put it: "Do you want a (functional) logout button?"
    - tasuki 2y ago
      That's not another way to put it. You can have a logout button which makes the client forget the jwt token.
      - pan69 2y ago
        But if the jwt was leaked before the client forgot it, the jwt itself is still valid and can continued to be used by an attacker.
        stkdump 2y ago
        I wonder if an extension to the concept of jwt that extends the cryptographics chain down into some hardware component such as a TPM or secure enclave is the right answer. Basically the payload of the token could contain a pubkey for checking a signature on the request payload. The logout button would then have two local effects on the client side: delete the token and tell the hardware component to forget the private key.
      - xorcist 2y ago
        Well, hence (functional). Making the client forget a token sounds trivial. But there's a long tail of clients out there, and many cases where things might get more complicated. Maybe I'm damaged from working in a regulated industry, but a (possibly malicious) client who went through the logout process and could prove someone else reused the token after logout might have a case. Or another of a myriad of unknown possibilities. It's all very unnecessary. There's a reason we all used to invalidate trust server side. It's just so much easier to reason about.
    - sweetjuly 2y ago
      Why would you need to revoke on logout? Forgetting seems to be enough in all cases except maybe SSO revocation because in all other cases you can (and indeed often must) trust the client to protect the credential.
  - beeboobaa3 2y ago
    Store reset_time per user. Use a message queue (or postgres notify) to push changes to this value to your apps. Check the user's token was created after the reset_time when validating it. You would be required to keep a Map<UserId, Timestamp> in memory, potentially with TTL. Most systems can handle this easily for their expected user load. If not, you should have the engineering capacity to figure it out ;) Logout button sets reset_time to now, as does revoking tokens. This would only allow you to revoke all tokens for one user at the same time, but this tends to be fine, since JWTs should be short-lived anyway and apps should deal with the expectation of them being expired/revoked.
    - nosefrog 2y ago
      And hope your service hasn't been restarted so it doesn't lose the in-memory revocation list?
      - beeboobaa3 2y ago
        Just populate the cache when you need it? You will need a database round trip for the first request per user per application restart, if they haven't reset since. I assumed this was obvious.
        nosefrog 2y ago
        Oh, I didn't realize that the design also has a database of revocations. In that case, you can just query that directly :P
        beeboobaa3 2y ago
        You'll want to store your user credentials that they traded for a JWT somewhere. The point of using JWTs is that most of your requests don't have to hit this database.
  - zdragnar 2y ago
    You can use a separate DB that acts more like a cache for revocations- usually something where you can set a time to live on the row equal to the duration of the token itself. That keeps your application DB free for application load, while keeping your identity validation logic nice and snappy. Of course, adding infrastructure may be intimidating, but most applications that face any real load are going to be using redis or something similar anyway at some place in the stack.
    - akerl_ 2y ago
      If I have to run a separate DB to check for revocations, why not skip JWTs and just use that separate DB for auth directly.
      - andoando 2y ago
        Not an issue for most cases but a cache of revoked tokens is going to be much smaller than a db of all users tokens.
      - zdragnar 2y ago
        The advantage of redis or similar kv DBs / caches comes in being lighter and faster than a full second database, mostly. The secondary advantage is you don't need to deal with cookie storage, sticky sessions or anything else along those lines. If you're manually hand crafting a server, go for it. If you're treating them like cattle not pets, going stateless with a bearer token tends to be easier.
  - 4star3star 2y ago
    How do you find out a single token got leaked within the token lifetime? If it's that easy to detect a leaked token, why aren't you stopping the leak in the first place?
  - 015a 2y ago
    Then you can hit the db. I don't understand this argument against JWTs; if instantaneous session revocation is important for your use-case, versus JWTs more typical 5 minute or 60 minute expiration, there is nothing about JWTs which makes them poor candidates for going to the database as you would a session token. And, you get all the other benefits. One example where this can matter: I've seen JWTs used in defense-in-depth scenarios where you've got an API gateway that does the initial JWT validation, including a round-trip to the database to check for revocation, but then had microservices behind the gateway only check the signature. Traditional session keys would require a database roundtrip for every validation, which could number in the dozens for a single API request.
treve 2y ago
OAuth2 has no dependency on JWT, and _most_ authentication cases don't need OIDC, OAuth2 is enough.
tracker1 2y ago
I'd add that it's easier to abstract your software service from authentication. It's allowed me to write bridge signing from AzureAD, Okta etc, to a supported application deployed to differing environments on client hardware and readily integrating to different SSO systems.

by bebop 2y ago

andoando 2y ago

3. Easy to implement. 4. Dont need to hit db. 5. Can store some information with the claim which is very convenient

pests 2y ago
How do you revoke tokens if a one gets leaked without hitting a db? How long are your users vulnerable to attack?
- moomoo11 2y ago
  Use low TTL and put rate limits and other mechanisms in place?
  - jjice 2y ago
    I think you're right, but it seems like you get into a tricky territory that'll never be great (as everything with security has compromised). Too long is an issue for attacks, but convenient for users. Too short and you have to do an initial re-auth over and over again, partially defeating the benefits. Even if the TTL is short, there are plenty of ways to compromise a token and use it immediately in an automated system. If you're using JWTs, I'd lean shorter TTLs and embrace this as a potential concern. Not sure what the best re-auth frequency is though. I'd be really interested to see other's thoughts on that.
    - moomoo11 2y ago
      But the token is used over SSL and the only way to get it afaik is to hijack the client device or somehow hijack the server. The first scenario is pretty rare and the second is pretty easy to avoid. I don’t think that’s really an edge case that’s concerning for 99% of applications.
      - pests 2y ago
        > the only way to get it afaik is to hijack the client device or somehow hijack the server. Yet we have millions of passwords in dumps across the internet. Maybe hijacking the client or server is more common than thought?
        moomoo11 2y ago
        I think you're conflating a few things. Passwords being leaked is due to noobs and idiots in charge of systems, and probably not using an actual auth provider. It really isn't that hard. 1. Send secure information over SSL. If some noob-tier dev decides that's too advanced for them, congrats I guess for being stupid. 2. Store passwords with hashing and salting. If you use an auth provider, like auth0 or firebase even, they will do this for you because they're not noobs. A noob-tier dev who stores plaintext passwords in a database with insecure connection and postgres:postgres is again stupid af. Most of those leaked passwords are because of this. And don't think some Fortune 500 is not stupid. They outsource their development to Accenture or Detoilette, or any of the other outsourcers where they pay some "Software Architect" $8/hr to secure banking information (while charging the client $150/hr). I'm not throwing shade, but these companies are cheap af and throw bodies at the problem instead of experience and brains. I have direct experience with this, so I know how bad it is. Don't confuse people being stupid (very common, 90% of any population) with a failure in a technology that others who don't understand it claim makes it inferior or something. The internet and all the technology you use today is glued together by the <10% of people who actually understand computers, networking, and problem solving. Just because a noob-dev uses session tokens doesn't mean it will be any secure if they fail those 2 points I mentioned. Those are so deadass simple to mitigate, anyone who purposefully skips on them should be named and shamed, and receive a 10 year cooldown from being a software developer.
- bebop 2y ago
  Yes, this is the trade off. If you are working in an industry where you need to be highly sensitive for data access even for short periods of times then oauth/oidc/jwts are probably not for you. If you really need an emergency escape hatch you can always rotate your singing keys and jwks and invalidate all of your tokens and force everyone to sign back in.
- andoando 2y ago
  Good point. If a short session time isnt good enough, you can use a simple key store to check for revoked tokens. Youll be hitting a db but its somewhat better since its just a very small db of revoked tokens. Its hard for me to imagine though with like a 30 min or even few hour long token, under what circumstances you'd actually revoke tokens. If your db got leaked, you can rotate the key and invalidate all tokens. Otherwise, itd have to be something like you have some post login fraud detection in place. Cause jwt or not, if a user just signed in and a hacker got their auth token, what are you going to do? Sure you need to check the db to revoke it, but the problem is how would you know the tokens been compromised?
  - deleted 2y ago
    [deleted]
  - mrkeen 2y ago
    > If a short session time isnt good enough, you can use a simple key store to check for revoked tokens. It's not bad solution per se, but it does negate JWT's main value proposition, which is to not need such a store.
- xorcist 2y ago
  Another way to put it: "Do you want a (functional) logout button?"
  - tasuki 2y ago
    That's not another way to put it. You can have a logout button which makes the client forget the jwt token.
    - pan69 2y ago
      But if the jwt was leaked before the client forgot it, the jwt itself is still valid and can continued to be used by an attacker.
      - stkdump 2y ago
        I wonder if an extension to the concept of jwt that extends the cryptographics chain down into some hardware component such as a TPM or secure enclave is the right answer. Basically the payload of the token could contain a pubkey for checking a signature on the request payload. The logout button would then have two local effects on the client side: delete the token and tell the hardware component to forget the private key.
    - xorcist 2y ago
      Well, hence (functional). Making the client forget a token sounds trivial. But there's a long tail of clients out there, and many cases where things might get more complicated. Maybe I'm damaged from working in a regulated industry, but a (possibly malicious) client who went through the logout process and could prove someone else reused the token after logout might have a case. Or another of a myriad of unknown possibilities. It's all very unnecessary. There's a reason we all used to invalidate trust server side. It's just so much easier to reason about.
  - sweetjuly 2y ago
    Why would you need to revoke on logout? Forgetting seems to be enough in all cases except maybe SSO revocation because in all other cases you can (and indeed often must) trust the client to protect the credential.
- beeboobaa3 2y ago
  Store reset_time per user. Use a message queue (or postgres notify) to push changes to this value to your apps. Check the user's token was created after the reset_time when validating it. You would be required to keep a Map<UserId, Timestamp> in memory, potentially with TTL. Most systems can handle this easily for their expected user load. If not, you should have the engineering capacity to figure it out ;) Logout button sets reset_time to now, as does revoking tokens. This would only allow you to revoke all tokens for one user at the same time, but this tends to be fine, since JWTs should be short-lived anyway and apps should deal with the expectation of them being expired/revoked.
  - nosefrog 2y ago
    And hope your service hasn't been restarted so it doesn't lose the in-memory revocation list?
    - beeboobaa3 2y ago
      Just populate the cache when you need it? You will need a database round trip for the first request per user per application restart, if they haven't reset since. I assumed this was obvious.
      - nosefrog 2y ago
        Oh, I didn't realize that the design also has a database of revocations. In that case, you can just query that directly :P
        beeboobaa3 2y ago
        You'll want to store your user credentials that they traded for a JWT somewhere. The point of using JWTs is that most of your requests don't have to hit this database.
- zdragnar 2y ago
  You can use a separate DB that acts more like a cache for revocations- usually something where you can set a time to live on the row equal to the duration of the token itself. That keeps your application DB free for application load, while keeping your identity validation logic nice and snappy. Of course, adding infrastructure may be intimidating, but most applications that face any real load are going to be using redis or something similar anyway at some place in the stack.
  - akerl_ 2y ago
    If I have to run a separate DB to check for revocations, why not skip JWTs and just use that separate DB for auth directly.
    - andoando 2y ago
      Not an issue for most cases but a cache of revoked tokens is going to be much smaller than a db of all users tokens.
    - zdragnar 2y ago
      The advantage of redis or similar kv DBs / caches comes in being lighter and faster than a full second database, mostly. The secondary advantage is you don't need to deal with cookie storage, sticky sessions or anything else along those lines. If you're manually hand crafting a server, go for it. If you're treating them like cattle not pets, going stateless with a bearer token tends to be easier.
- 4star3star 2y ago
  How do you find out a single token got leaked within the token lifetime? If it's that easy to detect a leaked token, why aren't you stopping the leak in the first place?
- 015a 2y ago
  Then you can hit the db. I don't understand this argument against JWTs; if instantaneous session revocation is important for your use-case, versus JWTs more typical 5 minute or 60 minute expiration, there is nothing about JWTs which makes them poor candidates for going to the database as you would a session token. And, you get all the other benefits. One example where this can matter: I've seen JWTs used in defense-in-depth scenarios where you've got an API gateway that does the initial JWT validation, including a round-trip to the database to check for revocation, but then had microservices behind the gateway only check the signature. Traditional session keys would require a database roundtrip for every validation, which could number in the dozens for a single API request.

treve 2y ago

OAuth2 has no dependency on JWT, and _most_ authentication cases don't need OIDC, OAuth2 is enough.

tracker1 2y ago

I'd add that it's easier to abstract your software service from authentication. It's allowed me to write bridge signing from AzureAD, Okta etc, to a supported application deployed to differing environments on client hardware and readily integrating to different SSO systems.