Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Rest api authorization

news.ycombinator.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Ask HN: Rest api authorization

#11

Post by rashkov »

rashkov wrote: post #9

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…

By the way, you may want to have a look at Auth0. They run the jwt.io informational site. Their services look interesting. Their claim is that you can use their service and their SDKs to add authentication to your service super easily.

Re: Ask HN: Rest api authorization

#12

Post by aprdm »

jaypaulynice wrote: post #10

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 authenticati…

Isn't having two distinct servers one for auth and one for business logic too much for small start ups / services?

I can see the benefit when scaling but starting with this design seems to be a little bit of an overkill / harder to manage? Care to elaborate?

Cheers

Re: Ask HN: Rest api authorization

#13

Post by aprdm »

I've used mostly JWT, the tokens with a short TTL which makes it easier to control revoking/banning in the backend.

It is really simple to set up. In the frontend it's pretty straight forward to implement logout and other common behaviors even if the token is still valid because of the TTL.

Re: Ask HN: Rest api authorization

#15

Post by atmosx »

rashkov wrote: post #11
rashkov wrote: post #9

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…

By the way, you may want to have a look at Auth0. They run the jwt.io informational site. Their services look interesting. Their claim is that you can use their service and their SDKs to add authentication to your service super easily.

JWT looks very interesting, thanks for bringing this up.

JWT website: https://jwt.io/introduction/

Re: Ask HN: Rest api authorization

#17

Post by jaypaulynice »

aprdm wrote: post #12
jaypaulynice wrote: post #10

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 authenticati…

Isn't having two distinct servers one for auth and one for business logic too much for small start ups / services? I can see the benefit when scaling but starting with this design seems to be a little bit of an overkill / harder to manage? Care to elaborate? Cheers

For a quick prototype, I think it's ok to have both in same server/database, but beyond a prototype you should think about security and scaling. Redesigning later can be a nightmare and most people end up not doing it instead just leaving what they already have.

The good thing with 2 separate servers is that if one is compromised, then the bad actor doesn't get access to all your data. Also you could use any language/database that makes sense for your auth server or services.

Re: Ask HN: Rest api authorization

#19

Post by tom_b »

I have semi-copied what AWS did a couple of years ago. Each api consumer has an api key with a private key known to the consumer and server-side. Requests are SSL only and are signed with the private key by the consumer side (including any parameters and a client-side timestamp). For example, using curl:

  #!/bin/bash

  TS=$(date +"%s000")

  SIG=$(echo -ne 'GET\nhttps://servername:port/api/resources?api_id=1&ts='$TS | openssl dgst -sha256 -hmac "secret-key" -binary | xxd -p -c 32)

  curl -H "Content-type: application/vnd.collection+json" 'https://servername:port/api/resources?api_id=1&ts='$TS'&signature='$SIG
I have consumers of the api using node.js and Java as app dev languages with various http client libraries successfully. The actual server-side api is written with Clojure using the Liberator library (highly enjoyed working with this combo).

Server-side uses the api_id to check the signature using the shared secretkey. (Edit to clarify). There are two timestamps flying around here. One is a timestamp from the client call to the api ($TS above). This timestamp has to be "close" - completely configurable on server-side - to the server-side time or the request is not valid. A little more subtle is that each resource has a timestamp that is the last time the resource was changed server-side. As part of the authorization for the api call to change a resource, it has to be make the call to the api with the resource's most current value for that timestamp to succeed. This is a little goofy logically.

This approach works very well when you have a requirement to allow multiple different apps to call the api rather than say, allowing users to call the api from their browser. I don't have a case where users are in a web browser app that directly calls the REST api.

By the way, if you are using SSL, you don't have to worry about the api_id being exposed in either the query parameters or the request headers.

Post reply on HN