Comments 33
Все хотят одну кнопку: «Войти как...».
Лол, смелое утверждение. Например, я не хочу. Если есть возможность, то всегда предпочту именно пару логин и пароль, чем вход через третий сервис. А запоминать ничего и не нужно, есть менеджеры паролей для этого 🤷
А я вообще предпочту анонимное пользование. Процентов 70 сервисов с требованием идентификации я просто закрывавю.
Менеджеры паролей - инфернальное зло. Особенно если ты 20% времени работаешь с устройств, которые вайпятся при перезагрузке (рабочие/лабораторнык компы)
Аналогично.
До сих пор избегаю переходить на VK ID в почте mail.ru.
А RuStore-ом пользуюсь анонимно. Как только введут обязательную авторизацию - перестану пользоваться.
У каждого есть почта, подписка Плюс или аккаунт в Такси.
Нет.
Подскажите, а как вы обычно регистрируйтесь на сайте?
Всё равно как-то нужно идентифицировать, обычно для этого телефон используют, но SMS обычно платные для сервиса.
Это чревато. На один логин и пароль завязывать все доступы. Сам яндекс настаивает на 2FA, внедряет всякие "Yandex Identity Hub". Что уже "по клику" не получится.
А кроме SMS есть куда дешевле по звонившему номеру.
Я лично встречался с багами одного из способов авторизации названных здесь, так что, как минимум с технической части, я был бы очень аккуратен с внедрением.
А уж делать далеко идущие выводы (вам больше не нужна собственная аутентификация) надо быть предельно аккуратным
Ну и кстати легко представить как могут монетизировать такую сквозную аутентификацию, темболее если не у кого не будет своей...
Если ваш продукт сегодня встречает юзера формой Email + Пароль + Повторите пароль, вы теряете конверсию.
Мои личные предпочтения другие. Если сервис не особо нужный и бесплатный, то я, да, предпочитаю одну кнопку и имею для этого специальный ящик в Gmail. Если сервис платный или ой как нужный, то я предпочитаю регистрироваться по-настоящему с формой "Email + Пароль + Повторите пароль". Просто авторизация по одной кнопке - это лишний конрагент в процессе, значит, лишние риски поломки цепочки. Поэтому, мне кажется, с формой "Email + Пароль + Повторите пароль" сервис не теряет именно платных пользователей, а приобретает праздных гуляк, нагружающих сервис.
Пока я делаю простые сервисы, и действительно этого хватает. Когда мои сервисы подрастут, возможно подключу что-то более серьёзное, только вот вопрос - что?
Что является сейчас золотым стандартом? Если подтверждение через телефон - то нужно будет платить за SMS и писать кучу дополнительного кода и восстановление пароля, что дополнительная заморочка на первых парах.
Ну, через телефон проводить авторизацию нужно не всем сервисам, а тем, кто хочет быть уверенным в персоне. Например, банки официально не разрешают даже пользоваться карточкой их клиента его родственникам. И при заходе в аккаунт банка они предпочитают двухфакторную аутентификацию по паролю и телефону. Рутубу же не обязательно использовать телефон пользователя для авторизации, но он, сволочь, в некоторых сценариях использует.
Конечно, если авторизации можно избежать - это лучший вариант.
Но вот если например сервис монетизируется по модели фремиум - 10 запросов бесплатно, дальше за деньги, то без авторизации никуда.
Так как пользователь платит деньги, у него должна быть возможность восстановить доступ.
Это 3 варианта:
Через телефон
Через электронную почту
Через третий сервис Гугл, Яндекс, ВК, Сбер
В моей статье говорится о том, что для большинства пользователей взаимодействие через третий сервис удобнее, и с точки зрения разработки это сильно проще, чем писать код восстановления пароля для телефона и почты(с ретраями и безопасностью)
Один из пользователей написал в личку, очень в тему:
Здравствуйте. По поводу способов авторизации..
Я предлагаю попутно взглянуть на этот вопрос в разрезе обработки персональных данных (ОПД). Для стартапов это может быть очень полезно.
В области ОПД очень большие размеры штрафов и достаточно большие возможности у проверяющих для дистанционного/автоматического выявления нарушений – это создает неоправданно высокие риски для тех, кто хотел бы «простопотеститьсервис».
Если вы используете для идентификации пользователя придуманный им логин – вы можете вообще уйти от рисков, связанных с ОПД, правильно сконструировав логику взаимодействия с пользователями. Конечно, в пределах, которые в принципе допускает сама суть сервиса. Того же эффекта, полагаю, можно достичь если ограничиваться токеном, получаемым от Яндекс и т.п., и не запрашивать от сервиса данные пользователя, не являющиеся пока что необходимыми..
Работаете с юрлицами? Добавьте Сбер ID
Довелось мне работать над одним сервисом для начинающих предпринимателей, очень плотно связанным со Сбером. Ну то есть вот совсем плотно.
Основная причина оттока с формы регистрации, с долей в районе ¾ - необходимость иметь СберID.
Если я вижу такое сообщение...
...и сервис для меня не особо важен, то следующее действие будет - "закрыть вкладку".
Ну нафига вам мой портрет, имя, пол и адрес почты? ;) Спам адресный рассылать, поскольку я согласился на передачу этих данных и обработку в соответствии с вашими правилами?
Работаете с юрлицами? Добавьте Сбер ID
Насколько я в курсе, Сбер ID - это для физлиц.
А для юрлиц - это СберБизнес ID.
Шёл год 2026. Человеки продолжали «авторизовываться» с помощью формы аутентификации. Даже чёрт с ним, что авторизация, но как авторизовать себя — вот загадка тысячелетия. Разве что произнести в зеркало «я себя вижу — значит, я существую, и своим существованием наделяю себя полномочиями быть». Звучит бессмыслицей, но хотя бы имеет определенную логику.
Чистая правда. Отсутствие oauth это ред флаг, сразу закрываю сайт и ищу другой. В последнее время даже появляются сайты вообще без полей ввода, где только oauth есть - к этому надо стремиться.
Я тот человек, который хочет одну кнопку: «Войти как...» и которая будет сразу работать. Проблема в том, что большинство сайтов делают функционал этой кнопки через пятую точку. Даже Хабр не осилил эту сложную функцию (чему я не удивлен) т.к. после входа через ВК получаю сообщение "Внешняя учётная запись не привязана ни к одному Аккаунту" и предлагает "Вернуться к форме входа". Жаль, похоже у них не хватило денег на аналитика/ продакт-менеджера/тестера, который бы сказал: "Эй, это так не должно работать".
Любопытно, что никто не задал технических комментариев :) А мне вот кажется, что ни в документации у Яндекса, ни в статье нет информации как с этим всем работать в dev-окружении. Иначе выглядит, что код прямо на проде пишется.
К примеру:
Для дев-окружения (localhost) надо создавать второе приложение?
Достаточно ли подключить Javascript блок из статьи и документации или нужны еще какие-нибудь действия, чтобы это завелось на localhost?
Нужен ли какой-то дополнительный инвентарь типа внешнего тестового домена для проксирования на локалхост?
Авторизация 2026: Почему вам больше не нужна форма регистрации (и как внедрить Яндекс ID, VK и Google)