Почему я не должен программно отправлять имя пользователя / пароль в Facebook/Twitter/Amazon/ и т. Д.?
Хотелось бы, чтобы была центральная, полностью настраиваемая, универсальная система входа с открытым исходным кодом, которая позволяла вам входить в систему и управлять всеми вашими учетными записями в Интернете (может быть, есть?)...
Я только что нашел RPXNow сегодня после начала создания приложения Sinatra для входа в Google, Facebook, Twitter, Amazon, OpenID и EventBrite, и похоже, что это может сэкономить некоторое время.
Но я продолжаю задаваться вопросом, не будучи гуру аутентификации, почему я не могу просто иметь гладкую страницу входа с надписью "Введите имя пользователя и пароль и проверить свою службу входа в систему", а затем в фоновом режиме либо соскрести страницу входа с скажем EventBrite и программно отправить форму с помощью Mechanize или использовать API, если он был? Было бы намного проще и удобнее работать с пользователем, если бы им не приходилось проходить через всплывающие окна и перенаправления, и они могли использовать любые ранее существующие учетные записи.
Мой вопрос:
- По каким причинам я не должен делать что-то подобное?
Я не знаю много о серьезных деталях куки / сессий / безопасности, так что если вы могли бы описать или указать мне некоторые полезные ссылки, которые были бы удивительными. Спасибо!
Редактировать:
Я знаком с OpenID и API. Мне действительно было интересно, что касается безопасности, юриспруденции и конфиденциальности. Я полностью понимаю часть конфиденциальности, не знаю, есть ли что-то юридически записанное по этому поводу, но при условии, что это под ssl, и я не храню никакие данные (буду хранить куки и токены), каковы последствия для безопасности?
3 ответа
Если я захожу на ваш сайт и сообщаю вам свой пароль Gmail, что я могу гарантировать, что вы не прочитаете все мои электронные письма и даже не отправите несколько своих собственных? А что, если вы станете немного умнее и скажете: "Люди повторно используют пароли, я мог бы также попробовать попробовать, работает ли этот пароль для его банковского счета".
Как пользователь, я не доверяю вашему сайту мой пароль. Период.
Весь смысл Open Id и OAuth (именно это использует RPX) состоит в том, чтобы обойти вышеуказанную проблему. Я могу предоставить вашему веб-сайту ограниченный, отзывной и настраиваемый доступ к моей учетной записи Facebook, и все это без указания вашего веб-сайта моего пароля Facebook.
Пользовательский интерфейс сбивает с толку, я согласен. Но со временем люди поймут, что это такое, и станет намного лучше.
Как уже сказано выше:
- Нельзя доверять сайту (или владельцу сайта), имеющему доступ к вашей учетной записи {google|yahoo| и т. Д.}, Не изменять свой пароль и выгонять вас из своей учетной записи.
Но я чувствую, что есть и другие веские причины:
Многие люди используют один и тот же пароль для нескольких учетных записей сайта (некоторые могут использовать один и тот же пароль в gmail и paypal), и владелец сайта может злоупотребить этим
Владелец сайта не хочет нести ответственность за других владельцев сайта, злоупотребляющих вашей учетной записью
Владелец сайта не может хранить ваше имя пользователя и пароль в безопасном режиме. Сайт должен иметь возможность доступа к ним автоматически. Таким образом, на сервере хостинга хранится все необходимое для доступа к этим учетным данным.
И хостинг обычно происходит на общем или виртуальном сервере, и администраторы хостинговой компании (а иногда - если хостинговая компания не слишком сознательна - коллеги-пользователи) могут получить к ним доступ.
Безопасность и конфиденциальность. Период.
Я верю, что даже некоторые сайты, такие как Facebook, не рекомендуют использовать этот подход в своих TOS. Если это так, это будет незаконно.