5 ms·

This is why I prefer not to pass session information to the client in the first place. Have the session key be just an opaque, cryptographically random token th

This is why I prefer not to pass session information to the client in the first place. Have the session key be just an opaque, cryptographically random token that is then associated with data on the server (via a keystore of some sort). Then the cookie becomes nothing more than a bearer token. There are some use cases this does not cover, such as authentication across multiple systems, where one or more may not have access to the authentication source, but even in that case it'd be preferable to have a separate, internal, private microservice that exchanges tokens for session information. None of this will stop an attacker that has network access, but that's not what the article is considering, and if somebody is inside your network you might have bigger problems than session hijacking.

fpgaminer 10y ago
The reason is that, at scale, all the little things matter. Having to query your database for _every_ user request, to convert their session token into the server-side underlying data, gets expensive and slow. And it's a centralizing force in the architecture, requiring your session management database to be accessible by all your user facing servers. So they store the data with the client, who can pass it back to the server with every request. One less DB query. There are various rebuttals to that approach, even at scale, etc, etc. I'm certainly not advocating for it. But that's what some big applications landed on. Big apps drive most of the development of free tools, libraries, and frameworks. So it's no surprise that a lot of free tools handle this use case, even by default. In the majority of cases, the not at scale cases, of course it doesn't make sense. Most all the hot new tools don't make sense. But again, that's just an artifact of software economics. The majority of the money is made by the big apps, so most tools are built for the big apps. It's just a shame that new developers get caught up in these hip tools and base their understanding of the ecosystem on them.
- einrealist 10y ago
  Session key verification can be a cross cutting concern that is good enough for scale (API gateway, reverse proxy, cross cutting service). And with a verified session key, each service should be able to optimize for restoring data belonging to that session key. If the data leaves your server, it is considered potentially malicious and you have to verify and validate everything anyway. Also, with client-side stored data you lose control over the client-server state unless you validate against the server state. But then you lose all the advantages of client-side storage. Crypto cannot mitigate that.
- hdhzy 10y ago
  > One less DB query. This trait constantly appears in threads about JWT. But then how do you handle token invalidation? I wonder how big IT companies (Google, Microsoft, Amazon) are really doing it...
  - jsjohnst 10y ago
    Most of the big companies to my knowledge generally don't depend on client side storage of session state (they might in a few isolated cases, but in general avoid it).
    - hdhzy 10y ago
      Thanks. Google uses interesting approach to handling service accounts: JWT is used as user credential once to get the access token (session credentials) that is reused between requests. https://developers.google.com/identity/protocols/OAuth2ServiceAccount https://developers.google.com/identity/protocols/OAuth2Servi...

fpgaminer 10y ago

The reason is that, at scale, all the little things matter. Having to query your database for _every_ user request, to convert their session token into the server-side underlying data, gets expensive and slow. And it's a centralizing force in the architecture, requiring your session management database to be accessible by all your user facing servers. So they store the data with the client, who can pass it back to the server with every request. One less DB query. There are various rebuttals to that approach, even at scale, etc, etc. I'm certainly not advocating for it. But that's what some big applications landed on. Big apps drive most of the development of free tools, libraries, and frameworks. So it's no surprise that a lot of free tools handle this use case, even by default. In the majority of cases, the not at scale cases, of course it doesn't make sense. Most all the hot new tools don't make sense. But again, that's just an artifact of software economics. The majority of the money is made by the big apps, so most tools are built for the big apps. It's just a shame that new developers get caught up in these hip tools and base their understanding of the ecosystem on them.

einrealist 10y ago
Session key verification can be a cross cutting concern that is good enough for scale (API gateway, reverse proxy, cross cutting service). And with a verified session key, each service should be able to optimize for restoring data belonging to that session key. If the data leaves your server, it is considered potentially malicious and you have to verify and validate everything anyway. Also, with client-side stored data you lose control over the client-server state unless you validate against the server state. But then you lose all the advantages of client-side storage. Crypto cannot mitigate that.
hdhzy 10y ago
> One less DB query. This trait constantly appears in threads about JWT. But then how do you handle token invalidation? I wonder how big IT companies (Google, Microsoft, Amazon) are really doing it...
- jsjohnst 10y ago
  Most of the big companies to my knowledge generally don't depend on client side storage of session state (they might in a few isolated cases, but in general avoid it).
  - hdhzy 10y ago
    Thanks. Google uses interesting approach to handling service accounts: JWT is used as user credential once to get the access token (session credentials) that is reused between requests. https://developers.google.com/identity/protocols/OAuth2ServiceAccount https://developers.google.com/identity/protocols/OAuth2Servi...