Web客户端和移动REST api安全性的推荐配置 [英] Recommended configuration for both web client and mobile REST api security
问题描述
目前我有一个开发的django网站，通过django-piston json REST api，网络客户端可能传达约95％的信息。另外5％是一些提醒登录功能，仍然通过CSRF保护的POST表单。理想情况下，我想将其余部分也转移到REST api中。
我现在正处在这一点，我需要找出最佳的解决方案来确保网路客户端和移动客户端（应用程序尚未开发）以可重复使用和愉快共存的方式。我已经阅读了很多帖子，最终为移动端推荐了OAuth2（和https），但我仍然对如何设置Web客户端安全性感到困惑。我也在理解OAuth2方面，以及我是否可以使用双腿形式。就这样，Web客户端被django认证。从技术上来说，jsonp的功能在活塞中仍然很活跃，所以我认为任何人都可以使用来自第三方应用程序的api，只要他们的网络会话具有auth cookie？
我的api的使用摘要：
- API是一个完全私有的服务器应用程序接口， li>
- 如果API不能被第三方网络客户端混搭广泛使用，这将是理想的。
- 数据不是非敏感的。它只是一个社交型网站，最个人的信息是基本的用户个人资料，如电子邮件，地址等。
我的问题摘要
- OAuth2是确保移动应用访问的最佳推荐方法吗？它与Web客户端方面有什么关系吗？如果建议使用OAuth2，应该是应用程序版本的应用程序范围的密钥吗？
- 如果Web客户端使用通过ajax传递的CSRF，并且只能禁用jsonp确保其始终相同的起源？基本上，我是否单独处理网络客户端安全？
- 我应该如何组织URL /应用程序实例/子域名或建议哪些维护Web与移动安全性？我只需要单独的网址前缀，一个用于使用不同规则的手机？
我正在寻找django-活动的具体建议来解决这些问题。我已经分支了我的项目，并开始玩这个分叉版的活塞： https：// bitbucket .org / jespern / django-piston-oauth2
一个想法是创建一个活塞资源，首先检查它是否相同，然后只有强制执行django auth，否则强制执行oauth2，但是我不确定这是否适合。
更新1/1/2012
从Spike提供的信息中，我开始使用活塞oauth2 。我最终创建了一个fork，为nonrel django（mongodb）添加了一些修补程序，我分叉了一些例子也使用oauth2和活塞：
https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example
现在只是一个问题，我真的把这个挂在我自己的项目上，让它工作。但是这些测试都很棒。
我都是OAuth2，所以我会根据这个解决方案回复。 / p>
OAuth2是保护移动应用程序
访问的最佳推荐方法吗？它与Web客户端方面有什么关系吗？如果推荐
OAuth2，应该是一个应用程序范围的密钥，这是一个
版本的应用程序版本？
是的，OAuth2目前被广泛认为是推荐的方法。这比OAuth1容易得多。我建议您实际阅读规格而不是博客文章关于规范本身就是非常明确的规范。除了规范之外，查看已建立的实施方式，如 Facebook的和 Foursquare的，因为他们不遵守规范，但做一些修改更实际和容易要使用。
对于版本控制版本，从教条式的REST角度来看，这是皱眉。然而，从更实际的角度来看，这是非常常见的做法，使API开发人员和客户端的生活变得更加简单。我建议您阅读Apigee博客，因为他们有大量关于版本控制的主题的帖子。
如果Web客户端使用通过ajax传递的CSRF，并且只需
禁用jsonp以确保其始终相同的来源？基本上，我是
分别处理网络客户端的安全吗？
如果你使用一个完整的oauth2解决方案，你会想要启用跨站点api请求。要拒绝您不知道的应用程序，您可以在查看正在传入的access_tokens时添加检查。以下是有关您所拥有的不同选项的一些说明：
http://blog.apigee.com/detail/crossing_the_streams_handling_cross-site_api_requests/
我应该如何组织URL /应用程序实例/子域或
无论建议维护网络与移动安全？我要
只需要单独的url前缀，一个用于使用不同的
规则的移动设备。
只是决定什么为你工作这些天，很多人的移动网站都在m.mysite.com或mobile.mysite.com。如果您使用完整的OAuth2实现，此决定与整个身份验证讨论并不真正相关。
我正在寻找django-piston具体建议解决
这些问题。我已经分支了我的项目，并开始使用这个分支活塞的
：
https://bitbucket.org/jespern/django-piston-oauth2
我不太熟悉这样，当我使用 tastypie 时。如果它不适合你，有一个优秀的Django OAuth2独立服务器，我已经使用：
https://github.com/hiidef/oauth2app
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:
- The API is a completely private interface to the server app
- It would be ideal if the API could not be widely reused by 3rd party web client mashups.
- 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:
- 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?
- 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?
- 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.
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
这篇关于Web客户端和移动REST api安全性的推荐配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
