Hacker News Reader

Comment by EthanHeilman | Hacker News Reader

I once operated a very low usage webservice that used JWT for auth. We got hit with a DDoS and it was trivial to mitigate by using AWS API gateway to drop HTTP requests that didn't contain a valid JWT for the IDPs we supported.

Making authentication only require a signature verification at the edge (JWT) vs authentication middleware that needs to do a DB read (opaque), can be a life saver even if you have 10 requests a second most of the time.

View on HN

This is a great point. 10 requests per second is likely to be sufficient scale that you are noticeable to people that might want to attack you. The ability to validate the key before doing anything with it could be a huge time (and resource) saver on AWS.

> The ability to validate the key before doing anything with it [..]

Q: What about the endpoint that's issuing the tokens?

In OpenID Connect the endpoint is issuing the tokens is run by Google, Microsoft or some other company that is too big to fail (or rather if it fails everything goes down).

If you are issuing the tokens yourself, you can build a simple horizontally scaling identity service that only does authentication and token issuance. With refresh tokens, if that service goes down it only prevents users not already signed in from signing in. Generally users stay signed into to webapps for weeks at a time, so you have massively reduced the impact: rather than 100% of your users not being able to do anything on your site, now 0.5% of users are impacted.

Reply on news.ycombinator.com