Is OAuth good choice for RESTful API in this SaaS scenario?

Question

Is OAuth sensible to use when the user account info (user id's, passwords, roles, etc) is going to be maintained in our own back-end and when there will not be any sharing of resources with other sites? Or is sharing the whole point of using OAuth?

Background:

I'm working on developing an enterprise SaaS product and we are creating a RESTful API to be used by our front-end applications. Consumers of the API will be browser and native smartphone (iOS & Android) applications that we develop. Since we'll be supporting multiple client types, it makes sense to create a RESTful API that all our client apps can consume.

Naturally we need to secure this RESTful API. We are considering authenticating using HTTPS / Basic Auth but we are aware of some of the well known drawbacks to this approach.

Some quick research shows OAuth is highly recommended. But most of what I find with OAuth is in the context of authorizing web sites to share information on behalf of the user.

Any info if most welcome.

Answer 1

Good question, and we're having a good discussion on this over at API Craft:

https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00

Here's the answer that I posted there:

I think this is a good use case for OAuth, actually.

First of all, with OAuth your mobile app can store an OAuth token on the client rather than the user's "real" password. So, you can have the app automatically "log the user in" by getting an OAuth token without having to store the actual password on the device. If the user loses the device or if it's compromised somehow they (or you) can wipe the OAuth token without requiring that the user change the password and blow away other things that they might be doing with your API. There are similar examples for an Ajax-style web app but it depends more on the specific way that you build the client.

Second, the OAuth token is associated with a unique key that identifies the app that is making the API call, and that in turn identifies which developer built the app. That gives you options like tracking usage by application, turning off an application that might have been compromised without disabling the whole API, and if you ever want to open access to third parties or partners who build apps for your API, you can offer different levels of service to other customers.

Third, your IT security people will be happy if you tell them that you never store a password on the user's mobile device or stash it somewhere in their browser.

Fourth, you have the option of browser-based login for the mobile app. That means that the mobile app will never see the user's password, and also that if you want to implement two-factor security or something like that, you can do it in the login screen without changing the mobile apps. Now, the downside is that the user sees a browser window pop up. That's why OAuth gives you a few different ways to get an access token for an app, so you can choose whether you need to have browser-based login or have the user enter their password directly in the app.

Fifth, how do you know that your API will only ever be used by your own apps? If you use OAuth now then you will have an easier time making that transition later.