3 ms·

That is the cool thing about JWT. You get the best of both worlds. With JWT you don't have to hit the auth server for requests where a ~5 minute (or whatever) w

That is the cool thing about JWT. You get the best of both worlds. With JWT you don't have to hit the auth server for requests where a ~5 minute (or whatever) window doesn't matter. That is probably 99% of the authenticated traffic on a lot of sites (thinking of HN, reddit, youtube, etc). On requests that matter, like on a write request or a "sensitive" read request, you can always ping your auth server to make sure the token is still legit. Cutting out 99% of your auth backend traffic can dramatically change how you design it.

ravenstine 5y ago
This seems like an invented problem. What is an auth server fundamentally? It's a hash table lookup. Which happens to be something that computers are designed to be really good at. I've never worked at a company where auth or storing user sessions was a bottleneck.
- spookthesunset 5y ago
  I worked at a place whose auth server system literally serviced tens of billions of request per day. 99% of that traffic was for "dude was logged in and is looking at some page that is not unlike the one you are reading right now on HN". JWT let us cut that traffic by 99%. The remaining 1% was for servicing refresh tokens and handling requests for "sensitive" traffic (i.e. account page, anything involving writes, anything dealing with billing). This was in a system with data centers across the globe. Auth might not be your primary bottleneck, but each page load you service has a latency budget and every millisecond spent being blocked on some auth call is a millisecond that could be spent doing else. And trust me, your database or crazy "solve it with redis" server isn't responding in 1ms, it's gonna be at least 20ms due to network overhead and the variance in latency on that request isn't always "20ms" it is "99% of the requests are 20ms and 1% are >>100ms". So now 1% of 10 billion requests (100 million requests) take way longer than 100ms... well that sucks... Not to mention when your auth backend blows up and dies... your site is completely dead in the water. JWT can at least let you tread water for a while. JWT is amazing. People that diss it don't understand it, or likely don't understand the tradeoffs they implicitly made with their own auth architecture.
- ledauphin 5y ago
  it's not the hash table lookup that is expensive, it's the network request. Computers are not good at network requests because physics says they can't be - it takes orders of magnitude more time for light/electricity to traverse even one side of a datacenter to another than it does to go from the CPU side of the motherboard to the RAM side. For plenty of use cases, the additional network roundtrip is very affordable. But it's simple math that explains why this might easily become half or more than half of the total load on your systems if you want to "just do an additional (network-mediated) hash table lookup" on every request.
  - sneak 5y ago
    The 100-2000ns it takes signals to move across a datacenter and back is not the primary cause of a network request being slow in comparison with a cpu.
    - spookthesunset 5y ago
      LOL to 2000ns. Seriously? 10ms minimum to go to the next rack. For 99% of the requests. For the unlucky 1% you'll get outlier performance due to.... well... you spend the next sprint figuring it out and the next quarter trying to solve that scaling bottleneck.... It could be network, it could be some weird design thing, it could be redis, who knows? But yeah... enjoy figuring it out instead of focusing on your product. 1% of all requests is actually a lot of requests. And if you think 1% of your auth requests aren't 10x the median... you aren't measuring it hard enough.
      - brobinson 5y ago
        What on earth kind of clownish network setup do you have where O(1) lookups over a network take 10ms? I worked on a tiny (3 people) engineering team serving 250,000 http requests/second 27/7/365 doing 5-6 over-the-network requests to other services (memcached, redis) per request we handled and our 99th percentile time to get a response on the wire was < 15 milliseconds.
        5y ago
- user5994461 5y ago
  >>> I've never worked at a company where auth or storing user sessions was a bottleneck. I can tell you from my experience working at JP Morgan (the largest US bank) that authentication checks was the #1 root cause of major outages. That is, except when it was #2. It was a close tie with network related issues depending on the season. It's easy enough to understand that when sessions can't be checked, every application and service that need to check sessions are effectively 100% down. Another hard learned fact is that (very) critical services or (very) high traffic services will simply never support remote sessions, because it's too slow and unreliable. (There are potential alternatives like JWT tokens or TLS authentication).
lamontcg 5y ago
On the front end you also have a user id in plaintext that you can use for request routing to send the user to the right shard in the right datacenter. That doesn't have to be cryptographically secure since cryptographic auth happens in a later step. By not having to decrypt anything your front end geographical load balancers can handle higher bandwidths (and more headroom for DDoS attacks).
LanceH 5y ago
This is optimizing for an already solved problem in a way that adds complexity and increases the opportunity for security problems.
- spookthesunset 5y ago
  JWT solves all kinds of problems, you just haven't encountered them or aren't sophisticated enough to detect them yet. I'd assert that all the solutions you might propose have their own non-trivial issues. For example your auth server better be god damn awesome if it is gonna service every front-end page load. If even 1% of its traffic takes an order of magnitude longer than the median... that means 1% of your front-end traffic is gonna take an order of magnitude longer too. Lord help you if that fucker hiccups for a minute every so often... JWT shields most front-traffic from auth-server latency issues because most front-end traffic never needs to talk to the backend. (And no, your auth server isn't perfectly designed and yes 1% of its traffic will be an order of magnitude slower for whatever random reason)
  - lbriner 5y ago
    You are arguing against a false assumption. Most web apps that use "normal" auth don't call an auth service. They drop an encrypted auth cookie that is checked on every page load and which is very fast. Session data and any centralised auth check (banned user for example) are simply database calls, which are no slower than the perhaps 10 or 20 other calls you are probably already making on your page. > or aren't sophisticated enough to detect them yet I'm sophisticated enough thanks!
    - lmm 5y ago
      > Session data and any centralised auth check (banned user for example) are simply database calls, which are no slower than the perhaps 10 or 20 other calls you are probably already making on your page. They're calls that you have to complete before you can start making any of the others (since it's not safe to start making database calls based on a user that hasn't been authenticated/checked for bannedness yet), so you're talking about more or less doubling or tripling your page's load time (check authentication, check authorization, then do the queries that give you the actual data) if you've got decently written queries.

