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

201–210 of 254 posts

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

#201

Post by tptacek »

hungerstrike wrote: post #200
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…

I can’t fathom what the problem could be when using private key encryption to create stateless tokens. I do this to create bearer tokens without JWT. Anyway, you can find a lot of his comments about JWT by searching ‘tctapek JWT site: ycombinator.com’

In the box at the bottom of the page, just type "author:tptacek jwt" (make sure you switch to "comments" mode).

HN search is much more efficient than Google for this.

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

#202

Post by san_at_weblegit »

There is no single good answer to this question without taking into account the security consideration of the API in question and the consumers. On a high level all solutions work just fine as long as we understand the tradeoff's involved (cpu, IO, revocation, complexity,..). The different solutions that could be tried with ease are: 1. Network filtering - If the API consumers can be limited by identifying their IP addresses 2. Bearer tokens - Simple random string that can be passed in the header (depending on number of consumers, ability to revoke/change tokens it can become little complex) 3. JWT's - Similar to bearer tokens without the ability of revocation and extra cost of key management and CPU (the signature verifications are quite costly). 4. OAuth - Better call it 2-legged OAuth since its between servers only. Its the ideal one with both revocation possibility and signature verification.

The first three could be implemented easily inhouse and are suited when number of consumers are small. Its better to use some third party SAAS service or OAuth server for the fourth one. I work professionally on these things and these implementations can be time consuming. More than often people dont take into account their requirements when choosing a solution.

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

#203

Post by u801e »

acdha wrote: post #199
u801e wrote: post #191

Earlier quoted context omitted.

> Wait for the email to arrive and follow the retrieval process to get the certificate Is there a reason why the server couldn't send the certificate back to the browser via HTTPS? > You then need a non-trivial amount of work to export the private key and certificate and install it on all of your devices, Would it not be better to just use a different key for each device? That is, repeat steps 1 and 2 for every devic…

> > Wait for the email to arrive and follow the retrieval process to get the certificate > Is there a reason why the server couldn't send the certificate back to the browser via HTTPS? The public implementations are generally trying to verify current ownership of the specified email address. That's part of why I wish this could be linked to a third-party which already does that so users don't have to repeat the proce…

> The public implementations are generally trying to verify current ownership of the specified email address.

Are there any implementations that don't? For example, when I create an account on news.ycombinator.com, does it really need to verify my email address, rather than using a signed message sent via HTTPS during the sign up process?

> Consider e.g. all of the sites which trust Google or Facebook to authenticate users and imagine what it'd be like if that could be extended so you could ask that trusted third-party which keys correspond to a verified email address.

Perhaps we need to rethink using email for verification. For server side authentication, we have certificate authorities to handle verification of a given server's identity. In your example, Google or Facebook (or both) could serve as certificate authorities for the client certificate used for a given website.

Again, I would say that most websites do not (or should not) need my email address in order for me to sign up for an account. My web browser should be able to manage verifying my identity with a website as well as adding other trusted web browsers.

> That last point underscores how much of this has nothing to do with PKI and everything to do with horrible UI: the failure mode for not having a valid certificate is generally horrible

Unfortunately, that is very true. It would be nice if some serious effort could be directed to improve the process. I think that if we were using certificate authentication, as opposed to password based, it would be much harder for people's accounts to be compromised, even through "social engineering".

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

#204

Post by tboyd47 »

jmulho wrote: post #158
tboyd47 wrote: post #94

Authentication is such a mess, I don't even know where to begin. Most APIs rely on some sort of token-based auth, communicated via the header format: "Authorization: Bearer abc123", as opposed to placing it in the Cookie, as most web sites will do. Many solutions exist, like OAuth2, JWT, etc. but that's ultimately what it all boils down to.

Is there any reason to favor bearer tokens over cookies?

If you use a cookie for an API, it will look like you don't know what you are doing. Also, there are extra rules around Cookies (expiration, length, etc.) that may bite you if you use them outside a browser context.

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

