我意识到关于这个主题有很多问题，我已经研究了几天了。我想确保我的问题尽可能具体，因为我还没有完全理解最佳方法。
目前我有一个开发的 django 网站，Web 客户端大约 95% 是通过 django-piston json REST api 进行通信的。另外 5% 是一些剩余的登录功能，仍然通过带有 CSRF 保护的 POST 表单。理想情况下，我想将其余部分也移至 REST api 中。
我现在需要找出最佳推荐的解决方案，以可重用且愉快共存的方式保护 Web 客户端和移动客户端（尚未开发的应用程序）。我读过很多文章，最终推荐 OAuth2（和 https）用于移动端，但我仍然对如何设置 Web 客户端安全性感到困惑。我也在努力理解 OAuth2 方面以及我是否可以使用 2 足形式。目前，Web 客户端已通过 django 身份验证。从技术上讲，jsonp 功能在活塞中仍然处于活动状态，所以我认为任何人都可以使用来自第 3 方应用程序的 api，只要他们的网络会话具有身份验证 cookie？
我的 API 的使用摘要：
- 该 API 是服务器应用程序的完全私有接口。
- 如果该 API 不能被第 3 方 Web 客户端混搭广泛重用，那将是理想的选择。
- 数据不敏感。它只是一个社交类型的网站，其中最个人化的信息是基本的用户个人资料，例如电子邮件、地址等。
我的问题摘要：
- OAuth2 是保护移动应用程序访问的最佳推荐方法吗？它与网络客户端方面有什么关系吗？如果建议使用 OAuth2，它是否应该是与应用程序版本一起进行版本控制的应用程序范围密钥？
- Web 客户端是否应该使用通过 ajax 传递的 CSRF，并禁用 jsonp 以确保其始终相同的来源？基本上，我是否单独对待 Web 客户端安全？
- 我应该如何组织 url/应用程序实例/子域或任何建议维护网络与移动安全的内容？我是否只需要单独的 URL 前缀（用于使用不同规则的移动设备）？
我正在寻找 django-piston 的具体建议来解决这些问题。我已经对我的项目进行了分支，并开始使用这个分叉版本的活塞：https://bitbucket。 org/jespern/django-piston-oauth2
我的一个想法是创建一个活塞资源，首先检查其是否同源，然后只强制执行 django 身份验证，否则它强制执行 oauth2，但我不确定这是否合适。
2012 年 1 月 1 日更新
根据 Spike 提供的信息，我开始使用piston-oauth2。我最终创建了一个分支来为非相关 django (mongodb) 添加一些修复，并且我分支了某人的示例来也使用 oauth2 和piston:
https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example
现在，我只需将其真正连接到我自己的项目并使其正常工作即可。但这些测试都效果很好。
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.
发布评论
评论（1）
我完全支持 OAuth2，所以我会根据该解决方案进行回复。
是的，OAuth2 目前被广泛认为是推荐的方法。它比 OAuth1 容易得多。我建议实际阅读规范而不是关于规范的博客文章，因为规范本身写得非常清楚。除了规范之外，查看它的既定实现也很有用，例如 Facebook 的 和 Foursquare 的，因为他们并没有在所有方面都遵循规范，但做了一些修改以使其更实用并且易于使用。
至于版本控制，从教条式的 REST 角度来看，这是令人不悦的。然而，从更务实的角度来看，这是极其常见的做法，并且使 API 开发人员和客户的生活变得更加简单。我建议阅读 Apigee 博客，因为他们有很多关于版本控制等主题的帖子。
如果您使用完整的 oauth2 解决方案，您将需要启用跨站点 api 请求。要拒绝您不知道的应用程序，您只需在查看传入的 access_tokens 时添加检查即可。以下是有关您拥有的不同选项的一些阅读内容：
http://blog.apigee.com/detail/crossing_the_streams_handling_cross-site_api_requests/
只需决定什么对您有用即可。如今，许多人的移动网站位于“m.mysite.com”或“mobile.mysite.com”。如果您采用完整的 OAuth2 实现，则此决定与整个身份验证讨论并不真正相关。
我是对此不熟悉，因为我使用 美味。如果它不适合您，我使用过一个出色的 Django OAuth2 独立服务器：
https: //github.com/hiidef/oauth2app
I'm all for OAuth2, so I'll reply based on that solution.
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.
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/
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'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