Comments 16
Немного не по теме, ребят подскажите пожалуйста, я в процессе написания своего Saas сервиса, так вот. Как лучше сделать авторизацию? Мне видится что проше всего для пользователя это авторизация по номеру телефона, через короткий пароль высылаемый по смс. Так сделано у Тинькофа и Озона, довольно удобно и процент отказа скорее всего очень низкий.
Не все готовы оставлять свой номер телефона. Одно дело банк или крупный маркетплейс, другое дело, если некая новая платформа. Никто не хочет потом телефонного спама. К тому же, по номеру телефона гораздо проще отследить владельца. Ваша целевая аудитория согласится на это? В-третьих, смс не бесплатны, в отличии от пинкода отправленного на почту. Ну и стоит напомнить, в про уязвимость SS7 - Уязвимость в протоколе SS7 уже несколько лет используют для перехвата SMS и обхода двухфакторной аутентификации / Хабр (habr.com).
И чуть не забыл про кейс с переходом номера от одного владельца к другому. Зачастую, если человек не пользуется номером более 6 месяцев, номер считается свободным и может уйти к другому человеку. Сможет ли он зарегистрироваться на вашем сервисе? Ведь номер может оказаться занят.
Свои 5 копеек вставлю о наболевшем. Использование контактных данных в качестве логина означает раскрытие логина всем. Их базы есть у тех, кто профессионально занимается их сбором или использованием. Если этот логин ещё и email, это означает предоставить возможность сбросить пароль любому и раскрыть связь между email и логином. А это даёт возможность захватывать аккаунты, захватывая email. Аналогично с номером телефона. Помимо названой выше уязвимости, телефон может быть общедоступным. Т.е. работать в режиме DMZ == не использовать экран блокировки. Поэтому считать доверенным канал, на который отправляется одноразовый код, можно только в случае, если этот канал подтвердил пользователь в текущей коммуникации. А значит этот канал не даёт никакой дополнительной защиты. И нельзя забывать, что пользователь не обязан иметь постоянно доступы ко всем своим аккаунтам и поддерживать канал мобильной связи.
Все эти раундтрипы с переходами туда-сюда для получения и прочтения кода люто выбешивают. На элементарную операцию аутентификации вместо 3 секунд тратится минута-две и идиотское ожидание и неизвестность, а придёт ли одноразовый код. Некоторые особо стараются аутентификацию усложнить, запрещая возможность вставки пароли из буфера обмена. А ещё блокируют работу хранилища паролей в браузерах.
Согласен что авторизация через сети головняк.
Вот попробовал oauth2 на go с примера
(см правилый ответ)
Завел на Facebook приложение получил client-id ,клиент секрет увидел ,-вставил...запустил ...в браузере,- одна ссылка на странице login facebook / давим / Первое что facebook не нравится надо добавить домены(я ну как бы со страрта ...имею только localhost...)Добавляю localhost в настройки приложения на сайте developer.facebook...Теперь ему(facebook) не нравится...что не https :-)
Дорабатываем типа https://github.com/denji/golang-tls
Запускаем
Теперь ему не нравится самоподписанный сертификат...(Да и calback куда оно сделает?(Не на localhost же)..но до calbback еще далеко)....
Т.е чтоб это оттестировать мне надо...реальный IP(или арендовать VPS) купить домен к нему ,организовать ключ и сертификат к этому домену...и лишь потом скормить это facebook,убедившись что авторизация через сеть работает?
Есть ли проще путь?
ngrock не пробовали? (хинт - запускайте либо из пустой директории, либо из директории с файлами, которые не жалко выставить всем на чтение :) )
Благодарю...прикольный сервис...Попробовал с ним..и больше вопросов чем ответов...:-)
Он создал ссылку https://cd1c-194-187-149-96.ngrok.io
Поправил код...подправил личный квбинет facebook приложения...и тут совсем странно пишет что домен не внесен в приложение,..хотя он точно внесен..я вот даже видно набросал ниже по ссылке
Видимо в фейсбуке знаю об этом хитром способе и так его лочат
Не там надо с бубном потанцевать...ниже ответ написал (возможно в другой ветке)
Цитирую,что ответил
После поиска решения невхода, что домен не внесен(Текс ошибки не соответствует причине ) выяснилось что надо отключить "Использовать строгий режим для URI перенаправления " Я его отключить не мог почему-то...просто добавил uri .. Всё одно при входе (см видео) пишет красный треугольник предупреждения(как его убрать ? кто знает?)...а дальше возвращает токен в прогу
Ещё раз благодарю за ссылку ngrock...Без него сложно оттестировать вход в соц сети...жаль что после перезапуска сервиса ngrock ссылка новая.
После поиска решения невхода что домен не внесен(Текс ошибки не соответствует причине ) выяснилось что надо отключить "Использовать строгий режим для URI перенаправления " Я его отключить не мог почему-то...просто добавил uri .. Всё одно при входе (см видео) пишет красный треугольник предупреждения(как его убрать ? кто знает?)...а дальше возвращает токен в прогу
"Т.е чтоб это оттестировать мне надо...реальный IP(или арендовать VPS) купить домен к нему ,организовать ключ и сертификат к этому домену...и лишь потом скормить это facebook,убедившись что авторизация через сеть работает?"
Для обучения это конечно проблема, а для продакшена это все самао собой разумеется. Ну и Let'sEncrypt это палочка-выручалочка в подобных случаях.
авторизацыя через сс похожа на фишинг, поэтому сразу нафик.
Можете называть меня ретроградом, но я не соглашусь с изначальным тезисом статьи о том, что сложно или плохо иметь отдельные учетки для отдельных сервисов или сайтов. Это намного лучше, чем иметь учетки, которые привязаны к другим учеткам, ибо шанс того, что этот карточный домик интеграций сломается по тем или иным техническим причинам слишком велик. Или все сломается просто потому, что вы потеряете доступ к изначальной учетке, на основе которой происходил вход в другой сервис.
Мы живём в мире, где любой крупный сервис не отвечает ни за что перед своими обычными пользователями. Если вы не VIP-пользователь, для которых существует отдельный мирок, то вашу учетную запись в любой момент может забанить поехавшая автоматика, которая усмотрит своими кривыми алгоритмами в вашем поведении «что-то не то». Вас забанит анонимный и неподотчетный модератор с синдром вахтёра, либо потому что у него было плохое настроение, либо потому, что на вас настрочили жалоб какие-то троли. Вашу учетку банально заблокирует «умная» эвристика по причине «он зашёл через VPN!!!!111 Полундра!!!11», несмотря на то, что вы пол года уже заходили в своё учетку через один тот же VPN. Как бонусные очки: заблокированную учетку якобы можно будет разблокировать путём сброса пароля через ответ на секретный вопрос, но система не будет принимать его, несмотря на то, что он у вас храниться в менеджере паролей. Реальная проблема, если что. К слову тот же самый ответ на секретный вопрос потом магическим образом сработает через пол года какого-то непрозрачного таймаута при блокировке.
И у вас не будет ни саппорта, ни эскалации проблемы, ни обжалования и возможности оспорить это. И вы хотите привязываться к этой помойке? Нет, спасибо.
Я соглашусь с Вами, сам где-то использую авторизацию через соцсети, а где-то только прямую. Мы предоставляем выбор пользователю. И этот выбор, судя по анализу статистики, привлекает новых пользователей.
Насчёт вашего кейса с блокирокой - всё сильно зависит от реализации конкретного сервиса. На нашей платформе не запрещено совмещать несколько авторизаций завязанных на один аккаунт платформы - можно зайти напрямую, можно зайти через соцсети. Если везде на момент регистрации была использована одна почта, то вы всегда откроете один аккаунт. Т.е. если вашу учётную запись заблокировала соцсеть, вы можете восстановить пароль на почту и зайти через прямую авторизацию.
На некоторых сервисах, особенно, если аккаунт становиться корпоративным, авторизации разными способами приводят к попаданию в разные аккануты.
Судя по названным признакам, особенно про отсутствие службы поддержки, прям про Google написали. У них таймаут от 3 дней на разрешение доступа к аккаунту после сброса пароля в таких случаях. Об этом сроке было в их статьях руководства пользователя. Потерять аккаунт в Google теперь уже ничего не стоит с их проверкой личности, навязываемой двухфакторной аутентификацией и вымогаемым номером телефона. Я так уже два Google-аккаунта потерял. Самый идиотский вопрос их системы аутентификации: "введите номер телефона для отправки СМС-кода". Идиотский он потому, что номер телефона в аккаунте не прописан, и светить Google свой номер телефона через связь с аккаунтом для меня неприемлемо. И такое не только у Google встречал, а и на некоторых других сайтах. Географическая привязка аккаунтов по IP – лютое зло от Google. Ещё и раскрывает регион прохождения аутентификации. Для меня ужас в том, что никак всю эту дрянь не отключить в настройках аккаунта.
"Есть и ложка дёгтя, появилась она недавно. Если раньше можно было получить сразу access-токен и ID-токен, то теперь вариантов нет, токен должен быть один. Если вам требуется взаимодействие с API Facebook, аутентифицировать пользователя за один запрос не получится, придется делать запрос профиля отдельно."
не совсем понял суть проблемы, Facebook же прямо указывает на то, что токены, выдаваемые для Android, iOS и JavaScript SDK клиентов всегда долгоживущие. В этом Facebook удобнее (но и менее безопасен) чем Google SignIn, ID токен которого живет всего час, и после этого требуется повторный запрос на его обновление через SilentSignIn к примеру
"столкнулись в процессе разработки это несоответствие между документацией и реальными контрактами API" - это в чем же?
А еще вы забыли FireBase, который мало того, что довольно просто интергрируется, там еще и имеет основные популярные упомянутые тут сервисы (ну, может быть кроме Yandex или VK, но это умирающие решения), тут и авторизация через номер смартфона (SMS), и обычную почту, и другие. Заодно и PUSH сразу можно прикрутит к приложению, чтобы два раза не вставать. :)
Тернистый путь внедрения аутентификации через соцсети