15

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.

j0k
  • 22,600
  • 28
  • 79
  • 90
Justin
  • 6,031
  • 11
  • 48
  • 82
  • 1
    "context of authorizing.." Thats three-legged OAuth. There is also two-legged oauth, which is what you may need. – Jesvin Jose Feb 22 '12 at 07:44

4 Answers4

8

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.

Greg Brail
  • 96
  • 1
3

Yes, this is a very good fit for OAuth. You can still use HTTP Basic over SSL during the handshake for authentication. The output of the OAuth handshake will be a token which can then be used to consume the API. This way, the application does not need to store the credentials and tokens can easily be revokes with minimal user impact.

OAuth 2.0 defines a number of different grant types for accommodating different situations. It sounds to me like the 'implicit' or the 'resource owner password credentials' are the most appropriate but you may want to consider each carefully.

You should not implement this directly in your API but use infrastructure to delegate the OAuth support and token management on behalf of your SaaS API instead.

Take a look at

http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/

and

http://www.layer7tech.com/products/oauth-toolkit

Hope this help,

-fl

Francois Lascelles
  • 26
  • 2
1

I implemented an OAuth for Django nonrel with piston to expose my APIs to consumer. There are a number of kind in OAuth(2-legs 3legs).

Generally, supporting OAuth is quite a bit challenge. You have to obtain the request token, authorize it, store the access token to sign every request you want to authenticate.

Advantages
- You don't have to send username and password everytime, secure.
- Enable third party to consume your app.
Disadvantages
- Make 2,3 round trips to authenticate.
- Complicated to implement it by yourself.

I'm pretty sure that you can find a number of library that allow you to:
- Expose your Api and support OAuth. E.g Django piston.
- Sign your requests by adding headers to them. E.g Oauth-signpost.

Cuong Thai
  • 1,165
  • 1
  • 11
  • 24
0

OAuth is only a token and the requesting App will issue one. You can read more in pingidentity.com where there are several webinars on this topic(cloud identity and user provisioning) as well.

kishorekumar neelamegam
  • 1