Recommended configuration for both web client and mobile REST api security

Question

I realize there are a ton of questions on this subject, and I have been researching this for a couple days now. I want to make sure my question is as specific as possible since I have yet to gain a full understanding of the best approach.

Currently I have a developed django site, with the web client communicating probably about 95% via a django-piston json REST api. The other 5% is some remaning login functionality that still goes through POST forms with CSRF protection. Ideally I would like to move the remainder also into the REST api.

I am at the point now where I need to figure out the best recommended solution for securing both the web client and the mobile client (app yet to be developed) in a reusable and happily co-existing fashion. I have read many posts ultimately recommending OAuth2 (and https) for the mobile side, but I am still confused about how to go about setting up the web client security. I am also grasping at understanding the OAuth2 aspect and whether I can use the 2-legged form. As it stands, the web client is django authenticated. Technically the jsonp functionality is still active in piston, so I would think anyone could use the api from a 3rd party app as long as their web session has the auth cookies?

Summary of the usage of my api:

1. The API is a completely private interface to the server app
2. It would be ideal if the API could not be widely reused by 3rd party web client mashups.
3. The data is not necc sensitive. Its just a social-type site with the most personal information being the basic user profile stuff like emails, addresses, etc.

Summary of my questions:

1. Is OAuth2 the best recommended approach to securing the mobile apps access? Does it have anything to do with the web client aspect? And if OAuth2 is recommended, should it be an application-wide key that is versioned with the app releases?
2. Should the web client use CSRF that is passed over ajax, and just disable jsonp to ensure its always same origin? Basically, am I treating the web client security separately?
3. How should I go about organizing the urls/app instances/subdomains or whatever is recommended to maintain the web vs mobile security? Do I just need separate url prefixes, one for mobile that uses different rules?

I am looking for django-piston specific recommendations to solving these problems. I have already branched my project and started to play with this forked version of piston: https://bitbucket.org/jespern/django-piston-oauth2

One idea I had was to create a piston resource that first checks if its same-origin and then only enforces the django auth, otherwise it enforces oauth2, but I am not sure if this is even appropriate.

Update 1/1/2012

From the info that Spike provided, I started working with piston-oauth2. I ended up creating a fork of that to add some fixes for nonrel django (mongodb) and I forked someones example to also use oauth2 and piston:

https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example

Now its just a matter of me really hooking this up to my own project and getting that working. But these tests all work great.

Repeater

Now this is a well-written question! Nice to see some people try. – Unmeriting

Thanks! I really try not to ask a question on SO if I know its not well detailed and been asked the same way before. I see way too many people on here just casually dropping 2 sentences and asking everyone to solve there problems :-) – Repeater

Answer 1

I'm all for OAuth2, so I'll reply based on that solution.

Is OAuth2 the best recommended approach to securing the mobile apps access? Does it have anything to do with the web client aspect? And if OAuth2 is recommended, should it be an application-wide key that is versioned with the app releases?

Yes, OAuth2 widely regarded as the recommended approach at the moment. It's far easier than OAuth1. I'd recommend actually reading the spec instead of blog posts about the spec as the spec itself is very clearly written. Beyond the spec, it's useful to look at established implementations of it like Facebook's and Foursquare's since they don't follow the spec in every way, but make some modifications to be more practical and easy to use.

As for versioning the releases, from a dogmatic REST perspective this is frowned upon. However, from a more pragmatic perspective, this is extremely common practice and makes life much simpler for both the API developers and the clients. I'd recommend reading the Apigee blog, as they have lots of posts about topics like versioning.

Should the web client use CSRF that is passed over ajax, and just disable jsonp to ensure its always same origin? Basically, am I treating the web client security separately?

If you go with a full oauth2 solution, you'll want to enable cross-site api requests. To deny apps you don't know, you can just add checks for that when you look at the access_tokens being passed in. Here's some reading about the different options you have:

http://blog.apigee.com/detail/crossing_the_streams_handling_cross-site_api_requests/

How should I go about organizing the urls/app instances/subdomains or whatever is recommended to maintain the web vs mobile security? Do I just need separate url prefixes, one for mobile that uses different rules?

Just decide what works for you. Lots of people have their mobile site at "m.mysite.com" or "mobile.mysite.com" these days. This decision isn't really related to the whole authentication discussion if you go with a full OAuth2 implementation.

I am looking for django-piston specific recommendations to solving these problems. I have already branched my project and started to play with this forked version of piston: https://bitbucket.org/jespern/django-piston-oauth2

I'm not familiar with this, as I use tastypie. If it doesn't work well for you, there is an excellent Django OAuth2 standalone server that I've used:

https://github.com/hiidef/oauth2app

Childish

Ok, so I will work towards just making oauth2 work for everything. If thats the case, then my question about separate url endpoints for mobile and web wouldn't be necessary as their auth is exactly the same. I suppose my remaining hurdle is getting a proper solution of oauth2 working for django/piston. Your link to oauth2app seems to be an oauth app and not necc a standalone server. So it would replace doing anything using the django-pistin-oauth2 fork. I will have to see how to integrate it with piston, as I currently cant get piston-oauth2 working. I just wish there was a specific tut. – Repeater

Cool. Sorry, I wasn't clear about oauth2app. You're right in that it's not a standalone server. It's a django app that implements the oauth2 server views for your site, and it isn't tied to any other 3rd party django apps. – Childish

I wanted to wait a bit before accepting this, since I was looking for some more piston specific info, but since then I have messed with piston-oauth2. See my updates for info! – Repeater