Ask HN: Rest api authorization

#1

Post by vskr » Sat, Oct 15, 2016, 8:51 PM UTC

I am working on service which exposes REST API.

What is the best way to implement authorization for incoming requests.

* Identify who is making the request. Can we use api key for this.

* Make sure this REST api can be used just as easily using curl. I am not sure how to do this, as I dn't think exposing API key is a good idea. I can ask clients to hash request params with api key, but that makes it non-trivial to use with curl.

What are the standard practices, and what are the trade offs.

Please be kind and helpful. If I said anything wrong, please correct me instead of flagging this.

Any help would be appreciated. Glad to provide any info that makes it useful to answer

Re: Ask HN: Rest api authorization

#2

Post by quickben » Sat, Oct 15, 2016, 9:40 PM UTC

Look into identity server 4. YouTube some videos about it and it should get you going. The rest is just picking what's popular for your platform/language.

Re: Ask HN: Rest api authorization

#3

Post by diggernaut » Sat, Oct 15, 2016, 9:50 PM UTC

you can (and should :)) use it (token auth) with ssl. To get SSL is not a problem today, and will cost you nothing if you use letsencrypt.org

Re: Ask HN: Rest api authorization

#4

Post by atmosx » Sat, Oct 15, 2016, 9:59 PM UTC

HMAC for auth to avoid having the key exposed at every request.

For the rest: http://www.javabeat.net/rest-api-best-practices/

And documentation: https://github.com/Rebilly/ReDoc/blob/master/README.md

There many more comprehensive resources about sane API design (use HATEOAS, pagination, etc.) but you don't have to implement everything from v1

ps. SSL goes without saying even if it's a public API

Re: Ask HN: Rest api authorization

#5

Post by RandomOpinion » Sat, Oct 15, 2016, 10:51 PM UTC

I've seen people use JWT (https://jwt.io/introduction/) for REST API auth. There are a variety of libraries that implement it and it's fairly simple to use.

Since it's just another HTTP header field, cURL can include it easily enough. Granted, you'll have to generate the encoded token externally but you would have had to do that with any other auth mechanism anyway.

Re: Ask HN: Rest api authorization

#6

Post by weitzj » Sun, Oct 16, 2016, 12:29 AM UTC

Be aware of JWT when it comes to Login/Logout behavior. JWT is not a good fit for user facing login unless you have a session ID on the server. But then you could as well use Cookies and a sessionID.

So I would do a Login via Basic Auth or a Form post or a JSON post with username/password and then get some kind of token/sessionID/JWT which expires on the server side. The token might be encrypted on the server side with a secret only known to the server, never the client. Use the sessionStore to implement a proper session expiration scheme.

Re: Ask HN: Rest api authorization

#7

Post by johnjuuljensen » Sun, Oct 16, 2016, 12:32 AM UTC

Use basic authentication and ssl. The users credentials will be encrypted and the API will be easily consumable from cli and from browsers.

Re: Ask HN: Rest api authorization

#8

Post by nickmancol » Sun, Oct 16, 2016, 1:15 AM UTC

Maybe you can take a look of an api gateway like apiman which can leverage the auth & authz to keycloak, or perhaps kong may be the one.

Re: Ask HN: Rest api authorization

#9

Post by rashkov » Sun, Oct 16, 2016, 1:53 AM UTC

I really wish this topic got discussed more because there don't seem to be a lot of great options.

I personally use an OAuth 2 library using the "Resource Owner Password Credentials Grant" which is where you POST a username and password, and you get back a session token. OAuth 2 has a few other types of grant flows but they don't make as much sense for REST only APIs.

The downside of this password grant flow is that anyone can create a client to work against your API, and potentially they can steal passwords in a man-in-the-middle fashion. One way to prevent this is to give your "trusted clients" a secret token, and then verify that token before issuing a session.

However you can't hide a secret in browser-side JavaScript and even mobile apps can be be decompiled, so this isn't perfect either. Some devices provide a hardware enclave to store your secrets in, but most don't.

Another weakness is that if your SSL breaks, then you're essentially sending the passwords in clear text over the wire. Another commenter mentioned HMAC encryption of the password which might help. That this isn't recommended by oauth is concerning. It's not the best standard and password grant is its weakest form. [Edit: now that I think about it, HMAC requires having another shared secret between your API and your client. Storing secrets on the client is difficult, as discussed in the previous paragraph]

JWT seems new and not too widely used but worth looking into. It has its own downsides like some difficulty with revoking sessions from the server side, but there are workarounds for this.

I wish there was an industry standard answer that was secure and we could all be happy with but there doesn't seem to be much interest in the topic, going by how rarely it gets discussed. Best of luck!

Re: Ask HN: Rest api authorization

#10

Post by jaypaulynice » Sun, Oct 16, 2016, 2:32 AM UTC

OAuth2 is the way to go for REST services especially if you plan to let users give other apps/developers access without giving out their passwords. For better security, you want to decouple the authentication server from your web application (2 separate databases at least)

The authentication server stores email/username, encrypted password, and roles. To access the web app, you first get a token from the authentication server by exchanging a client_id, secret, username, password and grant type. The token is used whenever you want to make a request to the web app. The authentication server has an endpoint that lets the web app check to see if the token is valid and what roles the client has.

The token is only valid for a short time and can be revoked. To know who is making the request, you associate the username/email from the authentication server with a user object on the web application so you can look up based on username/email.

It's not worth doing this from scratch as there are plenty of open source implementations out there already like Spring Security Oauth2 and other libraries for Django/python, but they all require some reading to get started.

I've used Spring Security Oauth2, but it's not very well documented. I've thought about open sourcing my work, but not sure yet.