Насчет первого — склонен согласиться. Я б даже сказал, что 95% рядовых сайтов той же loginзы хватило б выше крыши. Я про другой случай.
А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор? ЖЖ, помнится мне, в таком случае прямо сообщал (причем не мне, а пользователю) что-то вроде: «сайт ХХХ попросил у вас идентификации, которую вы не можете предоставить» — после того, как юзер вводил свой логин и пароль на ЖЖ. Да и спецификации явно требуют передавать провайдеру идентификатор.
Вообще, рекомендую обратить внимание на такую вещь, как real_name. В том или ином виде он есть у всех вышеупомянутых провайдеров (в отличие от email). Я планирую вообще отказаться от того, чтобы логин где-то фигурировал на сайте, кроме как в странице входа. У меня входящие через OAuth получают ник вида vk_{VK_uid} — пусть некрасиво, но они (пользователи ВК) его и не видят. Все их сообщения подписываются их реальным именем. А регистрирующимся обычным путем при необходимости я сообщаю, что префикс vk_ — зарезервирован.
По OpenID. "(войти через гугл, войти через жж). Что в данном случае меняется?"
"-"
1. OAuth еще и дает мне доступ к API провайдера (что, в том числе, позволяет мне дать пользователю набор «вкусных» функций), а OpenID не дает ничего.
2. Независимо от того, выполнен пользователем вход на OpenID-провайдере, или нет, он *должен* ввести у меня свой идентификатор
"+"
1. Мне не надо регистрироваться на провайдере.
2. Мне не надо писать отдельную реализацию клиентской части для каждого очередного провайдера.
Итог: если мы заботимся о пользователе — OAuth лучше, если о себе — OpenID
про уникальный коллбек я упомянул, читайте, пожалуйста, внимательнее, перед тем как предъявлять претензии. кстати, из упомянутых 7 сервис-провайдеров по-моему (не скажу, что на 100% уверен — специально не считал) только 3 разрешают менять коллбек непосредственно в запросе. Остальные — жестко посылают на юг, если коллбэк отличается от прописанного в натройках приложения.
Да, надо. Если вдуматься, это логично. С чего бы тому же ВКонтакту или Фейсбуку давать доступ практически ко всем своим механизмам какому-то неизвестному сайту? Один из немаленьких плюсов авторизации по OAuth это как раз доступ к API сервера. Так зарегистрированный пользователь оставит на сайте в лучшем случае свой пол, город и возраст. А обычно и вовсе ограничится требуемым минимумом. А с зашедшего со ВКонтакта — столько можно инфы натащить, что ой :)
Не то, чтобы эта инфа была нужна, но наличие возможности её получить — не помешает.
А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор? ЖЖ, помнится мне, в таком случае прямо сообщал (причем не мне, а пользователю) что-то вроде: «сайт ХХХ попросил у вас идентификации, которую вы не можете предоставить» — после того, как юзер вводил свой логин и пароль на ЖЖ. Да и спецификации явно требуют передавать провайдеру идентификатор.
"-"
1. OAuth еще и дает мне доступ к API провайдера (что, в том числе, позволяет мне дать пользователю набор «вкусных» функций), а OpenID не дает ничего.
2. Независимо от того, выполнен пользователем вход на OpenID-провайдере, или нет, он *должен* ввести у меня свой идентификатор
"+"
1. Мне не надо регистрироваться на провайдере.
2. Мне не надо писать отдельную реализацию клиентской части для каждого очередного провайдера.
Итог: если мы заботимся о пользователе — OAuth лучше, если о себе — OpenID
Не то, чтобы эта инфа была нужна, но наличие возможности её получить — не помешает.
Меня не устраивают функционал, дизайн и надежность виджета
Большинство — OAuth 2, но на твиттере пока первый.