Web 客户端和移动 REST api 安全性的推荐配置

Posted 2023-03-08

【中文标题】Web 客户端和移动 REST api 安全性的推荐配置

【英文标题】：Recommended configuration for both web client and mobile REST api security

【发布时间】：2012-02-21 08:59:57

【问题描述】：

我意识到关于这个主题有很多问题，我已经研究了几天了。我想确保我的问题尽可能具体，因为我尚未完全了解最佳方法。

目前我有一个开发的 django 站点，Web 客户端可能通过 django-piston json REST api 进行大约 95% 的通信。另外 5% 是一些重新登录功能，仍然通过具有 CSRF 保护的 POST 表单。理想情况下，我想将其余部分也移动到 REST api 中。

我现在需要找出最好的推荐解决方案，以一种可重用且愉快共存的方式保护 Web 客户端和移动客户端（尚未开发的应用程序）。我已经阅读了许多最终为移动端推荐 OAuth2（和 https）的帖子，但我仍然对如何设置 Web 客户端安全性感到困惑。我也在理解 OAuth2 方面以及我是否可以使用 2-legged 形式。就目前而言，Web 客户端已通过 django 身份验证。从技术上讲，活塞中的 jsonp 功能仍然有效，所以我认为任何人都可以使用来自 3rd 方应用程序的 api，只要他们的网络会话具有身份验证 cookie？

我的api使用总结：

API 是服务器应用程序的完全私有接口 如果 API 不能被第 3 方 Web 客户端混搭广泛重用，那将是理想的选择。 数据不敏感。它只是一个社交类型的网站，其中包含最多的个人信息是基本的用户个人资料，例如电子邮件、地址等。

我的问题总结：

OAuth2 是保护移动应用程序访问的最佳推荐方法吗？它与网络客户端方面有什么关系吗？如果推荐使用 OAuth2，它是否应该是应用程序版本的应用程序范围的密钥？ Web 客户端是否应该使用通过 ajax 传递的 CSRF，并且只禁用 jsonp 以确保其始终同源？基本上，我是在单独对待 Web 客户端的安全性吗？ 我应该如何组织 url/应用程序实例/子域或任何推荐的东西来维护 Web 与移动安全？我是否只需要单独的 url 前缀，一个用于使用不同规则的移动设备？

我正在寻找 django-piston 解决这些问题的具体建议。我已经分支了我的项目并开始使用这个分叉版本的活塞：https://bitbucket.org/jespern/django-piston-oauth2

我的一个想法是创建一个活塞资源，首先检查其是否同源，然后仅强制执行 django 身份验证，否则强制执行 oauth2，但我不确定这是否合适。

2012 年 1 月 1 日更新

根据 Spike 提供的信息，我开始使用活塞 oauth2。我最终创建了一个 fork 来为 nonrel django (mongodb) 添加一些修复程序，并且我分叉了某人的示例以也使用 oauth2 和活塞：

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

现在我只需要把它与我自己的项目联系起来并让它发挥作用。但是这些测试都非常有效。

【问题讨论】：

现在this 是一个写得很好的问题！很高兴看到有人尝试。

谢谢！如果我知道它不是很详细并且以前被问过同样的方式，我真的尽量不问关于 SO 的问题。我在这里看到太多人只是随便丢两句话并要求大家解决那里的问题:-)

【参考方案1】：

我完全支持 OAuth2，所以我将根据该解决方案进行回复。

OAuth2 是保护移动应用的最佳推荐方法吗 使用权？它与网络客户端方面有什么关系吗？而如果 建议使用 OAuth2，如果它是应用程序范围的密钥 与应用版本一起发布版本？

是的，OAuth2 目前被广泛认为是推荐的方法。它比 OAuth1 容易得多。我建议实际上阅读the spec 而不是关于规范的博客文章，因为规范本身写得很清楚。除了规范之外，查看它的已建立实现（如 Facebook's 和 Foursquare's）很有用，因为它们并非在所有方面都遵循规范，但进行了一些修改以使其更实用和易于使用。

至于版本控制，从教条的 REST 角度来看，这是frowned upon。然而，从更实用的角度来看，这是非常普遍的做法，并且让 API 开发人员和客户的生活变得更加简单。我建议阅读 Apigee 博客，因为他们有很多关于 versioning 等主题的帖子。

Web 客户端是否应该使用通过 ajax 传递的 CSRF，并且只是 禁用 jsonp 以确保其始终相同的来源？基本上，我是 单独处理 Web 客户端安全性？

如果您使用完整的 oauth2 解决方案，则需要启用跨站点 api 请求。要拒绝您不知道的应用，您可以在查看传入的 access_tokens 时添加检查。以下是有关您拥有的不同选项的一些阅读：

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

我应该如何组织 urls/app 实例/子域或 有什么建议来维护网络与移动安全？难道我 只需要单独的 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

【讨论】：

好的，所以我将努力让 oauth2 适用于所有事情。如果是这样，那么我关于移动和网络的单独 url 端点的问题就没有必要了，因为它们的身份验证完全相同。我想我剩下的障碍是获得为 django/piston 工作的 oauth2 的适当解决方案。您到 oauth2app 的链接似乎是一个 oauth 应用程序，而不是一个独立的服务器。所以它将取代使用 django-pistin-oauth2 叉子做任何事情。我将不得不看看如何将它与活塞集成，因为我目前无法让活塞-oauth2 工作。我只是希望有一个特定的 tu。

酷。抱歉，我不清楚 oauth2app。你是对的，它不是一个独立的服务器。这是一个 django 应用程序，它为您的站点实现了 oauth2 服务器视图，它不与任何其他 3rd 方 django 应用程序绑定。

我想在接受这个之前稍等片刻，因为我一直在寻找更多活塞特定的信息，但从那时起我就搞砸了活塞-oauth2。查看我的更新以获取信息！