#205

Post by beckler »

013a wrote: post #182
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 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.

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

#206

Post by webster23 »

alex_duf wrote: post #40
jpalomaki wrote: post #37

Why not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries. I would consider more complicated solutions only if you first come to conclusion that these simple things are not fit for the purpose. True that some fancy token based solution may reduce database load, but if the API is doing something useful then that one primary key lookup and potentiall…

I would agree, always start simple - unless you manipulate sensitive data - a shared secret is a good place to start (api-key or basic/digest auth) You can always introduce other forms of authentication later. I have a slight preference for basic/digest auth as the secret isn't part of the URL, and therefore not cached/logged by any network equipment.

The api-key does not need to be part of the URL, you can also put it in the Authorization header.

edit: typo

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

#207

Post by MichaelGG »

matwood wrote: post #153
MichaelGG wrote: post #150

Earlier quoted context omitted.

How so? The client needs to have the username and password to call the login function over and over, as well as managing the session token. It's just incredibly annoying with no benefits in nearly every scenario.

The client should not store the user/pass [1]. If the token expires, the user needs to provide a user/pass to login in again. The user should also be forced to provide a user/pass in order to change the password - something that cannot be enforced if keeping the user/pass on the client. You also lose any method to force a re-authentication. With a token, I could expire with no activity for an hour and allow it to be…

What is the client? OP says API which sounds more machine to machine. If you mean the API powering a site, used from the client's browser, then sure. Track separate logins, then give them a control panel to see where they're logged in.

But most clients store their user/pass in their browser anyways so I'm not sure it's a security win for preventing credential loss.

You don't lose re-auth. The master system issuing API keys can revoke keys, too.

But anyways maybe we're talking about different contexts because I don't understand the scenario you're describing.

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

#208

Post by MichaelGG »

tptacek wrote: post #184
zaroth wrote: post #179

Earlier quoted context omitted.

I would say, store the hash of the token in the database, but that's my personal preference to add a bit of defense against timing attacks, insider stealing the token, or token database breach.

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, nothing is possible. We don't even need to tell people to rotate keys. With plain keys, we'd need to freeze usage for people without e.g. IP address restrictions in place.

Read-only leaks happen all the time. Why not make sure they don't impact your clients API usage?

I'm not just trying to fight. It's a handful of trivially-validated lines of code that significantly mitigate the impact of a data leak. Seems like a super easy tradeoff.

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

#209

Post by matwood »

MichaelGG wrote: post #207
matwood wrote: post #153

Earlier quoted context omitted.

The client should not store the user/pass [1]. If the token expires, the user needs to provide a user/pass to login in again. The user should also be forced to provide a user/pass in order to change the password - something that cannot be enforced if keeping the user/pass on the client. You also lose any method to force a re-authentication. With a token, I could expire with no activity for an hour and allow it to be…

What is the client? OP says API which sounds more machine to machine. If you mean the API powering a site, used from the client's browser, then sure. Track separate logins, then give them a control panel to see where they're logged in. But most clients store their user/pass in their browser anyways so I'm not sure it's a security win for preventing credential loss. You don't lose re-auth. The master system issuing AP…

I see. I read "Rest API" as securing the server portion with no implication that it meant only server to server. Cheers!

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

#210

Post by infogulch »

rapind wrote: post #197
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…

It's very possible I completely misunderstood your suggestion, however in case I didn't. If you're storing the key on the client (cookie or w/e) and in the database and solely using it to authenticate, aren't you going to run into timing attacks if you're using it for retrieval? What I typically do is also store a unique identifier like email for the lookup and then use a random key for comparison / validation.

Yeah could the DB token lookup timings by itself be used to find a real token? It might be several layers deep and DBs are noisy, but I think it's still possible in theory. Could you get around this by only storing some hash of both the token and a DB secret?
Post reply on HN