7 ms·

So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.

mjg59 5y ago
The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?
- xnorswap 5y ago
  I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?
  - mjg59 5y ago
    Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.
    - iso1631 5y ago
      That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.
      - mjg59 5y ago
        You're a 5-person startup. How do you verify that all of Github's token issuance policies align with your needs?
        iso1631 5y ago
        Don't. Run your own. It's a cost of business, you can either rely on the standard terms of your suppliers, or you can supply your own, it's far easier than the vast majority of industries. Git especially is a federated system that has no need for things like github.
        mjg59 5y ago
        Or we could invent better solutions where we didn't need to depend on policies imposed by vendors? The value that Github provides isn't around their git hosting, it's all the integrated features. Reimplementing that isn't going to be trivial - there's a reason so many people use hosted Git rather than doing it themselves.
    - xnorswap 5y ago
      So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials. A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone. If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.
      - mjg59 5y ago
        No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.
        xnorswap 5y ago
        But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.
        mjg59 5y ago
        I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.
- iso1631 5y ago
  So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk. I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk. [0] https://www.youtube.com/watch?v=y4GB_NDU43Q https://www.youtube.com/watch?v=y4GB_NDU43Q
  - mjg59 5y ago
    I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.
    - iso1631 5y ago
      Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.
michaelt 5y ago
This is a common problem in enterprise single-sign-on systems. The issue is: If the user presses the 'log out' button, you want it to take effect within a few seconds. But if logouts are simply a timestamped record expiring, they'd have to expire within seconds, and that would basically mean re-authenticating on every single request. And at the same time, some webapps have shitty re-authentication flows (like discarding any unsaved work-in-progress and kicking the user back to the homepage) and they're only usable with a re-authentication periods measured in days.
- jillesvangurp 5y ago
  It's tradeoff. If you require tokens to be invalidated instantly, there's no way around the notion of doing some kind of lookup when you are validating the tokens. It could be as simple as having a database/memory store somewhere with invalidated tokens or all the still valid tokens. You might cache those for a few seconds so the performance overhead would be pretty minor. You can make this as strict/complicated/slow as you need it to be. It's up to the validating party to decide just how strict they want to be. But mostly, the device simply deleting the tokens when the user clicks logout is good enough though. Logout does not protect against mitm attacks of course. But that's not what logout is about. And if you have attacks like that going on, the user clicking logout or not does not matter anyway because you can't trust anything they do since you can no longer tell them apart from whomever is attacking. All a logout signals is the user throwing away their tokens (and probably a lot of other local state). Which is why world + dog uses either tokens that never expire or tokens with expiration times that are pretty long. In our case we use access tokens and refresh tokens. The access tokens are refreshed regularly and the refresh tokens expire after a few months. So, the only users that we force through repeated login procedures are those that don't regularly use our app. Anything more would be annoying. And yes, if their devices get hacked, those users have would have an issue. That's the tradeoff. The user using a token they just threw away is not a real problem because they wouldn't. The user's tokens getting stolen is a different problem. That's why having the tokens expire eventually is a good thing. Long expiration times are not appropriate if you are a bank for obvious reasons. So, they tend to use expiration times measured in minutes typically and use additional authentication around sensitive transactions.
xnorswap 5y ago
A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash. So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer tokens from a single sign on to grant access to the API. That works great until Bob realizes that Eve has got access to his password and hits a password reset to force Eve out the system. But with bearer tokens, Eve still has access until those tokens expire. You could add a check for expiration against the calls, but then we're back to session keys being more straightforward because we're back to having some central information (has Bob's token expired) that needs propagation to the different services. You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again). I think bearer tokens work best for internal proxies / APIs to avoid hitting the data store, they aren't a great replacement for session keys.
- mormegil 5y ago
  Yeah, there is this classic: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
  - spacemanmatt 5y ago
    Long-time fan of joepie. Worth a follow.
- eurasiantiger 5y ago
  > You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again). GraphQL clients like Apollo can solve this by re-authenticating transparently on error and reissuing the same request.
- ledauphin 5y ago
jillesvangurp 5y ago
Exactly, all of the reasons bearer tokens might be awful are essentially self inflicted pain. Simple suggestion: don't do that and do it right instead. It's an opaque blob, by design. Which means it could be anything. Including something bearing useful information that you can verify in a sane way. In our case, we use JWT tokens that contain a few claims, are signed, have an expiration token, etc. Not awful at all. Verifiable information, signed by us with our private key, exchanged over https. That's not information the bearer of the token needs to be aware of but it is something our APIs can trivially verify and use as a basis for authenticating the bearer of the token. Pretty neat mechanism. Nothing wrong with it. Used at scale by world + dog on the internet without a lot of issues. And before somebody starts ranting about JWTs being awful: same argument. They don't have to be but they can might if you decline to use sane crypto. So, use it properly and you're fine. It's not that hard.
- mjg59 5y ago
  And if I compromise a system that possesses one of those JWTs, I can copy it elsewhere and have access to all the resources that JWT grants me access to. You're not tying it to a specific device, and you're not providing a mechanism to verify the device state when making the access decision.
  - jillesvangurp 5y ago
    That's why we use expiration times. If I was a bank, I would be using very short expiration times and also use second factors. And have a lot of ceremony around releasing our app. And if I cared enough I would indeed add some claims narrowing down the scope of the token to a device, require our user to wear tin foil hats, and what not. Security measures are proportional to the thing they protect. Plenty of banks use both bearer tokens and JWTs. Nothing inherently wrong with that. If your require these things, do them. If you don't, then don't.
    - mjg59 5y ago
      I, as your customer, don't control your expiration time. But I, as your customer, would like to be able to apply my choice of policy to tokens that you issue that grant someone access to my data, because otherwise I don't control access to my data.

