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

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

#141

Post by scriptkiddy » Tue, Jan 16, 2018, 5:11 PM UTC

newscracker wrote: post #125

scriptkiddy wrote: post #109

Earlier quoted context omitted.

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.

Cert renewal can be automated the same way letsencrypt does it for instance.

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

#142

Post by jcadam » Tue, Jan 16, 2018, 5:12 PM UTC

fimdomeio wrote: post #49

barrystaes wrote: post #41

Do everything via HTTPS, disable HTTP. The login request (POST, dont use url query params) contains username + password. The API replies with a session token (a random string). You can store any metadata relating to this session token in your DB. The API client should this token in every request that requires authentication, often in the header as `Authorization : Bearer 123TheToken456`. JWT: If DB performance become…

I basically do this with jwt. In my case jwt just contains the basic data that the front needs to find out who the user is and what it can do (user uuid and role). While obviously checking if action is allowed to user is done server side it's normally useful for the front end to also be aware.

Yea, I happen to be using JWT in the simplest way. Authentication only.

I don't even store role information in them, since authorization checks are performed on the server anyway.

If the client needs to know what a user is allowed to do with a resource (so it knows not to display certain buttons, etc.) I have the client do an OPTIONS call (with the token) to see what methods are allowed.

Lately, I've been thinking about replacing the whole JWT scheme with simple bearer tokens stored in the database, mostly because it would make revocation simple and I can't think of anything I would lose by giving up JWTs (a little storage space in the database?), and I don't think switching the type of bearer token I'm working with will actually be very painful implementation-wise. You know what, I'm adding a task to my backlog...

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

#143

Post by tptacek » Tue, Jan 16, 2018, 5:15 PM UTC

jdc0589 wrote: post #140

tptacek wrote: post #133

Earlier quoted context omitted.

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.

Sorry, I made it sound like I think multiple tokens is an illegitimate choice. It's not; I just think, be aware of the tradeoffs and keep things as simple as they can possibly be.

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

#144

Post by oxymoron » Tue, Jan 16, 2018, 5:16 PM UTC

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 security reason to stop doing so?

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

#145

Post by stephengillie » Tue, Jan 16, 2018, 5:17 PM UTC

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 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 pointless and useless unless you already knew SQL.

Then, there are articles like the Hackernoon post explaining why most Passport blog posts are wrong in one way or another.[0] This article explains that there are no "copy/paste" authentication solutions for Javascript, as there are for other languages - and Passport is probably the best out there.

As there's no "copy/paste" auth solution for Javascript, it becomes essential to understand how auth works with your site. It has to be added to every Express render call, to work with the Session. And rolling your own is educational - you can learn some of the common pitfalls and why rolling your own is a bad idea.

I do plan to go back to Passport sometime this year. The number of Oauth providers is nearly overwhelming - too much to ignore. But also daunting for the first-time student.

[0] https://hackernoon.com/your-node-js-authentication-tutorial-...

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

#146

Post by iopuy » Tue, Jan 16, 2018, 5:28 PM UTC

tptacek wrote: post #131

dboreham wrote: post #129

Earlier quoted context omitted.

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.

Is it not true that Basic Authentication requires TLS due to transporting credentials as plain text but other variations encrypt the credentials at a higher level before being put on the wire? In that case why is TLS a necessity?

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

#147

Post by bb88 » Tue, Jan 16, 2018, 5:39 PM UTC

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…

Only if the long_secret was made public.

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

#148

Post by riquito » Tue, Jan 16, 2018, 5:42 PM UTC

iopuy wrote: post #146

tptacek wrote: post #131

Earlier quoted context omitted.

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

Is it not true that Basic Authentication requires TLS due to transporting credentials as plain text but other variations encrypt the credentials at a higher level before being put on the wire? In that case why is TLS a necessity?

It's necessary because otherwise the encrypted credentials could be copied and used to access the service.

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

#149

Post by Blazespinnaker » Tue, Jan 16, 2018, 5:42 PM UTC

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…

Signed REST requests are good too, more secure. And what’s wrong with delegated auth?

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

#150

Post by MichaelGG » Tue, Jan 16, 2018, 5:44 PM UTC

matwood wrote: post #110

kbutler wrote: post #73

Earlier quoted context omitted.

Yes, it does. If you want to be completely stateless, you need to send the authorization info on each request, probably as basic auth headers. This is actually simpler than implementing the Bearer token, for both client and server, but requires that the client retain the non-expiring username and password, rather than retaining the expiring, session-specific Bearer token.

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

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.