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

211–220 of 254 posts

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

#211

Post by 013a »

beckler wrote: post #205
013a wrote: post #182

Earlier quoted context omitted.

> Do not use JWTs, which are an increasingly (and somewhat inexplicably) popular cryptographic token that every working cryptography engineer I've spoken to hates passionately. Can we get more intel behind why JWT is bad? I've always been told that as long as you explicitly check both the signature and that the signature algorithm type is what you expect, its fine. Libraries tend to make the mistake of not doing that…

You can't prematurely expire or invalidate JWT tokens once created, unless you keep a database of tokens, and at that point you should just use sessions because that's basically what it is at that point: A session token with additonal data.

That doesn't mean JWTs are bad; it just means their use case is more restrictive. JWTs are designed for sessions; think Google API tokens that have a validity of 1 hour. If you're using them for anything longer than that, then you'll probably need to back it with a database so you can support revocation, and at that point JWTs make less sense because they're so large.

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

#212

Post by matwood »

stephengillie wrote: post #145
iopuy wrote: post #112

Earlier quoted context omitted.

Isn't using the "auth" snippet more an example of rolling your own crypto? Why not use established libraries like passportjs? Super curious.

I wrestled with Passport for 3 weekends last October on my side project before reverting to a simple form for login. Passport has several dependencies that aren't well-documented, like a SQL ORM. It took a full weekend of researching to figure out what ORMs were and how they were used, since almost every blog assumes readers will recognize one in their code. This led to blogs pushing the opinion that ORMs were pointl…

Passport is pretty large so it can be confusing. IMO, it's much easier to not use the session stuff in passport and just do your own thing letting passport handle the flow. You can use the BasicAuth strategy on a /login url to sign someone in and grant a token, and then use Bearer auth strategy to check the token on the rest of your urls.

Doing it that way, Passport doesn't require an ORM at all. You'll need to obviously provide a way to auth a user and verify a token, but that's then up to you.

Now, if you want to actually use OAuth it can get complicated because the flow.

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

#213

Post by oxymoron »

LanceH wrote: post #166
oxymoron wrote: post #144

Earlier quoted context omitted.

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?

Well, you don’t, so if that’s a requirement you’ve got to do it some other way.

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

#214

Post by e12e »

oxymoron wrote: post #213
LanceH wrote: post #166

Earlier quoted context omitted.

How do you revoke access to that token?

Well, you don’t, so if that’s a requirement you’ve got to do it some other way.

You can rotate the secret to invalidate all tokens.

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

#215

Post by wglb »

user5994461 wrote: post #178
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…

>>> 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". Please don't reinvent the wheel and use a guid. A guid is a random number generator to avoid collisions.

GUIDS are NOT random. They are unique (the 'U' in GUID).

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

#216

Post by pvg »

MichaelGG wrote: post #208
tptacek wrote: post #184

Earlier quoted context omitted.

I don't think this buys you anything. Keep things simple.

I feel like picking a fight. What's the downside? It's super simple to hash them, and it prevents a read-only exploit from turning into a major catastrophe. Example from something I built. If our db was used by an attacker, with all client API keys, they could go liquidate those accounts (place phone calls). Huge loss, and not far-fetched (this kind of attack happens daily and is profitable). With hashed API keys, no…

Click the link in his comment.

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

#217

Post by e12e »

batoure wrote: post #189
tptacek wrote: post #167

Earlier quoted context omitted.

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.

Yeah this is the problem with crypto security people they are one dimensional. JWT has the benefit of allowing disconnected services to send each other information through the front end. Which minimizess the number of things you need to get right or in your words equals more secure. Designing a token that can be validated instead of looked up. (Design/Implement once) Or maintaining, updating and monitoring a set of f…

That's also an argument for just using Kerberos over the Internet. And I'm not sure that's a good idea.

I'm almost certain it's a bad idea if that means rolling your own Kerberos implementations in php, javascript and golang in order for your various back-end to speak to your various front-ends.

But sure, leverage secret-key crypto and tickets in your own implementation in a way that's more secure than Kerberos.

Or, use a solution that's simple enough any weakness is fairly obvious.

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

#218

Post by thijsvandien »

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…

Could you clarify why (or when) to use bearer tokens instead of Basic Authentication (i.e. sending username and password) with every request? Is it that if the server is compromised, only passwords from future logins can be stolen rather than those of everyone who performs a request? The cost of checking the hash? Other reasons?

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

#219

Post by tptacek »

thijsvandien wrote: post #218
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…

Could you clarify why (or when) to use bearer tokens instead of Basic Authentication (i.e. sending username and password) with every request? Is it that if the server is compromised, only passwords from future logins can be stolen rather than those of everyone who performs a request? The cost of checking the hash? Other reasons?

The purpose of a password is to have an authenticator that is human-readable/writeable and, ideally, human-memorable. Ideally, a strong password is stored only in a person's head; in the very worst (and unfortunately common) case, it's also stored in a password manager.

API authentication doesn't have the memorability problem, because the password has to be stored somewhere the client program can reach it. But, as you can see, it does have the storage problem, which means you need to account for the fact that it might be compromised in storage.

So you need a separate credential for API access. Since it's only going to be used by computers, there's no purpose served by making it anything other than a computer-usable secure credential; hence: a 128 bit token from /dev/urandom.

Once you have a 128 bit token, there's also little purpose served by forcing clients to relay usernames, since any 128 bit random token will uniquely identify an account anyways.

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

#220

Post by cjcampbell »

tptacek wrote: post #175
pvg wrote: post #170

Earlier quoted context omitted.

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.

My plan is just to keep repeating it over and over again so that more people will see the words arranged that way in a sentence: "you don't need stateless authentication; it's usually not a good thing".

That is sometimes what it takes. Appreciate the additional explanation you’ve put into other comments from this thread. Will most likely be referring back to this one when I get tired of repeating similar points. ;)
Post reply on HN