Рекомендуемая конфигурация для безопасности веб-клиента и мобильного REST API. - PullRequest
9 голосов
/ 29 января 2012

Я понимаю, что есть множество вопросов на эту тему, и я изучаю это уже пару дней.Я хочу убедиться, что мой вопрос настолько конкретен, насколько это возможно, так как я еще не получил полного понимания наилучшего подхода.

В настоящее время у меня есть разработанный сайт django, с веб-клиентом, который общается примерно на 95% черезДжанго-поршневой JSON REST API.Остальные 5% - это некоторые постоянные функции входа в систему, которые все еще проходят через формы POST с защитой CSRF.В идеале я хотел бы перенести остаток также в REST API.

Сейчас я нахожусь в точке, где мне нужно найти наилучшее рекомендуемое решение для защиты как веб-клиента, так и мобильного клиента (приложение еще небыть разработанным) многократно и счастливо сосуществующим способом.Я прочитал много постов, в которых, в конечном счете, рекомендую OAuth2 (и https) для мобильных устройств, но я все еще не уверен, как настроить безопасность веб-клиента.Я также понимаю, что такое аспект OAuth2, и могу ли я использовать двухногую форму.В настоящее время веб-клиент проходит проверку подлинности django.Технически, функция jsonp все еще активна в поршне, поэтому я думаю, что любой может использовать API из стороннего приложения, если их веб-сессия имеет куки-файлы аутентификации?

Сводка использования моегоapi:

  1. API - это полностью закрытый интерфейс для серверного приложения.
  2. Было бы идеально, если бы API не мог широко использоваться сторонними веб-клиентами.
  3. Данные не являются конфиденциальными.Это просто сайт социального типа, где самая личная информация является основным профилем пользователя, таким как электронные письма, адреса и т. Д.

Резюме моих вопросов:

  1. Является ли OAuth2 лучшим рекомендуемым подходом к обеспечению безопасности доступа к мобильным приложениям?Это как-то связано с аспектом веб-клиента?И если рекомендуется OAuth2, должен ли он быть ключом всего приложения, который версионируется вместе с выпусками приложения?
  2. Должен ли веб-клиент использовать CSRF, передаваемый через ajax, и просто отключить jsonp, чтобы обеспечить его всегда одинаковое происхождение?В основном, я рассматриваю безопасность веб-клиента отдельно?
  3. Как мне организовать организацию URL-адресов / экземпляров / поддоменов приложений или что-то еще, что рекомендуется для обеспечения безопасности веб-сайтов и безопасности мобильных устройств?Нужны ли мне отдельные префиксы url, один для мобильного, который использует другие правила?

Я ищу конкретные рекомендации для решения этих проблем.Я уже разветвил свой проект и начал играть с этой разветвленной версией поршня: https://bitbucket.org/jespern/django-piston-oauth2

Одна из моих идей состояла в том, чтобы создать ресурс поршня, который сначала проверяет, имеет ли он тот же источник, а затем толькопринудительно применяет аутентификацию django, в противном случае - oauth2, но я не уверен, что это даже уместно.

Обновление 1/1/2012

По информации, предоставленной Спайком, я начал работать с pneon-oauth2.Я закончил тем, что создал форк этого, чтобы добавить некоторые исправления для nonrel django (mongodb), и я раздумал кое-кого, чтобы также использовать oauth2 и поршень:

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

Теперь это просто вопрося действительно подключил это к моему собственному проекту и заставил это работать.Но все эти тесты работают отлично.

1 Ответ

4 голосов
/ 29 января 2012

Я все за OAuth2, поэтому я отвечу на основе этого решения.

Является ли OAuth2 лучшим рекомендуемым подходом к защите мобильных приложений? доступ? Это как-то связано с аспектом веб-клиента? И если Рекомендуется OAuth2, если это ключ всего приложения, который версии с выпусками приложения?

Да, OAuth2 широко считается рекомендуемым подходом на данный момент. Это намного проще, чем OAuth1. Я бы рекомендовал читать спецификацию вместо сообщений в блоге о спецификации, так как сама спецификация написана очень четко. Помимо спецификации, полезно взглянуть на установленные реализации, такие как Facebook и Foursquare , так как они не следуют спецификации во всех отношениях, но вносят некоторые изменения, чтобы быть более практичными и прост в использовании.

Что касается версий версий, с догматической точки зрения REST это осуждается на . Однако, с более прагматичной точки зрения, это чрезвычайно распространенная практика, которая значительно упрощает жизнь как для разработчиков API, так и для клиентов. Я бы порекомендовал прочитать блог Apigee, так как там много постов на такие темы, как versioning .

Если веб-клиент использует CSRF, который передается через ajax, и просто отключить 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-поршня для решения эти проблемы. Я уже разветвил свой проект и начал играть с этой раздвоенной версией поршня: https://bitbucket.org/jespern/django-piston-oauth2

Я не знаком с этим, так как использую tastypie . Если он не работает для вас, есть отличный автономный сервер Django OAuth2, который я использовал:

https://github.com/hiidef/oauth2app

...