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

71–80 of 254 posts

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

#71

Post by imtringued »

fyfy18 wrote: post #19
baddox wrote: 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…

What's the appeal of tokens that never expire? You cannot delete the revokations after the token has expired.

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

#72

Post by jpalomaki »

matwood wrote: post #63
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 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.

On the client side that adds some complexity. You either do always two requests (first get token, then use it) or need to manage the storing the token and doing the renewals. If there are bursts of traffic and multiple threads/processes you need to think if each one will get their own token or if others will wait while one is getting a fresh token.

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

#73

Post by kbutler »

sethgecko wrote: post #56
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…

Doesn't a session token violate the stateless principle ?

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.

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

#74

Post by mattbroekhuis »

iEchoic wrote: post #58
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…

> 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

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

#75

Post by brabel »

mattmanser wrote: post #47
baddox wrote: 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…

Can you explain why only "public non-user-specific data" is suitable for basic auth over HTTPS? For most SasS products, basic auth or an API key is going to be fine. In fact, a ton of SasS vendors do exactly that. It's also totally fine for, say, an enterprise API used by a partner or clients. Oauth is a cluster-fuck of terribleness, a nightmare for you to work with and a nightmare for your consumers to use. If you d…

The OAuth use case you mention is spot on but with OAuth clients available in every language remotely popular I don't agree it's complicated. And I think that even if you don't have a strong user case for OAuth you will sooner or later. Better to go with the standard practice for user centric APIs instead of using ad hoc solutions.

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

#76

Post by pivotal »

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…

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?

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

#77

Post by pfg »

matwood wrote: post #63
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 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.

It's generally a good idea to avoid JWT. There are a lot of foot-guns in JWT, and many implementations have gotten it wrong in the past. This[1] is a good summary on the topic.

[1]: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

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

#78

Post by sk5t »

pivotal wrote: post #76
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…

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?

For one, the query string is much more likely to be logged, compared to the entity body. Think: httpd access logs, browser history, misconfigured caches / correctly configured caches subject to inappropriate cache directives, etc.

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

#79

Post by Pigo »

Just wanted to throw Azure API Management out there https://azure.microsoft.com/en-us/services/api-management

If you happen to be using Azure. I found it very useful for everything you'd want to do with your API, one of them being able to tie down security as much or as little as you need. It even builds a front end for anyone who has access to use for reference. But that's just one of the cool features.

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

#80

Post by cdaven »

sethgecko wrote: post #56
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…

Doesn't a session token violate the stateless principle ?

Yes, if you mean a token that identifies a session that is saved on the server somehow. But not a JWT, which is only saved on the client and verified on the server.
Post reply on HN