mjg59 5y ago

The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?

xnorswap 5y ago
I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?
- mjg59 5y ago
  Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.
  - iso1631 5y ago
    That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.
    - mjg59 5y ago
      You're a 5-person startup. How do you verify that all of Github's token issuance policies align with your needs?
      - iso1631 5y ago
        Don't. Run your own. It's a cost of business, you can either rely on the standard terms of your suppliers, or you can supply your own, it's far easier than the vast majority of industries. Git especially is a federated system that has no need for things like github.
        mjg59 5y ago
        Or we could invent better solutions where we didn't need to depend on policies imposed by vendors? The value that Github provides isn't around their git hosting, it's all the integrated features. Reimplementing that isn't going to be trivial - there's a reason so many people use hosted Git rather than doing it themselves.
  - xnorswap 5y ago
    So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials. A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone. If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.
    - mjg59 5y ago
      No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.
      - xnorswap 5y ago
        But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.
        mjg59 5y ago
        I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.
iso1631 5y ago
So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk. I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk. [0] https://www.youtube.com/watch?v=y4GB_NDU43Q https://www.youtube.com/watch?v=y4GB_NDU43Q
- mjg59 5y ago
  I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.
  - iso1631 5y ago
    Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.

michaelt 5y ago

This is a common problem in enterprise single-sign-on systems. The issue is: If the user presses the 'log out' button, you want it to take effect within a few seconds. But if logouts are simply a timestamped record expiring, they'd have to expire within seconds, and that would basically mean re-authenticating on every single request. And at the same time, some webapps have shitty re-authentication flows (like discarding any unsaved work-in-progress and kicking the user back to the homepage) and they're only usable with a re-authentication periods measured in days.

jillesvangurp 5y ago
It's tradeoff. If you require tokens to be invalidated instantly, there's no way around the notion of doing some kind of lookup when you are validating the tokens. It could be as simple as having a database/memory store somewhere with invalidated tokens or all the still valid tokens. You might cache those for a few seconds so the performance overhead would be pretty minor. You can make this as strict/complicated/slow as you need it to be. It's up to the validating party to decide just how strict they want to be. But mostly, the device simply deleting the tokens when the user clicks logout is good enough though. Logout does not protect against mitm attacks of course. But that's not what logout is about. And if you have attacks like that going on, the user clicking logout or not does not matter anyway because you can't trust anything they do since you can no longer tell them apart from whomever is attacking. All a logout signals is the user throwing away their tokens (and probably a lot of other local state). Which is why world + dog uses either tokens that never expire or tokens with expiration times that are pretty long. In our case we use access tokens and refresh tokens. The access tokens are refreshed regularly and the refresh tokens expire after a few months. So, the only users that we force through repeated login procedures are those that don't regularly use our app. Anything more would be annoying. And yes, if their devices get hacked, those users have would have an issue. That's the tradeoff. The user using a token they just threw away is not a real problem because they wouldn't. The user's tokens getting stolen is a different problem. That's why having the tokens expire eventually is a good thing. Long expiration times are not appropriate if you are a bank for obvious reasons. So, they tend to use expiration times measured in minutes typically and use additional authentication around sensitive transactions.

xnorswap 5y ago

A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash. So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer tokens from a single sign on to grant access to the API. That works great until Bob realizes that Eve has got access to his password and hits a password reset to force Eve out the system. But with bearer tokens, Eve still has access until those tokens expire. You could add a check for expiration against the calls, but then we're back to session keys being more straightforward because we're back to having some central information (has Bob's token expired) that needs propagation to the different services. You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again). I think bearer tokens work best for internal proxies / APIs to avoid hitting the data store, they aren't a great replacement for session keys.

mormegil 5y ago
Yeah, there is this classic: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
- spacemanmatt 5y ago
  Long-time fan of joepie. Worth a follow.
eurasiantiger 5y ago
> You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again). GraphQL clients like Apollo can solve this by re-authenticating transparently on error and reissuing the same request.
ledauphin 5y ago

jillesvangurp 5y ago

Exactly, all of the reasons bearer tokens might be awful are essentially self inflicted pain. Simple suggestion: don't do that and do it right instead. It's an opaque blob, by design. Which means it could be anything. Including something bearing useful information that you can verify in a sane way. In our case, we use JWT tokens that contain a few claims, are signed, have an expiration token, etc. Not awful at all. Verifiable information, signed by us with our private key, exchanged over https. That's not information the bearer of the token needs to be aware of but it is something our APIs can trivially verify and use as a basis for authenticating the bearer of the token. Pretty neat mechanism. Nothing wrong with it. Used at scale by world + dog on the internet without a lot of issues. And before somebody starts ranting about JWTs being awful: same argument. They don't have to be but they can might if you decline to use sane crypto. So, use it properly and you're fine. It's not that hard.

mjg59 5y ago
And if I compromise a system that possesses one of those JWTs, I can copy it elsewhere and have access to all the resources that JWT grants me access to. You're not tying it to a specific device, and you're not providing a mechanism to verify the device state when making the access decision.
- jillesvangurp 5y ago
  That's why we use expiration times. If I was a bank, I would be using very short expiration times and also use second factors. And have a lot of ceremony around releasing our app. And if I cared enough I would indeed add some claims narrowing down the scope of the token to a device, require our user to wear tin foil hats, and what not. Security measures are proportional to the thing they protect. Plenty of banks use both bearer tokens and JWTs. Nothing inherently wrong with that. If your require these things, do them. If you don't, then don't.
  - mjg59 5y ago
    I, as your customer, don't control your expiration time. But I, as your customer, would like to be able to apply my choice of policy to tokens that you issue that grant someone access to my data, because otherwise I don't control access to my data.