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

121–130 of 254 posts

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

#121

Post by newscracker »

ixtli wrote: post #113
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).

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…

In Firefox, there's a configuration setting (from about:config) in Windows (not sure about other OSes) that can be used to tell Firefox to use the system certificate store for root CAs. There are also deployment mechanisms where this can be pushed as one of the default policies. [1]

The Firefox Enterprise mailing list is the place to go to for deeper level help on these things. [2]

[1]: https://wiki.mozilla.org/CA:AddRootToFirefox

[2]: https://mail.mozilla.org/listinfo/enterprise

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

#122

Post by tptacek »

hundt wrote: post #120
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…

Do you recommend signing requests?

No. The reason to sign requests is the same as the reason to support OAuth: so that the owner of the account can sign a request and give it to someone else to execute --- delegated authentication. Signed requests are finer-grained than OAuth is, but OAuth is much simpler and is the industry standard at this point. Don't do either thing until you absolutely need it, but then, start with OAuth.

Signed requests have burned a bunch of applications, more than have been burned by OAuth.

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

#123

Post by always_good »

iopuy wrote: post #112
drderidder wrote: post #68

I highly recommend reading "The Do's and Don'ts of Client Authentication on the Web" [1] from MIT. It's rather old and not very well-known, but it's excellent. The concepts provide very useful background info that will serve you well no matter what technology you use to implement your HTTP services, including issues like session hijacking, etc. One of it's best recommendations: avoid roll-your-own solutions. Secondly…

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

I think that if you use passportjs because you don't understand how to implement authn yourself, then you're no any better off from a security standpoint.

To me, passportjs might be useful if you need to plug into 3rd party auth APIs, but I don't really see the point. Authentication is a core part of your application and you should always know exactly how it works.

If you can't store an authn secret with confidence, how can you do anything with confidence?

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

#124

Post by everdev »

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?

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

#125

Post by newscracker »

scriptkiddy wrote: post #109
LandR wrote: post #34

Earlier quoted context omitted.

We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a g…

I Found a somewhat interesting solution for this issue. I assume you know what an ssh public/private key is, correct? Well, apparently, there is a way to apply this concept of ssh public key authentication to the HTTP protocol. This technique is referred to as "Mutual Authentication": http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS... Basically, it's 2-way SSL. You use signed SSL certs to authenticate th…

This brings in the question of how long the client certificate would be valid for and how it would be renewed before expiry. If sending a tech costs a good sum of money, one may be tempted to use certificates that are valid for decades, which may or may not be a good idea depending on the client environment, advances in cracking some algorithms or proving collisions in hashing, and business related factors.

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

#126

Post by tptacek »

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?

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.)

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

#127

Post by colinhowe »

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…

Just a brief addition to this as a user of APIs. Allow me to create a new token and have two tokens for the same account. This makes rotation of tokens without loss of service possible :)

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

#128

Post by newscracker »

intrasight wrote: post #96

In addition to token/key, for some APIs in the past I've added IP address filters.

Using IP address filters would require knowing the client environment and keeping some kind of planning and communication mechanisms of changes in what. Big enterprises would have teams and a lead time of a few months to sort this out, adding more overhead and costs to the service provider (which would have to somehow be recovered or absorbed).

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

#129

Post by dboreham »

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…

One very important thing you didn't mention : you MUST force transport encryption (SSL/TLS) to be used (deny plaintext connections). This is because the bearer token can be stolen by eavesdropping and since it's a bearer token it can be re-used by anyone anywhere.

Also remember to time out the tokens: it is almost never a good idea to permit infinitely long login sessions (surprising how often I see this not done). Again remember to invalidate the token when the user changes their password.

I agree that OAuth is not necessary on its own but it can be appropriate if you are also supporting delegated authentication with various 3rd parties : make your own native auth just another OAuth provider.

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

#130

Post by hundt »

tptacek wrote: post #122
hundt wrote: post #120

Earlier quoted context omitted.

Do you recommend signing requests?

No. The reason to sign requests is the same as the reason to support OAuth: so that the owner of the account can sign a request and give it to someone else to execute --- delegated authentication. Signed requests are finer-grained than OAuth is, but OAuth is much simpler and is the industry standard at this point. Don't do either thing until you absolutely need it, but then, start with OAuth. Signed requests have bur…

Thanks for the response!

My thinking was that you might sign requests so that a request that was intercepted or inadvertently logged would not contain sufficient credentials to authorize arbitrary other requests for the indefinite future. It sounds like you do not consider that a significant enough issue to justify the complexity involved.

Post reply on HN