2013-07-17 3 views
1

Я пытаюсь выяснить, какой лучший выбор был бы в плане безопасности для веб-приложения, которое может (в будущем) использоваться вместе с выделенным Приложение для Android.В OAuth (1.0a и 2.0) и Http Basic Auth

Однако, варианты выбора, с которыми я прошел, - это OAuth (2-legged) и Basic Http Authentication через TLS.

Пожалуйста, имейте в виду, что когда я обращаюсь к OAuth, я рассматриваю как OAuth 1.0a, так и OAuth 2.0, конечно, как разные альтернативы.

Вот мои сомнения:

1) Во-первых, будет ли смысл в наше время, чтобы создать систему безопасности, основанную на OAuth 1.0a? Должно ли считаться «слишком старым» и, следовательно, совершенно неправильным выбором?

2) Я не могу понять сценарий реального мира, где двуручный OAuth является более чистым, чем Http (S) Auth. Какие дополнительные бонусы я получаю от этого?

3) Учитывая, что я не являюсь экспертом по безопасности в ветеранах, мог бы ли OAuth быть разумным выбором?

4) Существуют ли поддерживающие фреймворки или другие сторонние вспомогательные инструменты, которые можно использовать для получения надежной надежной реализации OAuth за меньшее время и/или с меньшими усилиями, чем просто попытка выяснить это полностью от себя

ответ

1
  1. Это абсолютно разумно. Мое личное мнение заключается в том, что OAuth 1.0a все равно будет предпочтительным решением, если вы не уверены, что вам нужен OAuth 2. OAuth1 - строго определенный безопасный протокол, OAuth2 - это «инфраструктура», которая используется для создания протоколов, некоторые из них которые менее безопасны.

  2. Главное отличие заключается в том, что при использовании OAuth вы никогда не отправляете пароль по проводу. Кроме того, ваше приложение для Android не обязательно должно знать пароль пользователя. И если вы не знаете пароль, вы не можете обвинить его в утечке.

  3. OAuth 1.0a - вполне разумный выбор. Просто не забудьте использовать длинные (я имею в виду 1K + длинные) секреты. Секрет не передается с запросами, поэтому он не будет использовать пропускную способность, но он используется для генерации цифровых подписей.

  4. Есть. Но поскольку вы заинтересованы в андроиде, и я не специалист по Android, я оставлю это другим. У вас будут лучшие шансы на хороший ответ, если вы зададите этот вопрос отдельно.

+0

Спасибо за помощь. Примерно в пункте 2, так как я работаю над своим * собственным * приложением (никаких третьих сторон вообще), было бы действительно важно, если вместо токенов будут отправляться пароли? Поскольку, строго говоря, о «приватном» сценарии, я все еще не убежден в том, что OAuth будет использовать больше, чем Basic Auth. Если бы какой-либо злой злоумышленник украл токен пользователя B, он все равно мог использовать мое веб-приложение (или мобильное приложение), претендующее на роль B, будучи в состоянии сделать точно (и не более) то, что он мог сделать в базовой среде с защитой авторских прав , поскольку пользователь/пропуск будут работать только для этой цели. Правильно? – Seether

+0

@ В отличие от этого, пользователь мог использовать один и тот же пароль где-то в другом месте. поэтому, если пароль скомпрометирован в одном месте, есть вероятность, что учетные записи этого пользователя в других службах находятся под угрозой. – JimiDini

+0

@Seether также легче блокировать oauth-токен, чем пользователь. вы можете предоставить страницу на веб-сайте, где пользователь может просмотреть список своих oauth-сессий с использованием последнего времени, IP-адреса и кнопки, чтобы убить токен доступа.эта страница, конечно, не должна быть доступна через oauth :) – JimiDini