Рекомендуемая конфигурация для безопасности web-клиента и mobile REST api
Я понимаю, что есть тонна вопросов по этому вопросу, и я изучал это в течение нескольких дней. Я хочу убедиться, что мой вопрос является как можно более конкретным, поскольку мне еще предстоит получить полное представление о лучшем подходе.
В настоящее время у меня есть разработанный сайт django, с веб-клиентом, общающимся, вероятно, около 95% через api JSON REST django-piston. Другие 5% - это некоторые функции повторного входа в систему, которые все еще проходят через почтовые формы с CSRF защита. В идеале я хотел бы переместить остаток также в REST api.
теперь я нахожусь в точке, где мне нужно выяснить лучшее рекомендуемое решение для обеспечения безопасности как веб-клиента, так и мобильного клиента (приложение еще не разработано) многоразовым и счастливым сосуществованием. Я прочитал много сообщений, в конечном итоге рекомендующих OAuth2 (и https) для мобильной стороны, но я все еще смущен тем, как настроить безопасность веб-клиента. Я также хватаюсь за понимание аспекта OAuth2 и могу ли я использовать двуногую форму. В настоящее время веб-клиент аутентифицирован django. Технически функциональность jsonp по-прежнему активна в piston, поэтому я думаю, что любой может использовать api из стороннего приложения, пока их веб-сессия имеет куки-файлы auth?
резюме использования моего api:
- API является полностью частным интерфейсом для серверного приложения
- было бы идеально, если API, не может быть широко использовано в 3-й партии веб-клиент коллажи.
- данные не necc чувствительной. Это просто сайт социального типа с самой личной информацией, являющейся основным профилем пользователя, таким как электронные письма, адреса и т. д.
резюме моих вопросов:
- является ли OAuth2 лучшим рекомендуемым подходом к обеспечению доступа к мобильным приложениям? Имеет ли это какое-либо отношение к аспекту веб-клиента? И если OAuth2-это рекомендуется, должен ли это быть ключ для всего приложения, который версируется с выпусками приложений?
- должен ли веб-клиент использовать CSRF, который передается через ajax, и просто отключить jsonp, чтобы обеспечить его всегда одинаковый источник? В принципе, я рассматриваю безопасность веб-клиента отдельно?
- как мне организовать URL-адреса/экземпляры приложений / поддомены или что-то еще, что рекомендуется для поддержания веб-безопасности vs mobile? Мне просто нужны отдельные префиксы url, один для мобильного телефона, который использует другие правила?
Я ищу конкретные рекомендации django-piston для решения этих проблем. Я уже разветвил свой проект и начал играть с этой раздвоенной версией piston:https://bitbucket.org/jespern/django-piston-oauth2
одна идея, которую я имел, заключалась в создании ресурса поршня, который сначала проверяет, является ли его то же происхождение, а затем только применяет аутентификацию django, иначе он применяет oauth2, но я не уверен, что это даже соответствующий.
обновление 1/1/2012
из информации, которую предоставил Спайк, я начал работать с piston-oauth2. Я закончил тем, что создал вилку, чтобы добавить некоторые исправления для nonrel django (mongodb), и я раздвоил чей-то пример, чтобы также использовать oauth2 и piston:
https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example
теперь это просто вопрос меня действительно подключить это к моему собственному проекту и заставить это работать. Но все эти тесты отлично работают.
1 ответов
Я все за OAuth2, поэтому я отвечу на основе этого решения.
является ли OAuth2 лучшим рекомендуемым подходом к обеспечению безопасности мобильных приложений доступ? Имеет ли это какое-либо отношение к аспекту веб-клиента? И если OAuth2 рекомендуется, если это ключ для всего приложения, который версия с выпусками приложений?
да, OAuth2 широко рассматривается как рекомендуемый подход на данный момент. Это намного проще, чем OAuth1. Я бы рекомендовал читать спец вместо сообщений в блоге о спецификации, поскольку сама спецификация очень четко написана. Помимо спецификации, полезно посмотреть на установленные реализации it, такие как Facebook это!--8--> и Foursquare поскольку они не следуют спецификации во всех отношениях, но делают некоторые изменения более практичными и простыми в использовании.
Что касается версий релизов, с догматической точки зрения отдыха это неодобрением. Тем не менее, с более прагматичная перспектива, это чрезвычайно распространенная практика и делает жизнь намного проще как для разработчиков API, так и для клиентов. Я бы рекомендовал прочитать блог Apigee, так как у них много сообщений о таких темах, как версионность.
должен ли веб-клиент использовать CSRF, который передается через ajax, и просто отключить jsonp, чтобы обеспечить его всегда одинаковое происхождение? В принципе, я рассмотрение безопасности веб-клиента отдельно?
Если вы идете с полное решение oauth2, вы захотите включить межсайтовые запросы api. Чтобы запретить приложения вы не знаете, вы можете просто добавить проверку на то, что когда вы смотрите на маркеры доступа в. Вот некоторые чтения о различных вариантах у вас есть:
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, который я использовал: