Live data from Hacker News

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

news.ycombinator.com

131–140 of 254 posts

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

#131

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

You need transport encryption no matter what, not just for REST APIs. I'm just addressing the app design concerns.

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

#132
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…

Signed requests were also invented when the transport connection was in the clear: if the request were not signed then it could be modified in transit by an attacker. These days all sessions are encrypted (SSL/TLS) and so this concern doesn't exist (or doesn't exist if you trust the transport).

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

#133

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

The downside to allowing multiple tokens is that in the real world, people will create new tokens for new deployment environments, but never delete the old ones, which will inevitably end up on Github somehow.

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

#134

Earlier quoted context omitted.

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…

Signed requests were also invented when the transport connection was in the clear: if the request were not signed then it could be modified in transit by an attacker. These days all sessions are encrypted (SSL/TLS) and so this concern doesn't exist (or doesn't exist if you trust the transport).

The AWS API runs over TLS, and uses signed requests.

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

#135
post #130

Earlier quoted context omitted.

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.

No. You need to be securely using TLS anyways. Signed requests are hard to get right (Google "canonicalization vulnerabilities"). That's not a good tradeoff.

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

#136
post #130

Earlier quoted context omitted.

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.

Good point: Credentials must not be logged. The easiest way to achieve this is to use HTTP basic auth for the token because web server infrastructure already knows not to log that, or a header OAuth2 style.

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

#137
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 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,…

I would disagree on the grounds that authentication is, generally speaking, a well-solved problem for the level most applications require. It's a better use of your time to use a library that's well-used and well-understood rather than rolling Yet Another (Probably Bad) Authentication Framework.

I will concede, however, that the most basic forms of authentication that I've used are so close to the metal that they're usually already built into whatever you're using to do communication.

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

#138
post #112

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.

"Rolling your own crypto" usually refers to constructing new cryptographic schemes out of either primitives or just out of wholecloth.

Using well-developed hashing schemes like pbkdf2 (which the auth snippet uses) or bcrypt (another good and common option) and storing the output is not rolling your own crypto. Writing your own hash function would be rolling your own crypto.

People talk about not rolling your own crypto because crypto is very, very sensitive to even very small errors, in ways that other code is not. Writing your own authentication using a well-known strong hashing scheme (which handles salting and verifying passwords in a timing attack resistant way) is much less likely to have vulnerabilities that aren't obvious.

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

#139

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…

> There's a race to replace JWTs with something better (PAST is an example) and while I don't think the underlying idea behind JWTs is any good either, even if you disagree, you should still wait for one of the better formats to gain acceptance.

Aside from PAST, I recently have come across this[0] (called branca) as I too was looking for an alternative to JWT. This seems to be based on Fernet, but according to the maintainer of this spec it isn't maintained anymore.

[0] https://github.com/tuupola/branca-spec

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

#140

Earlier quoted context omitted.

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

The downside to allowing multiple tokens is that in the real world, people will create new tokens for new deployment environments, but never delete the old ones, which will inevitably end up on Github somehow.

agreed, but its a solvable problem.

e.g. You can request a second token, but doing so immediately sets the currently active token to expire and be deleted in X days.

Post reply on HN