ravenstine 5y ago

This seems like an invented problem. What is an auth server fundamentally? It's a hash table lookup. Which happens to be something that computers are designed to be really good at. I've never worked at a company where auth or storing user sessions was a bottleneck.

spookthesunset 5y ago
I worked at a place whose auth server system literally serviced tens of billions of request per day. 99% of that traffic was for "dude was logged in and is looking at some page that is not unlike the one you are reading right now on HN". JWT let us cut that traffic by 99%. The remaining 1% was for servicing refresh tokens and handling requests for "sensitive" traffic (i.e. account page, anything involving writes, anything dealing with billing). This was in a system with data centers across the globe. Auth might not be your primary bottleneck, but each page load you service has a latency budget and every millisecond spent being blocked on some auth call is a millisecond that could be spent doing else. And trust me, your database or crazy "solve it with redis" server isn't responding in 1ms, it's gonna be at least 20ms due to network overhead and the variance in latency on that request isn't always "20ms" it is "99% of the requests are 20ms and 1% are >>100ms". So now 1% of 10 billion requests (100 million requests) take way longer than 100ms... well that sucks... Not to mention when your auth backend blows up and dies... your site is completely dead in the water. JWT can at least let you tread water for a while. JWT is amazing. People that diss it don't understand it, or likely don't understand the tradeoffs they implicitly made with their own auth architecture.
ledauphin 5y ago
it's not the hash table lookup that is expensive, it's the network request. Computers are not good at network requests because physics says they can't be - it takes orders of magnitude more time for light/electricity to traverse even one side of a datacenter to another than it does to go from the CPU side of the motherboard to the RAM side. For plenty of use cases, the additional network roundtrip is very affordable. But it's simple math that explains why this might easily become half or more than half of the total load on your systems if you want to "just do an additional (network-mediated) hash table lookup" on every request.
- sneak 5y ago
  The 100-2000ns it takes signals to move across a datacenter and back is not the primary cause of a network request being slow in comparison with a cpu.
  - spookthesunset 5y ago
    LOL to 2000ns. Seriously? 10ms minimum to go to the next rack. For 99% of the requests. For the unlucky 1% you'll get outlier performance due to.... well... you spend the next sprint figuring it out and the next quarter trying to solve that scaling bottleneck.... It could be network, it could be some weird design thing, it could be redis, who knows? But yeah... enjoy figuring it out instead of focusing on your product. 1% of all requests is actually a lot of requests. And if you think 1% of your auth requests aren't 10x the median... you aren't measuring it hard enough.
    - brobinson 5y ago
      What on earth kind of clownish network setup do you have where O(1) lookups over a network take 10ms? I worked on a tiny (3 people) engineering team serving 250,000 http requests/second 27/7/365 doing 5-6 over-the-network requests to other services (memcached, redis) per request we handled and our 99th percentile time to get a response on the wire was < 15 milliseconds.
      - 5y ago
user5994461 5y ago
>>> I've never worked at a company where auth or storing user sessions was a bottleneck. I can tell you from my experience working at JP Morgan (the largest US bank) that authentication checks was the #1 root cause of major outages. That is, except when it was #2. It was a close tie with network related issues depending on the season. It's easy enough to understand that when sessions can't be checked, every application and service that need to check sessions are effectively 100% down. Another hard learned fact is that (very) critical services or (very) high traffic services will simply never support remote sessions, because it's too slow and unreliable. (There are potential alternatives like JWT tokens or TLS authentication).

lamontcg 5y ago

On the front end you also have a user id in plaintext that you can use for request routing to send the user to the right shard in the right datacenter. That doesn't have to be cryptographically secure since cryptographic auth happens in a later step. By not having to decrypt anything your front end geographical load balancers can handle higher bandwidths (and more headroom for DDoS attacks).

LanceH 5y ago

This is optimizing for an already solved problem in a way that adds complexity and increases the opportunity for security problems.

spookthesunset 5y ago
JWT solves all kinds of problems, you just haven't encountered them or aren't sophisticated enough to detect them yet. I'd assert that all the solutions you might propose have their own non-trivial issues. For example your auth server better be god damn awesome if it is gonna service every front-end page load. If even 1% of its traffic takes an order of magnitude longer than the median... that means 1% of your front-end traffic is gonna take an order of magnitude longer too. Lord help you if that fucker hiccups for a minute every so often... JWT shields most front-traffic from auth-server latency issues because most front-end traffic never needs to talk to the backend. (And no, your auth server isn't perfectly designed and yes 1% of its traffic will be an order of magnitude slower for whatever random reason)
- lbriner 5y ago
  You are arguing against a false assumption. Most web apps that use "normal" auth don't call an auth service. They drop an encrypted auth cookie that is checked on every page load and which is very fast. Session data and any centralised auth check (banned user for example) are simply database calls, which are no slower than the perhaps 10 or 20 other calls you are probably already making on your page. > or aren't sophisticated enough to detect them yet I'm sophisticated enough thanks!
  - lmm 5y ago
    > Session data and any centralised auth check (banned user for example) are simply database calls, which are no slower than the perhaps 10 or 20 other calls you are probably already making on your page. They're calls that you have to complete before you can start making any of the others (since it's not safe to start making database calls based on a user that hasn't been authenticated/checked for bannedness yet), so you're talking about more or less doubling or tripling your page's load time (check authentication, check authorization, then do the queries that give you the actual data) if you've got decently written queries.