CODEWITHSUNDEEP
apirest
Akinkunle Allen
Akinkunle Allen

Reputation: 1309

Securing REST API that will be accessed by diffrent clients

I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.

Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?

Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?

I hope my question is clear. Thanks for the help.

Upvotes: 0

Views: 1075

Answers (1)

scrowler
scrowler

Reputation: 24425

From what I understood in reading this there are two parts to your question:

What is the best authentication method for my API?

I recently developed an authentication system for an API that was modelled on OAuth but didn't have every single one of their specifications. The system was basically the same as what Amazon use for their API. [This article]1 is very helpful if you want a secure API authentication model without having to use OAuth.

The model uses these principles:

  • Authentication data will be passed with every request to the API server
  • Requests will include a Unix timestamp from when it was generated
  • The entire request (including the timestamp) will have an HMAC hash generated and sent alongside the rest of the data. The hash is generated using a private key that only the API server and the API client know.
  • The API takes the data (including the timestamp), generates an HMAC hash using the private key for that user (identified by a user ID, user name, public API key, whatever) and compares it to the hash sent with the request. If this was successful, regular authentication proceeds and the request is processed. Note: the API will check the timestamp and compare it to its own to make sure the request has occured within a valid timeframe of, for example, 30 seconds, 5 minutes, 10 minutes, etc.

Of course, you can use regular HTTP authentication over SSL/HTTPS also, but I find this way to be very good because you achieve a high level of security without needing to implement every aspect of the OAuth protocol.

How you authenticate is up to you essentially. I prefer to go with methods employed by large, trustworthy organisations (such as Amazon). I personally didn't want to go the whole hog with OAuth like Twitter, Facebook etc.

How should I allow different users to access different endpoints in my API?

You should have an internal map in your API server which contains records allowing or denying specific API accounts from accessing certain endpoints. In my API server I decided that all endpoints would be "allow" by default, and I would specify which accounts would not be able to access certain endpoints.

You could also set up different groups or types of API access accounts which could have group permissions like this.

My suggestion would be to [read this article]2 twice, or three times, then read it again. Then, implement the methods suggested within.

Personally, I think the best method for ensuring as much security as possible is to restrict absolutely everything in regards to the request to be within a set of boundaries that you define, e.g. I want this endpoint to only be accessible by GET HTTP requests (all other HTTP methods will throw an error), up to 3 times daily per account, within a 30 second timeframe of request to server, only allow a narrow range of data to be returned, etc.

Limiting the HTTP method is very important to reduce the risk of your API doing things it shouldn't, especially with a RESTful API as endpoints can be used to do multiple things depending on the request method. You can even set your permissions for each API account to restrict certain methods on each endpoint, e.g. API user xxx can GET information from an endpoint but cannot POST, PUT, PATCH etc, or API user xxx2 can POST data but cannot GET any, etc.

[EDIT] 1 and 2: www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ (not completely removing the link but keeping the url unlinked as it no longer works/redirects to random sites)

Upvotes: 2

Related Questions