Я пытаюсь выяснить, какой лучший выбор был бы в плане безопасности для веб-приложения, которое может (в будущем) использоваться вместе с выделенным Приложение для 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 за меньшее время и/или с меньшими усилиями, чем просто попытка выяснить это полностью от себя
Спасибо за помощь. Примерно в пункте 2, так как я работаю над своим * собственным * приложением (никаких третьих сторон вообще), было бы действительно важно, если вместо токенов будут отправляться пароли? Поскольку, строго говоря, о «приватном» сценарии, я все еще не убежден в том, что OAuth будет использовать больше, чем Basic Auth. Если бы какой-либо злой злоумышленник украл токен пользователя B, он все равно мог использовать мое веб-приложение (или мобильное приложение), претендующее на роль B, будучи в состоянии сделать точно (и не более) то, что он мог сделать в базовой среде с защитой авторских прав , поскольку пользователь/пропуск будут работать только для этой цели. Правильно? – Seether
@ В отличие от этого, пользователь мог использовать один и тот же пароль где-то в другом месте. поэтому, если пароль скомпрометирован в одном месте, есть вероятность, что учетные записи этого пользователя в других службах находятся под угрозой. – JimiDini
@Seether также легче блокировать oauth-токен, чем пользователь. вы можете предоставить страницу на веб-сайте, где пользователь может просмотреть список своих oauth-сессий с использованием последнего времени, IP-адреса и кнопки, чтобы убить токен доступа.эта страница, конечно, не должна быть доступна через oauth :) – JimiDini