CODEWITHSUNDEEP
apiauthenticationrestoauth-2.0
brandonvvv
brandonvvv

Reputation: 253

Security for "Private" REST API

I am currently developing a web application that is right now comprised of a front end which displays and interacts with the data using a REST API we have written. The only thing that will ever use the API is our front end website, and at some point a mobile app that we will develop.

I have done a lot of reading about how OAuth is the ideal mechanism for securing an API and at this point I am starting to have a good understanding of how it works.

My question is -- since I am never granting access to my API to a third-party client, is OAuth really necessary? Is there any reason it is advantageous? Furthermore, because the back end is simply the API, there is no gateway for a user to authenticate from (like if you were writing an app using the Twitter API, when a user authenticates they would be directed to the Twitter page to grant to access then redirected back to the client).

I am not really sure which direction to go in. It seems like there must be some approach halfway between http authentication and OAuth that would be appropriate for this situation but I'm just not getting it.

Upvotes: 23

Views: 9245

Answers (4)

Phil Sturgeon
Phil Sturgeon

Reputation: 30766

OAuth 2.0 originally seems like a PITA if you think about having to build a lot of it yourself, but most languages have some really solid OAuth 2.0 setups which you can just bolt in with varying amounts of fiddling. If you're using a framework like Laravel or RoR then it's barely any work.

If you don't want to redirect users as suggested in your post then ignore other comments and answers that talk about two legged flows. You can use the client_credentials grant type to have apps just provide their client id and secret in return for an access token, which is nice and easy.

I would ask how private are we talking, because if the only systems talking to it are within the backend and have no interaction with the outside world you could probably leave it wide open and just rely on the network to keep it safe (VPN/Firewall).

But if it's private in the sense of "our iPhone app uses it" then you definitely want to go with OAuth 2.0, or something like it.

Upvotes: 1

Daniel Cerecedo
Daniel Cerecedo

Reputation: 6207

From my point of view, one of the scenarios that favor OAuth over other options is to work with untrusted clients, no matter if these are developed by you or a third party.

What's an untrusted client? Think from the point of who handles the credentials that grant access to your API.

  • For example, your web application could interact with your API in two falvors:
  1. Your web app server side talks to your API. Your web app server is a trusted client because the credentials to access your API can only be access by whom have access to the server...You and your team. You could authenticate your web app server with a client_id and a client_secret.
  2. You may want to make calls directly to your API from your Web app client, which runs on the end user's browser using JavaScript. The end user's browser is an untrusted client. If you were to deliver the credentials to your API down to the browser, anyone could check the JavaScript code and steal your credentials.

  • A third party Native App is also untrusted. A malicious developer that uses your API could save the credentials of and end user of your platform.

  • Your Native App is a trusted client and could manage the authentication with a simple username , password and a client id identifying your App.

How can OAuth help? OAuth Authorization code and Implicit grants can help you with this issue. These flows only work with clients that support a redirect, like a browser. And let you authenticate an untrusted client and a user against your Authorization Server to gain access to your Resource Server, your API, without exposing the credentials. Take a look at the RFC to see how it is done.

The good thing of OAuth is that it not only supports these redirect based authentication flows, but it also supports client credentials grant and user credentials grant. So an OAuth Authorization Server would cover all cases.

Upvotes: 1

Santanu Dey
Santanu Dey

Reputation: 2978

You should use Oauth for mobile device to API layer communication.

However, there is no benefit of Oauth in this web UI layer to middle-layer access (machine to machine).

On the other hand there are some potential issues

  1. Managing the access token expiry becomes a pain. Consider that your UI has to cache the access token across multiple nodes in a cluster. Refresh it when expired, and the fact that UI layer is negotiating security with backend will just take extra time once in a while.

  2. In two legged Oauth (OAuth Client Credential as in v2.0) does not support any encryption. So you still need to send key and secret both to the server for getting an access token.

  3. Backend has to implement issuing access token, refresh token, validating access token etc, without any significant benefit

Upvotes: 0

jbowes
jbowes

Reputation: 4150

2 legged OAuth is probably what you want to use. It's basically hashing a shared key, but you have the advantage of not having to write the code yourself.

Here's a related question: Two-legged OAuth - looking for information

Upvotes: 0

Related Questions