Live data from Hacker News

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

news.ycombinator.com

81–90 of 254 posts

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

#81
post #70

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

For public services, getting users to have keys and install them in their browsers is quite hard. For APIs, it should be more manageable but many places stumble with key management and a lot of developers were resistant to learning enough about the tooling to do things like manage test instances.

I guess regarding the public services your statement may be correct. But I wonder if anyone (any significant content provider) actually tried. The technology is available for > 10 years at least (including browsers support). I think it's an issue for most people that they need to manage multiple passwords and it sometimes turns off people from actually using the service. With client certificates you install certificate once and (given enough support from web developers) forget about passwords "forever".

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

#82

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

Because SSL certificates are a hassle to use on the client side, and possibly cumbersome to generate. I used client certificates in a few projects, and while the idea sounds perfect, it's hard to implement, and at least I don't understand it thoroughly.

A username and a password is so much simpler.

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

#83

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…

Is this "go code this yourself" advice, or just what to look for from pre-existing tools? In my world there are middlewares that accomplish exactly this, it never occurred to me to code this myself, lest I screw it up.

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

#84
post #76

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…

What is your reasoning for not using query params for the login request? I know it's probably more RESTful to use POST, but otherwise if you're using HTTPS for everything, query params are just as encrypted as the POST body. Or is there another reason?

GET requests just do not make sense for actions: they are cacheable and replayable. An http client/a proxy/something on the backend can cache it and avoid going to the actual logic.

Also, mixing credentials into URL does not feel like a good separation of concerns, e.g. URLs are often logged and analyzed in separate logging/monitoring/analytic tools, so there is a bigger risk to have credentials leaked over some side-channel.

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

#85
post #76

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…

What is your reasoning for not using query params for the login request? I know it's probably more RESTful to use POST, but otherwise if you're using HTTPS for everything, query params are just as encrypted as the POST body. Or is there another reason?

Query params in the URL are encrypted for transmission, but not elsewhere: http://blog.httpwatch.com/2009/02/20/how-secure-are-query-st...

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

#86
post #70

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

For public services, getting users to have keys and install them in their browsers is quite hard. For APIs, it should be more manageable but many places stumble with key management and a lot of developers were resistant to learning enough about the tooling to do things like manage test instances.

One of the reasons it is hard is that most error reporting on certificate authentication is horrendously bad and there are a lot of ways it can go wrong. Dates can be wrong, the CN field can be wrong, the server or client might not agree on the quality of the ciphers, user can install the cert in the wrong place or with the wrong options, etc... If any of this goes wrong all you get is a "cannot connect to website" error and maybe if you're super lucky an error in the web server log like "certificate failure". For security reasons they never tell you what the actual problem is and just assume that the user must have a PHD in cybersecurity because they're trying to do crypto on a computer, so it should be no problem for them to check the thousand different possible failure points in the system.

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

#87
post #58

Earlier quoted context omitted.

> Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly. You can solve this with a token/user blacklist. There are desirable (and undesirable) characteristics of using a blacklist instead of a whitelist, but you don't lose this capability.

How do you share your blacklist across servers

The same way you share any of your other data across servers. Save it in a DB or Redis instance that all your servers can reach.

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

#88

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

SSL client authentication usually winds up authenticating physical devices similarly to SSH keys, but there is near zero infrastructure simplifying/protecting/distributing a single software certificate for an individual user (especially non-technical users!) across multiple devices -- and this is really complicated by mobile devices. (Enrolling a new cert on every machine is an exponential management nightmare.)

SSL client authentication is widely used by the US military on smartcards requiring additional hardware readers: https://en.wikipedia.org/wiki/Common_Access_Card. AFAIK using a smartcard doesn't work reliably on Mac without installing 3rd-party software. The difficulties of usage in practice has spawned a cottage industry of commercial software and support, like http://militarycac.com.

I assume companies selling end user hardware tokens like YubiKey would love to see client certificate authentication become more usable, but initiatives like FIDO U2F seem to be gaining momentum instead.

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

#89
post #69
post #63

Earlier quoted context omitted.

I have found the above (sans JWT) to be the simplest, secure method. Do everything over HTTPS, use basic auth or post for the user/pass and return an expiring token, use that token as a Bearer token for all subsequent requests.

I’m mostley a FE person at the moment so forgive me for my ignorance but how does the server use the token passed to the client to do auth? Does it keep a copy somewhere and check against it on every request?

> Does it keep a copy somewhere and check against it on every request?

Yes. The last time I did this we checked the X-Token header on every request, if it didn't exist or there were multiple we replied 401. If only one was there we checked a DB table of active tokens, if it wasn't there or had expired we replied 401. If it was there but wasn't associated with a role that had access to the requested resource, we replied 403. If it was not expired and had access we continued with the request.

As soon as you get away from "check authentication on every request" your attack vectors increase. As a bad actor, I no longer need to bypass your authentication, I just need to bypass whatever system you have in place to decide whether or not to authenticate me. That's generally going to be easier.

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

#90

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

I have worked with systems that use it to authenticate machine to machine communication (e.g. a web backend authenticating itself to another service doing work for it). In that environment it works well.

Using it to authenticate a person regardless of device doesn't work so well from a usability point of view.

Post reply on HN