3 ms·

> If you issue a long lived bearer token, bad things will happen. I can issue a short lived bearer token, and another service I don't control can then decide b

by mjg59 5y ago

> If you issue a long lived bearer token, bad things will happen. I can issue a short lived bearer token, and another service I don't control can then decide based on that to issue a long lived one and I have no generic way to gain insight into that.

mooreds 5y ago
Fair, by using bearer tokens you don't have full control over how they are used by downstream parties. But that's a bit like saying: I have a metal key that I only give to trusted people, but someone I trust can make a copy of that key and give me back the original. Therefore I can't trust metal keys. I guess I'd want to dig in a bit more to understand the use case. Who is deciding to use the other service? Who is accepting the long lived token? (you? If so, why? The issuer? Well then, they made that choice.)
- mjg59 5y ago
  If a metal key that could be duplicated was sufficient for someone to gain access to my company's entire source repository, then yes, I'd say that I shouldn't trust a metal key to be sufficient access control. If that was the best available then I might grudgingly accept it, but in the analogous case here we definitely have something better in the form of hardware-backed asymmetric keys. Here's an example scenario. One of my users runs Github Desktop and clicks "Sign in". This process involves them performing extra authentication in order to gain access to our enterprise organisation, which is handled by my identity provider. I can hook into that authentication process in order to verify device identity and state, and I can issue a short-lived token. Github will then happily take this short-lived token and provide a long-lived token to the Github Desktop app which will grant access to my organisation's source code without any further authentication, and which is not bound to the device in any way.

3 ms·

> If you issue a long lived bearer token, bad things will happen. I can issue a short lived bearer token, and another service I don't control can then decide b

by mjg59 5y ago

mooreds 5y ago
Fair, by using bearer tokens you don't have full control over how they are used by downstream parties. But that's a bit like saying: I have a metal key that I only give to trusted people, but someone I trust can make a copy of that key and give me back the original. Therefore I can't trust metal keys. I guess I'd want to dig in a bit more to understand the use case. Who is deciding to use the other service? Who is accepting the long lived token? (you? If so, why? The issuer? Well then, they made that choice.)
- mjg59 5y ago
  If a metal key that could be duplicated was sufficient for someone to gain access to my company's entire source repository, then yes, I'd say that I shouldn't trust a metal key to be sufficient access control. If that was the best available then I might grudgingly accept it, but in the analogous case here we definitely have something better in the form of hardware-backed asymmetric keys. Here's an example scenario. One of my users runs Github Desktop and clicks "Sign in". This process involves them performing extra authentication in order to gain access to our enterprise organisation, which is handled by my identity provider. I can hook into that authentication process in order to verify device identity and state, and I can issue a short-lived token. Github will then happily take this short-lived token and provide a long-lived token to the Github Desktop app which will grant access to my organisation's source code without any further authentication, and which is not bound to the device in any way.