Live data from Hacker News

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

news.ycombinator.com

21–30 of 254 posts

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

#21
post #14

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. i.e. we need to run software on a clients machine, and it has to authenticate to our web api to send us data. We obviously don't want to hard code the credentials in the software as that can be t…

Ideally you use some kind of time-limited API tokens, and find a way to automatically distributed new API tokens, before the old ones expire.

That way, the breach of a single device doesn't immediately give the attacker unlimited access to the API.

You should also monitor for unusual activity, and blacklist API keys and devices with such activity.

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

#22
post #14

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. i.e. we need to run software on a clients machine, and it has to authenticate to our web api to send us data. We obviously don't want to hard code the credentials in the software as that can be t…

Could it be a possibility to generate a keypair on the machine and then attempt to register itself to your webserver supplying client-name, IP and public-key. Then you would be able to see and OK any attempts to connect. Once you've OK'ed it, it would be able to authenticate and communicate normally as an authenticated device.

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

#23
Depending on your usecase, a quick setup would be to use https://auth0.com/ They have a lot of documentation and samples to get started.

We have implemented it for authentication with a Asp.Net Core webservice, with a REST based API. Authorization is also possible, either by working with the JWT token scopes, or using the Auth0 app_metadata.

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

#25
post #14

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. i.e. we need to run software on a clients machine, and it has to authenticate to our web api to send us data. We obviously don't want to hard code the credentials in the software as that can be t…

Can't store password on device (it's a device we don't control)

Can you expand on this? Because storing a device-specific password (or api key, which is essentially the same) would be my first suggestion.

If it's because you can't configure the device, then my suggestion would be to create a process that embeds the device key into the software before deploying to each particular device.

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

#26
post #3
post #2

For users or applications within your own network?

What would you recommend for both?

For applications using a HMAC token with some sort of timestamp which can be checked for replay attacks. AWS has a good guide: https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthenti....

For users, I'd add a OAuth layer to the application layer and still have this application using a HMAC like above. You want to try keep things 'stateless' when it comes to your API's.

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

#27
post #14

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. i.e. we need to run software on a clients machine, and it has to authenticate to our web api to send us data. We obviously don't want to hard code the credentials in the software as that can be t…

> Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated.

Am I missing something, or have you painted a contradiction?

* You want the device to hold some secret

* You want the device to be able to prove that it holds the secret

* You don't trust the device to hold a secret

If I'm understanding this correctly, then you've left the realm of cryptography and entered the realm of obfuscation.

Edit

This isn't necessarily a losing battle, but it changes the way we need to think about the problem.

Games consoles and DRM'ed video media (Blu-Ray and HDCP) do something similar in not trusting the end-user: they want to hold the key to the kingdom whilst ensuring the user never sees it. They've done this with varying levels of success.

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

#29
post #19
post #9

I’d say it depends a lot. If your API just serves public non-user-specific data, a simple API key might be okay. The obvious downside of this method is that a user leaking their client API key is a big problem, especially if your users are likely to distribute code that makes requests (e.g. a mobile app that makes requests to your API). The state of the art is probably still OAuth, where clients regularly request ses…

One thing to be aware of with OAuth 2.0 is Refresh Tokens. If the spec is followed, the Refresh Tokens are long-lived and never expire (the spec makes a suggestion that you revoke used tokens, but it's not required), so if they are leaked you are in for a bad time. There's an RFC that goes into some of the security considerations of OAuth 2.0, that should be required reading if you implement it (even from a pre-built…

If the Refresh Tokens are leaked, you revoke them and the user has to re-authenticate.

It's crucial that clients are able to respond to their refresh tokens being revoked.

The good thing is that it is a standard workflow, contrary to API key being revoked, which is generally not handled (most people hard-code API key in their client).

Post reply on HN