Почему я не должен программно отправлять имя пользователя / пароль в Facebook / Twitter / Amazon / и т. Д.?

Question

Хотелось бы, чтобы была центральная, полностью настраиваемая, универсальная система входа с открытым исходным кодом, которая позволяла бы вам входить и управлять всеми вашими учетными записями в Интернете (может быть, есть?) ...

Я только что нашел RPXNow сегодня после начала создания приложения Sinatra для входа в Google, Facebook, Twitter, Amazon, OpenID и EventBrite, и похоже, что это может сэкономить некоторое время.

Но я продолжаю удивляться, не будучи гуру аутентификации, почему я не могу просто иметь гладкую страницу входа с надписью «Введите имя пользователя и пароль, и проверьте свою службу входа», а затем в фоновом режиме или очистить страницу входа от скажем EventBrite и программно отправить форму с помощью Mechanize, или использовать API, если он был? Было бы намного проще и удобнее работать с пользователем, если бы им не приходилось проходить через всплывающие окна и перенаправления и они могли использовать любые ранее существующие учетные записи.

Мой вопрос:

• По каким причинам я не должен делать что-то подобное?

Я не знаю много о серьезных деталях куки / сессий / безопасности, так что, если вы могли бы описать или указать мне некоторые полезные ссылки, которые были бы удивительными. Спасибо!

Edit:

Я знаком с OpenID и API. Мне действительно было интересно, что касается безопасности, юриспруденции и конфиденциальности. Я полностью понимаю часть конфиденциальности, не знаю, есть ли что-либо юридически записанное по этому поводу, но при условии, что это под ssl, и я не храню какие-либо данные (будут хранить куки и токены), каковы последствия для безопасности

Answer 1

Если я захожу на ваш сайт и сообщаю вам свой пароль Gmail, что я могу гарантировать, что вы не прочитаете все мои электронные письма и даже не отправите несколько своих собственных? А что, если вы станете немного умнее и скажете: «Люди повторно используют пароли, я мог бы также попробовать попробовать, работает ли этот пароль для его банковского счета».

Как пользователь, я не доверяю вашему сайту мой пароль. Период.

Весь смысл Open Id и OAuth (именно это использует RPX) состоит в том, чтобы обойти вышеуказанную проблему. Я могу предоставить вашему веб-сайту ограниченный, отзывной и настраиваемый доступ к моей учетной записи Facebook, и все это без указания вашего веб-сайта моего пароля Facebook.

Пользовательский интерфейс сбивает с толку, я согласен. Но со временем люди поймут, что это такое, и станет намного лучше.

Answer 2

Как уже сказано выше:

• Сайт (или владелец сайта), имеющий доступ к вашей учетной записи {google | yahoo | etc} , не может быть доверенным , чтобы не изменить свой пароль и выкинуть вас из своей учетной записи.

Но я чувствую, что есть и другие веские причины:

• Многие люди используют один и тот же пароль на для нескольких учетных записей сайта (у некоторых может быть один и тот же пароль на gmail и paypal ), и владелец сайта может злоупотребить этим

• Владелец сайта не хочет нести ответственность перед другими владельцами сайтов, злоупотребляющими вашей учетной записью

• Владелец сайта не может сохранить ваше имя пользователя и пароль в защищенном режиме . Сайт должен иметь возможность доступа к ним автоматически . Таким образом, на сервере хостинга хранится все необходимое для доступа к этим учетным данным.

И хостинг обычно происходит на общем или виртуальном сервере, и администраторы хостинговой компании (а иногда - если хостинговая компания не слишком сознательна - коллеги-пользователи) могут получить к ним доступ.

Answer 3

Безопасность и конфиденциальность. Период.

Даже некоторые сайты, такие как Facebook, не рекомендуют использовать этот подход в своих TOS. Если это так, это будет незаконно.