| First of all, if my requirements are "not JWT" then the correct answer is not JWT. > You aren't blocking most of your requests waiting on your auth backend Yeah, at Facebook scale. My database responds in less than 1 ms. > for requests that actually need to have up-to-the-instant knowledge of a token's validity, you can always elect to hit up the auth backend anyway. So... what is the point of JWT when I always need to know if a token is valid? > For example it can let you use the same set of tokens for all your API's as you use for "web" traffic. It can reduce page latency. Again, my database responds in MS. If you're doing client side rendering anyway, why not just throw in middleware to check the session token? You are trading literally 1 millisecond of latency for unneeded application complexity. > I assert unless you are a bank or something, 99% of your authenticated traffic is read-heavy and can tollerate 5 minutes worth of somebody getting ahold of a token Read heavy traffic does not imply that 5 minutes of stolen credentials is okay. Could my app survive if someone stole a token and used it for 5 minutes? Sure. Do I want that to happen? No. Without JWT, I can revoke tokens in milliseconds. I can revoke tokens if IP is changed. I can revoke tokens if user agent changes. I can revoke tokens if a user rotates their device. > All the write traffic and "sensitive" read traffic can just hit up the backend server to do real-time token validation. Again, what is the point of JWT if you still need to hit the backend? All read traffic is sensitive to my app. > For example here on HN 99% of authenticated requests are just to view this page Sure, then why use JWT at all? Keep the profile name and points in cookies, upvotes in local storage. Who gives a shit if the data is a little stale? Right? JWT is unnecessary bloat in my opinion. At Facebook and Google scale I can see how saving billions of database calls a day could be useful. For people with less than a million page hits a day, probably not. |