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

[Jenson]

Folks,

I posted this to StackOverflow a few days ago. I'm hoping someone
over here can provide some insight.

http://stackoverflow.com/questions/9368548/is-oauth-good-choice-for-restful-api-in-this-saas-scenario

Begin past from original Stackoverflow post:

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.

[Jeff Schmidt]

Jenson:

It sounds like you're doing something similar to me. :) Our
application does not have any user specific content, nor does it need
to access any. What we do have is our own content, and tenant
specific content. The tenant applications are consumers of our
service, and we issue them OAuth 2 client credentials. The tenant
application uses these credentials to acquire OAuth (bearer) access
tokens. These tokens are then conveyed to clients by the tenant
application for use in directly accessing our API. This is all done
over HTTPS.

Our product also includes a number of embed-able "widgets",
implemented in JavaScript and Flash. The APIs support both XML and
JSON, but JSONP (cross-domain) is used by the widgets to invoke our
API. Ajax is restricted to the origin server, which is the Tenant web
application. Embedding a widget entails providing it the access token
acquired above. As the widget invokes the API, it must provide the
token, which gets validated, and it also identifies the tenant what
issued the token. That way we know just what tenant specific content
to access, as well as who to bill. :) The API is accessed over HTTPS
protecting the bearer token from being unknowingly hijacked.

Given the widgets etc., we're initially looking at browser based
clients. In the mobile case, the tenant application will have to do
something similar and provide some way to authenticate to their site,
and then provide the token to the device. Our service is always
accessed on behalf of a tenant. The direct site offering of our own is
just another tenant.

I'm still interested in what people may think about my other thread
"API security conundrum" (https://groups.google.com/group/api-craft/
browse_thread/thread/8bf3a2ab9a22048f). Depending on the nature of
your content this may not concern you, but if you want to keep some
data-sucking program at bay, how can you affect token acquisition
performed by a tenant, w/o burdening the tenant? I have measures in
place to look for excessive use and demand captcha, invalidate a token
prematurely and whatnot, but if another token can be obtained easily,
then I'm not putting up much of a fight...

Cheers,

Jeff

On Feb 22, 9:47 am, Jenson <justinhrobb...@gmail.com> wrote:
> Folks,
>
> I posted this to StackOverflow a few days ago.  I'm hoping someone
> over here can provide some insight.
>

> http://stackoverflow.com/questions/9368548/is-oauth-good-choice-for-r...

[Greg Brail]

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.

I'm sure there are more but those are the ones that I can think of right now.

--
Gregory Brail  |  Technology  |  Apigee

[Jack Repenning]

On Feb 22, 2012, at 8:47 AM, Jenson wrote:

> 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?

The point of OAuth is not exactly "sharing," though that can be a subset of it.

The primary point of OAuth is extending limited subsets of your rights with a first entity to some other entity. The "rights" might be the right to see data, or to change data, or to execute code, or pretty much anything else you might think of. The "other entity" might be another site that wants these rights in order to serve as a proxy for the user (the parade example), or some subsystem on your same site, such as a periodic maintenance task. The key notion is to identify some subset of rights and capabilities, and some entity or context in which these (and no other) rights/capabilities should be granted, repeatedly, without human involvement (such as repeatedly typing a password).

So, in the parade example:
1. You might have a Twitter account, which includes rights like "send tweets," "read tweets," "edit the profile," and "subscribe to other tweeples." Twitter is the first entity.
2. You might find a site that does something useful, like OpenTable making dinner reservations for you.
3. The second site (OpenTable) might ask for your permission to tweet from your account every time you use the service.
4. Assuming you agree, you, OpenTable, and Twitter perform the OAuth dance, and in the end Twitter is willing to accept tweets from OpenTable as if they came from you, conceivably even if you don't happen to be at any keyboard at all at the moment OpenTable sends the tweet (though I don't think OpenTable actually exercises that particular right).

A secondary use of OAuth is for "Single Sign On": the first entity knows how to confirm the person at the keyboard really is you. The second entity wants such assurance as well. The "right" in this case might only be "the right to be recognized as yourself," or basically no rights at all (so far as the first entity is concerned). The three of you execute the OAuth protocol, and if the first entity grants the protocol, then it has demonstrated that it's satisfied as to your identity; the second entity merely trusts the successful OAuth transaction as proof of identity.

Commonly, you find the two uses combined: when you first register with the second entity (OpenTable, to continue the above example), it offers you the option of using your Twitter account for login at OpenTable. Upon completion of the "allow OpenTable to tweet" protocol, OpenTable also has the SSO assurance. OpenTable sets up various structures of its own, such as profile info, dining history, and so on -- stuff Twitter knows nothing of -- and secures it behind the Twitter-certified identity "you."

If you only have one access point (say, one log-in page), then I don't think OAuth buys you anything. But if you deploy multiple web apps off the same database, each with its own login page, and if there's any chance that some users might use several in the same day, then OAuthing among the apps might still get you the SSO benefit.

