23

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.

brandonvvv
  • 253
  • 3
  • 6

4 Answers4

1

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.

Community
  • 1
  • 1
Daniel Cerecedo
  • 6,071
  • 4
  • 38
  • 51
1

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.

Phil Sturgeon
  • 30,637
  • 12
  • 78
  • 117
0

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

Santanu Dey
  • 2,900
  • 3
  • 24
  • 38
0

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

Community
  • 1
  • 1
jbowes
  • 4,062
  • 22
  • 38
  • What is the advantage of using OAuth? – brandonvvv Feb 14 '12 at 16:59
  • You won't have to write the authentication code yourself :) and it is well tested and trusted. With 2 legged OAuth you only need to share a single private key between your server and the api caller, and any snoopers won't be able to figure out what that key is (though you'll probably want to run the connection over SSL). – jbowes Feb 14 '12 at 17:09
  • OK. So the idea is process the login over the API using the user name and password and a signature using the private key, grant a token, and then for future calls use the token and signature for the remainder of the session? – brandonvvv Feb 14 '12 at 19:35
  • In your case, the private key could just be the users password. In the example at http://code.google.com/p/oauth-php/wiki/ConsumerHowTo#Two-legged_OAuth $key would be the user name, and $secret would be the password. – jbowes Feb 14 '12 at 19:42
  • So if I understand this correctly, in this scenario the username and password have to be submitted in every request? – brandonvvv Feb 14 '12 at 20:06
  • Yes, though the password isn't sent in plaintext; it's used to hash the request url. This is better than using basic auth, as with basic auth a third party can sniff the headers and request a different url using the same headers, whereas if they tried that with oauth headers, authentication on the server side would fail. – jbowes Feb 14 '12 at 20:11
  • 1
    But this means that I would have to store all usernames and passwords in plain text on the client server to use for signing – brandonvvv Feb 14 '12 at 20:33