5 ms·

This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it. For example, say client A calls service B, using

This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it. For example, say client A calls service B, using a token signed by service C. Previously, we were using randomly generated session keys, which meant B had to ask C every time. But with JWTs, B can directly verify that the token is genuine without asking C, because it has C's public key. We still check with C now and then, but that's because the token auto-expires. We use a long-lived master token stored in a cookie to generate new short-lived ones.

joepie91_ 10y ago
The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not. What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authorization token for a session on a stateful service. In none of those three cases do you use the token as the session. Tokens are handed out on a single-use, as-needed basis.
- lobster_johnson 10y ago
  The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not heard the term "direct-to-database" before, but we've been doing it for about 6 years, albeit not using Firebase, and it's huge win over the classic "custom, ad-hoc API per use case" methodology. Exposing a shared data layer abstraction between microservices is no different than exposing a more targeted API (i.e. there's conceptually zero difference between "POST /objects/42" and "POST /users/42"), including as far as security is concerned.
  - spriggan3 10y ago
    > Central session stores don't scale with distributed architectures. Sessions stores scale as much as anything else.
    - lobster_johnson 10y ago
      Not what I was referring to. They scale just fine on their own, but the surrounding architecture doesn't when it becomes involved for every single call. Simple scenario: Let's say user X wants to update document Y, which involves fetching a photo, processing it and storing it as Z. To read Y, we need to check the session. To update Y, we need to check the session. To store the photo, we need to check the session. We're already up to three roundtrips to the session store. Some interactions require a lot more participants, each of which need to check the store. Over and over again, even though _clearly_ the world hasn't changed the last 300ms. If one API requires 6 calls to its partners, that's 6 times more roundtrips than necessary.
  - kalleboo 10y ago
    There was a solution to that situation proposed here[0] where you keep using session tokens on the user end (so you can still do stuff like revoke sessions), but convert that to a signed token for all internal API calls. [0] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...
    - lobster_johnson 10y ago
      Thanks. That's pretty much the solution we ended up with, though the article author doesn't see the whole picture. Asking a central authority to issue single-use tokens for every call will result in a huge amount of unneeded network traffic.
DenisM 10y ago
The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.
- lobster_johnson 10y ago
  By previous post, did you the bit about "Federation becomes moderately difficult"? I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).
  - ams6110 10y ago
    Stop using so many different languages?
  - joshwa 10y ago
    Put it in the API gateway?
  - DenisM 10y ago
    I haven't. If you use microservices you should have an API gateway with sticky sessions, there is no need to check permissions for each service. It's more secure that way too, as it uses less code.
    - lobster_johnson 10y ago
      It's an interesting idea, but that would mean every internal microservice request (they don't just service users) would have to go through an API gateway, and every call would have to be checked against a session store. It also means (if I understand the design correctly) that the API gateway has to munge every request envelope to add the actual user ID as an HTTP header (or something similar with gRPC), so that the internal microservices can see it, otherwise they'd have to ask the session store, which would defeat the purpose. This in turn would mean that every microservice has to trust the upstream, which would require some infrastructure to manage (i.e., microservices would no longer be simply exposed to the world; the API gateway would be a special trusted actor). You also now have a dependency on the API gateway, because the microservice wouldn't know how to deal with a session without it.

joepie91_ 10y ago

The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not. What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authorization token for a session on a stateful service. In none of those three cases do you use the token as the session. Tokens are handed out on a single-use, as-needed basis.

lobster_johnson 10y ago
The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not heard the term "direct-to-database" before, but we've been doing it for about 6 years, albeit not using Firebase, and it's huge win over the classic "custom, ad-hoc API per use case" methodology. Exposing a shared data layer abstraction between microservices is no different than exposing a more targeted API (i.e. there's conceptually zero difference between "POST /objects/42" and "POST /users/42"), including as far as security is concerned.
- spriggan3 10y ago
  > Central session stores don't scale with distributed architectures. Sessions stores scale as much as anything else.
  - lobster_johnson 10y ago
    Not what I was referring to. They scale just fine on their own, but the surrounding architecture doesn't when it becomes involved for every single call. Simple scenario: Let's say user X wants to update document Y, which involves fetching a photo, processing it and storing it as Z. To read Y, we need to check the session. To update Y, we need to check the session. To store the photo, we need to check the session. We're already up to three roundtrips to the session store. Some interactions require a lot more participants, each of which need to check the store. Over and over again, even though _clearly_ the world hasn't changed the last 300ms. If one API requires 6 calls to its partners, that's 6 times more roundtrips than necessary.
- kalleboo 10y ago
  There was a solution to that situation proposed here[0] where you keep using session tokens on the user end (so you can still do stuff like revoke sessions), but convert that to a signed token for all internal API calls. [0] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...
  - lobster_johnson 10y ago
    Thanks. That's pretty much the solution we ended up with, though the article author doesn't see the whole picture. Asking a central authority to issue single-use tokens for every call will result in a huge amount of unneeded network traffic.

DenisM 10y ago

The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.

lobster_johnson 10y ago
By previous post, did you the bit about "Federation becomes moderately difficult"? I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).
- ams6110 10y ago
  Stop using so many different languages?
- joshwa 10y ago
  Put it in the API gateway?
- DenisM 10y ago
  I haven't. If you use microservices you should have an API gateway with sticky sessions, there is no need to check permissions for each service. It's more secure that way too, as it uses less code.
  - lobster_johnson 10y ago
    It's an interesting idea, but that would mean every internal microservice request (they don't just service users) would have to go through an API gateway, and every call would have to be checked against a session store. It also means (if I understand the design correctly) that the API gateway has to munge every request envelope to add the actual user ID as an HTTP header (or something similar with gRPC), so that the internal microservices can see it, otherwise they'd have to ask the session store, which would defeat the purpose. This in turn would mean that every microservice has to trust the upstream, which would require some infrastructure to manage (i.e., microservices would no longer be simply exposed to the world; the API gateway would be a special trusted actor). You also now have a dependency on the API gateway, because the microservice wouldn't know how to deal with a session without it.