3 ms·

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.
      • LanceH 5y ago
        > doubling or tripling That's not even arguing in good faith, or shows an extreme lack of experience. Auth/auth is routinely cached. Even if it's a database call, the query used there will likely be cached. Auth is a miniscule portion of a web page's performance.
        • lmm 5y ago
          > Auth/auth is routinely cached. Which completely undermines the argument for not using JWT. "We can't use JWT because then tokens would be valid for 5 minutes after the user logged out" - but if you're caching your auth for 5 minutes then you have exactly the same risks.
    • neurostimulant 5y ago
      > Session data and any centralised auth check (banned user for example) are simply database calls JWT doesn't make sense if your app can simply make a direct database calls for authentication check. But if your app is composed of myriad of microservices which aren't allowed to query the database directly and must call another service to access data outside the caller's scope, then yeah the only option is making the authentication service fast enough to tank all the authentication checks or use jwt which makes any microservice able to confirm authentication status without querying the auntentication service. Which is another reason why I think microservice architecture is a giant waste of time and productivity unless you're google-scale.