Jack Repenning

[Jenson]

Many thanks for the detailed replies. I'll need to let this sink in a
bit before moving forward...

[Ed Anuff]

Just to add my 2 cents, a lot of people are looking at OAuth through the lense of OAuth1, which was very much focused on solving the "allow third-party app to access my personal social networking site data" use case, but OAuth2 is a lot more than that.  OAuth2 does a very good job of representing just about every common use cases of passing credentials to API's and for people starting green field with a new API implementation, I tend to point them to the latest draft of the OAuth2 spec and suggest that finding one of the flows that match their use case may be the best starting point.  I would make this suggestion for either the classic OAuth 3-legged third-party access scenario or for machine-to-machine 2-legged scenarios.  It's just plain easier on the developer using your API not to have to learn one more vendor-specific access key mechanism.

Ed

[chuck clark]

We've been considering OAuth for a project as well and initially we
weren't sure it was a fit largely because of the "lens of OAuth1"
mentioned.

InfoQ has a good video of a lecture on OAuth posted at:
http://www.infoq.com/presentations/The-Rise-of-OAuth which I think
helps frame OAuth1 vs OAuth2 quite well. The second half does focus
on SpringSocial but I think the first half is very good overview for
someone new to OAuth. The only question now is when OAuth2 will be
made final.

We had a similar situation to Jenson where we have multiple web
applications in a larger SaaS product suite. It is possible a user
may not even know they have multiple accounts so the usual OAuth dance
of being referred to site where the user holds the "master" account in
order to link the applications seemed a little odd. But once we
started to look at the machine-to-machine 2-legged scenarios it made
more sense and we're now in the process of planning to have OAuth as
an option for securing all of our API calls for the very reason that
down the road there may be third parties using some of these APIs and
it will be easy to expose it to them.

thanks,
chuck

[Peter Rexer]

We've had an Oauth1-like mechanism in place for going on 6 years now.   It doesn't make a lot of sense to me to implement OAuth1 with OAuth2 coming out soon.  

I'd love to hear when it's going to go final as well.  

-Peter

[Sam Ramji]

OAuth 1.0 also has major security holes which have been discovered since its release, partially patched with OAuth 1.0a (http://oauth.net/core/1.0a/)

It doesn't make any sense at this point to start a new OAuth service based on 1.0.  As Greg Brail often says, grab the latest draft of 2.0 and go!

Cheers,

Sam

[Peter Monks]

I'm very keen to hear this too, although perhaps rather than focusing on "when", it might make sense to also ask "what's still in a state of flux in OAuth2"?  It doesn't help clarify the timeframes necessarily, but it at least gives draft implementers a chance to ponder which parts are most likely to change between now and ratification.

Cheers,
(another) Peter

[Jesse Emery]

Re-reading the OP, if the API clients are browsers and mobile apps then you pretty much have to use OAuth2 or roll your own thing (yes, yes, not strictly true, but practically speaking you don't want to try do 1.0a from mobile OS or Javascript).

As an aside and just my 2c, but I would strongly recommend not waiting around on the final OAuth2 spec. For one thing, it's in "last call,"  but more importantly, you don't have to implement the whole spec, just the flow you need and the essentials of the flows and security model aren't changing at this point. 

If you're really curious about what parts changed in the last draft, just look at the diff:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt

Jesse

[Andrew Kuklewicz]

I would agree with this - 

We have an older API we did between server apps using two-legged OAuth 1.0a, which is pretty similar to how AWS API security is done, and works well enough, but is nothing to write home about.

Having lived with it for awhile, I would say it is fine for internal, server to server APIs, but OAuth2 offers lots of good options for apps and for external folks to use, and if you go it alone, you will just end up reinventing some or all of it (poorly).  You really don't want to distribute keys in mobile app, that code will get ogled, and OAuth2 helps solve that in a variety of ways.

There are also already some pretty good impls for OAuth2 consumers and providers for most languages, not least b/c some big players have adopted it (google, facebook), so I don't think you need to wait for it to get through final approval.

Andrew Kuklewicz

[Greg Brail]

Reading the tea leaves in the spec mailing list (and unfortunately I don't have time to keep up as well as I'd like):

• The core protocol -- the various ways to issue tokens -- is pretty stable. There is a lot of IETF procedure left before it's "final" but I would be surprised if that part changed. Keep in mind that the core protocol spec in 2.0 doesn't say anything about the actual authentication token, however, and OAuth 2.0 doesn't actually do anything without some sort of token on each request...
• "Bearer tokens" are also pretty stable and the spec is so simple that there aren't too many ways for it to change. (OTOH, the mailing list just spent weeks arguing about exactly what characters should be allowed in a bearer token and how to represent that decision in IETF-spec-language.)
• "Mac tokens" (the equivalent of OAuth 1.0a tokens where the key and secret are signed on each reuest and SSL is not required) are pretty immature at this point and I wouldn't bet the farm on them until that spec gets a bit more mature.