Ask HN: What's the recommended method of adding authentication to a REST API?

Post by tptacek » Tue, Jan 16, 2018, 6:35 PM UTC

cuspycode wrote: post #162

tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

Great points! I use high-entropy random secrets as passwords in the Basic Authorization header, with their hashes stored in a database. I also use cookies to make the browser experience pleasant and secure. The cookies are based on a HMAC hash that uses a single server-side secret, a string representing the principal, and a timestamp. So the cookies work without needing server sessions. HTTPS is mandatory of course,…

Post by u801e » Tue, Jan 16, 2018, 6:37 PM UTC

rkangel wrote: post #90

6ue7nNMEEbHcM wrote: post #64

Hi, can someone explain me why SSL client authentication is not widely used? You can use the same protocol you use to authenticate hosts to authenticate users, yet no one seem to do that nowadays. I'm not professional web developer so maybe answer to this question is obvious (but I just don't know it).

I have worked with systems that use it to authenticate machine to machine communication (e.g. a web backend authenticating itself to another service doing work for it). In that environment it works well. Using it to authenticate a person regardless of device doesn't work so well from a usability point of view.

Post by tptacek » Tue, Jan 16, 2018, 6:40 PM UTC

pvg wrote: post #170

tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

You almost certain[ly] do not and will not need "stateless" authentication Unless you get Bill Murray to run into people on the street or crash their all-hands meetings and tell them this, no one will believe you. Or at least, it's worth a try since nothing else seems to work, as seen in thread.

Post by iovrthoughtthis » Tue, Jan 16, 2018, 6:44 PM UTC

everdev wrote: post #124

tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

Don't major companies like Google use JWTs?

Post by zaroth » Tue, Jan 16, 2018, 6:48 PM UTC

tptacek wrote: post #171

cuspycode wrote: post #162

Earlier quoted context omitted.

Great points! I use high-entropy random secrets as passwords in the Basic Authorization header, with their hashes stored in a database. I also use cookies to make the browser experience pleasant and secure. The cookies are based on a HMAC hash that uses a single server-side secret, a string representing the principal, and a timestamp. So the cookies work without needing server sessions. HTTPS is mandatory of course,…

All of this seems inferior to just using a 128 bit random token drawn from /dev/urandom and stored in a database. If you see "HMAC" in an API authentication design, something weird and probably bad is happening.