Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 254 posts

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

#161

Post by ixtli »

jhanschoo wrote: post #157
ixtli wrote: post #113

Earlier quoted context omitted.

Personally I've always used x509 client certs with a self signed root authority / intermediate authority for internal tooling at companies i've worked for. This is possible because 1) i happen to already have a good understanding of openssl and how to use it, secure keys 2) i have control over the devices im provisioning so i can make them trust my root cert for timing/x509/etc. It would be really cool if there was a…

Considering that mozilla is one of the founding members of Let's Encrypt, I think and hope that they are pretty competent in PKI.

Heh you make a good point.

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

#162

Post by cuspycode »

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, and caching successful authorizations help performance.

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

#163

Post by matwood »

azernik wrote: post #115
matwood wrote: post #110

Earlier quoted context omitted.

> but requires that the client retain the non-expiring username and password IMO, this makes this simpler solution a non-starter. It becomes way too easy to leak credentials.

The auth framework I use avoids this problem but remains stateless by encrypting/signing the tuple (user ID, session expiration time, maybe other stuff) in a cookie. Essentially it's using the browser as an encrypted one-row database to store the info that would normally be in a sessions table.

This can work, but you want to keep what you send with every request very small. It's also hard to do a mass expiration or revoke a single session. If you have the tokens on the server you can run a query and easily do both. Checking signatures and decrypting on every request can also be a performance issue.

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

#164

Post by logicuce »

tptacek wrote: post #126
everdev wrote: post #124

Earlier quoted context omitted.

Don't major companies like Google use JWTs?

Major companies like Google do all sorts of dumb things, and, equally importantly, have gigantic well-funded security teams triple-checking what they do, so that the pitfalls in these standards are mostly an externality to them. (The actual answer is: I have no idea what Google does with JWTs.)

With the right choice of algorithm, and if you control the code which interprets that JWT (whitelisting the alg and choosing the right library), I don't see a reason why JWT would be insecure.

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

#166

Post by LanceH »

oxymoron wrote: post #144
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…

I’ve frequently used the equivalent of HMAC_SHA512(long_secret,uid + ’|’ + timestamp) to generate a token on the server, which the client can retain and pass along requests, and can be verified on the server without persistence. I assume this is what you refer to as stateless authentication. While I agree that there are no real performance reasons to do so, it seems convenient to me every now and then. Is there a sec…

How do you revoke access to that token?

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

#167

Post by tptacek »

logicuce wrote: post #164
tptacek wrote: post #126

Earlier quoted context omitted.

Major companies like Google do all sorts of dumb things, and, equally importantly, have gigantic well-funded security teams triple-checking what they do, so that the pitfalls in these standards are mostly an externality to them. (The actual answer is: I have no idea what Google does with JWTs.)

With the right choice of algorithm, and if you control the code which interprets that JWT (whitelisting the alg and choosing the right library), I don't see a reason why JWT would be insecure.

It's absolutely true that if you do everything correctly, a JWT implementation can be secure. Generally, in crypto engineering, we're looking for constructions that minimize the number of things you need to get right.

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

#168

Post by cobbzilla »

eropple wrote: post #104
cdaven wrote: post #80

Earlier quoted context omitted.

Yes, if you mean a token that identifies a session that is saved on the server somehow. But not a JWT, which is only saved on the client and verified on the server.

"Stateless" refers to the app, not to its datastores, because that would be nonsensical. JWT is also poorly specified (no protocol under any circumstances should use negotiation, it does not support revocation, and it has been hammered home by the best security folks I know that public key cryptography is what you do when you don't have any other choice) and dangerous to use. Avoid it. Do the simplest thing that can…

Totally agree -- but verifying a session token doesn't even have to be a database call. Put the token in memcache or redis; now, if you are so successful that a single network call that doesn't touch disk is your bottleneck, well, you can hire some very smart people to fix that for you.

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

#169

Post by nullbyte »

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…

What's so bad about JWT's? The cryptographic protocol is sound.

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

#170

Post by pvg »

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 reply on HN