Hacker News Reader

Comment by matwood | Hacker News Reader

I have found the above (sans JWT) to be the simplest, secure method. Do everything over HTTPS, use basic auth or post for the user/pass and return an expiring token, use that token as a Bearer token for all subsequent requests.

View on HN

It's generally a good idea to avoid JWT. There are a lot of foot-guns in JWT, and many implementations have gotten it wrong in the past. This[1] is a good summary on the topic.

[1]: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

On the client side that adds some complexity. You either do always two requests (first get token, then use it) or need to manage the storing the token and doing the renewals. If there are bursts of traffic and multiple threads/processes you need to think if each one will get their own token or if others will wait while one is getting a fresh token.

I’m mostley a FE person at the moment so forgive me for my ignorance but how does the server use the token passed to the client to do auth?

Does it keep a copy somewhere and check against it on every request?

> Does it keep a copy somewhere and check against it on every request?

Yes. The last time I did this we checked the X-Token header on every request, if it didn't exist or there were multiple we replied 401. If only one was there we checked a DB table of active tokens, if it wasn't there or had expired we replied 401. If it was there but wasn't associated with a role that had access to the requested resource, we replied 403. If it was not expired and had access we continued with the request.

As soon as you get away from "check authentication on every request" your attack vectors increase. As a bad actor, I no longer need to bypass your authentication, I just need to bypass whatever system you have in place to decide whether or not to authenticate me. That's generally going to be easier.

I was planning to use custom headers over HTTPS for a similar thing, but then I read that some firewalls will strip custom headers, even over HTTPS. Can anyone with experience comment? Thanks.

Just use a Bearer token in the Authorization header from the OAuth spec: https://tools.ietf.org/html/rfc6750#section-2.1

> Does it keep a copy somewhere and check against it on every request?

Yep, a store like Redis that has automatic row expiration is what I have used in the past. Most clients will often be bursty in their requests so a simple few second cache on API after verifying the token can also be useful/performant.

Yes, a copy is kept somewhere — that somewhere could be application memory, a local file or database on the server where the application is running, or another server that provides this as a service (which may in turn store in memory or disk/database). Which approach is chosen depends on factors like performance/load capacity, availability/redundancy requirements (answering questions like, "if a server goes down, will users be logged out?"), etc.

Reply on news.ycombinator.com