Comments 78
Спасибо за перевод, не хватает только примеров кода. А в целом подход стар и в свое время широко раскручивался в виде отказа от собственной авторизации по логину-паролю, отдавая этот функционал стороннему сервису, который после авторизации отдаст токен. Маппинг в собственной базе при этом происходит либо по содержащемуся в токене id, либо по email.
На практике используется широко и недостатков не так уж и много — только затраты времени на запросы в сторонний сервис для валидации токена и возня с апи различных сервисов и их схемами работы. Из библиотек могу посоветовать www.passportjs.org, но единую схему работы для нескольких провайдеров он не предоставляет, код будет выглядеть довольно перегруженным.
На практике используется широко и недостатков не так уж и много — только затраты времени на запросы в сторонний сервис для валидации токена и возня с апи различных сервисов и их схемами работы. Из библиотек могу посоветовать www.passportjs.org, но единую схему работы для нескольких провайдеров он не предоставляет, код будет выглядеть довольно перегруженным.
Статья правильная в том смысле, что проверка имени/пароля и связанные с этим заботы не такие уж простые вещи и для небольших проектов гораздо разумней использовать чужие решения.
Но уж очень резануло про некие правила GDPR: использование чужой аутентификации усложняет соответствии GDPR, вы ведь начинаете передавать данные пользователя третьим лицам, возможно в другую юрисдикцию со своими правилами обработки. А ответственность за все неправомерное использование этих данных будет на вас.
Посыл того, что при этом у вас появляется возможность хранить меньше персональных данных он хороший, но неверный. Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше! По сути «спихнуть» на провайдера получается только хранения пароля.
Но уж очень резануло про некие правила GDPR: использование чужой аутентификации усложняет соответствии GDPR, вы ведь начинаете передавать данные пользователя третьим лицам, возможно в другую юрисдикцию со своими правилами обработки. А ответственность за все неправомерное использование этих данных будет на вас.
Посыл того, что при этом у вас появляется возможность хранить меньше персональных данных он хороший, но неверный. Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше! По сути «спихнуть» на провайдера получается только хранения пароля.
> вы ведь начинаете передавать данные пользователя третьим лицам
Но постойте, ведь все наоборот, это эти некие третьи лица начинают вам передавать (с согласия пользователей) эти данные, разве нет? А вы только используете их для аутентификации пользователя и авторизации запросов.
Я плотно работал только с google sign-in но там на бэкенде даже запросов на валидацию идентити как таковых почти не происходит — полученный idToken расшифровывается/подтверждается локально скачанными ключами, которые экспайрятся конечно но не ежесекундно и даже не ежеминутно.
> Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше
Вам придется хранить какой-либо идентификатор пользователя, удобный пользователю для логина. Особенно если хочется иметь хотя бы формальную верификацию. Email там или никнэйм (хотя можно и заморочиться и сохранять только хэш конечно, но кто ж будет этим заниматься). И пароль в каком-то виде тоже придется хранить. В случае стороннего провайдера у себя можно вообще хранить только идентификатор или даже хэш от идентификатора. При этом в UI все еще удобно показывать и аватарку и имя с фамилией, если сторонний провайдер выдает эту информацию при логине.
Но постойте, ведь все наоборот, это эти некие третьи лица начинают вам передавать (с согласия пользователей) эти данные, разве нет? А вы только используете их для аутентификации пользователя и авторизации запросов.
Я плотно работал только с google sign-in но там на бэкенде даже запросов на валидацию идентити как таковых почти не происходит — полученный idToken расшифровывается/подтверждается локально скачанными ключами, которые экспайрятся конечно но не ежесекундно и даже не ежеминутно.
> Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше
Вам придется хранить какой-либо идентификатор пользователя, удобный пользователю для логина. Особенно если хочется иметь хотя бы формальную верификацию. Email там или никнэйм (хотя можно и заморочиться и сохранять только хэш конечно, но кто ж будет этим заниматься). И пароль в каком-то виде тоже придется хранить. В случае стороннего провайдера у себя можно вообще хранить только идентификатор или даже хэш от идентификатора. При этом в UI все еще удобно показывать и аватарку и имя с фамилией, если сторонний провайдер выдает эту информацию при логине.
С точки зрения бекенда может быть, но пользователь приходит не к нему, а к некоторому сервису, проекту. Представьте себе, что вы разрабатываете аналог порнохаба, как вы считаете, комфортно ли будет пользователю проходить аутентификацию через гугль/фейсбук/ГосУслуги?
аналог порнохаба, как вы считаете, комфортно ли будет пользователю проходить аутентификацию через гугль/фейсбук/ГосУслуги?Ответ и так известен и даже пример есть, собственно тот самый порнохаб для рф просит авторизацию через ВК и находился как минимум один способ узнать кто использовал вход ВК для входа на порнохаб.
Статья очень сильно мешает термины аутентификации(процесс проверки истинности сущности пользователя), и авторизации(процесс проверки наличия доступа у пользователя).
Первое: Я полностью согласен по поводу "велосипедов". Если вы не ветеран семи морей аутентификации и авторизации, то вам лучше даже не стоит начинать изобретать свое. Наши же FIDO стандарты это 200 человек из 50 компаний, ветераны индустрии(Mike Johnes создатель JWT один из моих коллег для примера и это только цветочки).
Второе: Выбирая между моей аутентификацией или просто сделать авторизацию через кого-то, нужно учитывать "Кто это?", "Будет ли он сущевствовать через год?", "Стоимость?", "Безопасность" и "Законы и права". Если вы по закону должны хранить все у себя, или только работать с сертифицированными поставщиками.
Третье: Implicit-flow это плохо, только если это не мобильное приложение. Для микросервисной архитектуры храните JWT в куки c HTTP-ONLY флагом.
Четвертое: Почитайте про WebAuthn(https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285), FIDO2(https://habr.com/ru/post/354638/) и вот еще туева хуча с чем поигратся https://github.com/herrjemand/WebauthnAwesome. Для авторизации: Делаем свой IdP https://github.com/ory/hydra. Подключаем чужой http://www.passportjs.org/
Существенной частью вопроса «кто это?» может быть вопрос «как к этому отнесутся пользователи», потому что в определенных ситуациях, доля тех потенциальных пользователей, кто не захочет авторизоваться через соцсети вообще или через какую-то определенную соцсеть, может оказаться существенным. В этом могут быть замешаны самые разные мотивы, от откровенной паранойи до, например, политической аффилированности поставщика сервиса аутентификации (условно, «ВК = ФСБ» или «Google = коммунисты», смотря что реально может волновать целевую аудиторию).
JWT-токен это как ИТ-технологии
моделей, основанных на возможностях искусственного интеллекта. Такие модели позволяют лучше идентифицировать подозрительные паттерны поведения.
Например, предположим, один из ваших пользователей, живущий в Канаде, входит в систему из дома. А через два часа вход в тот же аккаунт выполняется из Украины.
Для этого действительно нужны модели искусственного интеллекта?..
Скорее просто веса давать разным изменениям:
А в конце задать уровни реагирования и если порог пройден, выдавать дополнительную защиту типа проверки капчи или второго фактора. Примерно так сделано у AWS Cognito в Advanced Security Features.
- Новый IP: +1 к подозрительности
- Новый провайдер: +2 к подозрительности
- Новая страна: +3 к подозрительности
- Новое устройство: +10 к подозрительности
А в конце задать уровни реагирования и если порог пройден, выдавать дополнительную защиту типа проверки капчи или второго фактора. Примерно так сделано у AWS Cognito в Advanced Security Features.
Или ИИ или блокчейн, иначе инвесторы денег не дадут.
А есть IdaaS сервис, который хостится в России?
UFO just landed and posted this here
А для чего это знать? Юзер авторизуется в стороннем сервисе, на бэк приходит токен, валидируешь его в стороннем сервисе и получаешь минимальный набор данных — email, id, срок действия токена. Формат поступивших данных, конечно, лучше провалидировать, но никакой опасности эта схема не представляет.
Очевидные недостатки лежат в другой плоскости — это доступность сервиса (и время отклика) и открытость информации. Так, сервис авторизации узнает, в какое время определенный человек (его регион, характеристики системы и часто имя, сохраненное во внутренней базе этого сервиса, телефон, email и т.п. — если брать например авторизацию через сервисы Google) заходил на определенный сайт и примерное время его пребывания (по количеству запросов на верификацию токена от нашего бэка). То есть подобные системы — часть «ока большого брата», которое в свои bigdata-хранилища собирает информацию о людях и их предпочтениях. А разработчики с удовольствием предоставляют эту информацию, так как реализовывать шифрование паролей и систему против взлома довольно морочно для проектов не-энтерпрайз уровня. Энтерпрайзные же приложения в большинстве случаев все равно используют один из сервисов аналитики (или несколько через GTM), так что в любом случае предоставляют эти данные, только через другой канал.
На самом деле это довольно резонный консерн, к которому серьезно относятся в приложениях, требующих высокого уровня конфиденциальности, но в остальных случаях никто особо не заморачивается.
Очевидные недостатки лежат в другой плоскости — это доступность сервиса (и время отклика) и открытость информации. Так, сервис авторизации узнает, в какое время определенный человек (его регион, характеристики системы и часто имя, сохраненное во внутренней базе этого сервиса, телефон, email и т.п. — если брать например авторизацию через сервисы Google) заходил на определенный сайт и примерное время его пребывания (по количеству запросов на верификацию токена от нашего бэка). То есть подобные системы — часть «ока большого брата», которое в свои bigdata-хранилища собирает информацию о людях и их предпочтениях. А разработчики с удовольствием предоставляют эту информацию, так как реализовывать шифрование паролей и систему против взлома довольно морочно для проектов не-энтерпрайз уровня. Энтерпрайзные же приложения в большинстве случаев все равно используют один из сервисов аналитики (или несколько через GTM), так что в любом случае предоставляют эти данные, только через другой канал.
На самом деле это довольно резонный консерн, к которому серьезно относятся в приложениях, требующих высокого уровня конфиденциальности, но в остальных случаях никто особо не заморачивается.
Очевидные недостатки лежат в другой плоскости
Я бы добавил
— logout сделать нельзя или очень сложно
— вместо безопасной cookie у нас токен, который легче стащить
— refresh токен, аналог пароля, нужно где-то хранить, чаще всего в plain text
— надо дополнительно заморочиться и синхронизировать данные пользователя, которые получаем из сервиса при логине
— настройка обмена токенами это всегда боль, у каждого сервиса есть свой глючный SDK, который трактует OAuth/OpenID Connect по своему
Вы бы почитали хоть про oauth...
— logout сделать нельзя или очень сложно
стереть токен не сложно
— вместо безопасной cookie у нас токен, который легче стащить
токен положить в безопасную куку
— refresh токен, аналог пароля, нужно где-то хранить, чаще всего в plain text
зашифровать и посолить, если припекло
— надо дополнительно заморочиться и синхронизировать данные пользователя, которые получаем из сервиса при логине
всмысле, а если сами делаете то заморачиваться не надо? данные от юзера сами валятся в открытый порт?))
— настройка обмена токенами это всегда боль, у каждого сервиса есть свой глючный SDK, который трактует OAuth/OpenID Connect по своему
Вот это единственное тут верное
стереть токен не сложно
даже не жестком диске хакера, который ваш токен перехватил?
токен положить в безопасную куку
Это очень правильная идея. После этого нужно будет еще руками написать код, который этот токен будет рефрешить, обращаясь в IDaaS.
зашифровать и посолить, если припекло
Нужно периодически этот refresh token посылать в IDaaS, а значит надо уметь его расшифровывать, а значит ключ доступен приложению, а значит и хакеру, который в него влез.
всмысле, а если сами делаете то заморачиваться не надо? данные от юзера сами валятся в открытый порт?))
Если база юзеров у вас, а не в IDaaS, то данные юзера вот так получаются.
select * from users where password_hash = @hash and email = @email;
стереть токен не сложно
Стереть где? И что вам это даст?
А сам факт необходимости заставлять юзера авторизоваться в каком-то абсолютно левом с его точки зрения сервисе никого не смущает? Это может быть сколь угодно безопаснее, но выглядит прям фу-фу-фу, плюс юзабилити под большим вопросом.
Точно, тоже хотел про это упомянуть) Авторизация через модальные окна работает не везде — в мобильных устройствах и при включенных блокировщиках рекламы либо особых настройках безопасности браузера они могут просто не открываться, соответственно нужно создавать систему «если не сработала модалка — применить схему редиректа». Во втором случае пользователя перебрасывает на сторонний сайт и обратно, это затраты его времени и трафика, а с точки зрения основного сайта — дополнительные запросы и нагрузка на сервер + лишние срабатывания событий аналитики (ведь обратный редирект считается новым заходом), и аналитикам приходится создавать дополнительные схемы для фильтрации подобного поведения.
Если же работает через модалку, то она не стилизуется под сайт и выглядит некрасивым инородным элементом.
Считается, что все эти ux-неудобства окупаются тем, что пользователю не требуется создавать новый логин-пароль и запоминать его, так как потерпеть +-10 секунд редиректы или некрасивые модалки — это проще, чем заставлять мозг креативить для создания новой пары ключей доступа и помещать это дело в хранилище (я, например, пользуюсь LastPass, поэтому это не проблема, но многие хранят в текстовых файлах или приватных сообщениях в мессенджерах, в худшем случае — только в памяти). А если сайт требует «безопасный пароль» с разным регистром, цифрами, спецсимволами и длинный, то тут очевидно справятся только самые стойкие и очень заинтересованные в использовании данного сервиса.
В общем, с точки зрения ux оба решения далеки от идеала. А технологии биометрической идентификации пока недостаточно внедрены в устройства, работающие с веб-сайтами, так что приходится выбирать из того, что есть.
Если же работает через модалку, то она не стилизуется под сайт и выглядит некрасивым инородным элементом.
Считается, что все эти ux-неудобства окупаются тем, что пользователю не требуется создавать новый логин-пароль и запоминать его, так как потерпеть +-10 секунд редиректы или некрасивые модалки — это проще, чем заставлять мозг креативить для создания новой пары ключей доступа и помещать это дело в хранилище (я, например, пользуюсь LastPass, поэтому это не проблема, но многие хранят в текстовых файлах или приватных сообщениях в мессенджерах, в худшем случае — только в памяти). А если сайт требует «безопасный пароль» с разным регистром, цифрами, спецсимволами и длинный, то тут очевидно справятся только самые стойкие и очень заинтересованные в использовании данного сервиса.
В общем, с точки зрения ux оба решения далеки от идеала. А технологии биометрической идентификации пока недостаточно внедрены в устройства, работающие с веб-сайтами, так что приходится выбирать из того, что есть.
Очередная агитация в стиле «сделайте бекдор в своём проекте не только для спецслужб своей станы, но ещё и для крупных корпораций, а то им тоже хочется, а законного способа вас заставить нет» (один OCSP реализуемый запросом браузера чего стоит). Безопасность это как раз та область где нужно по-умолчанию считать всех врагами и не доверять никому, а не искать способы сделать полегче, да подешевле.
Возмещение ущерба, ответственность за взломы? Вы шутите? Да вся IT построена на том, что никто никому ничего не должен. Сколько раз взламывались всякие крупняки? Сколько раз они теряли не то что логины/пароли а данные кредиток миллионов человек? И? Понёс ли хоть кто-то ответственность большую чем пресс-релиз «извините»? Вот когда начнут реально наказывать всякие Гугло-фейсбуки за утечки, тогда, возможно, уже и обратят внимание на проекты поменьше.
Возмещение ущерба, ответственность за взломы? Вы шутите? Да вся IT построена на том, что никто никому ничего не должен. Сколько раз взламывались всякие крупняки? Сколько раз они теряли не то что логины/пароли а данные кредиток миллионов человек? И? Понёс ли хоть кто-то ответственность большую чем пресс-релиз «извините»? Вот когда начнут реально наказывать всякие Гугло-фейсбуки за утечки, тогда, возможно, уже и обратят внимание на проекты поменьше.
А в чём конкретно проблема с OCSP?
Если запрос к OCSP делает браузер, а не сервер, то OCSP сервер получает полную статистику кто и когда обращается к ресурсу. Теперь следить за вами будет и CA.
Скорее, когда начнут реально наказывать проекты поменьше, тогда возможно достанется всяким Гугло-фейсбукам.
UFO just landed and posted this here
один проект, с парой миллионов пользователей, успешно проходивший проверку на безопасность каждые пол года
в один прекрасный день, разработчик, для дебага на форме логина поменял POST на GET
код ушел в прод, случайно заметили через пару недель и исправили
следующая проверка тоже прошла успешно :)
в один прекрасный день, разработчик, для дебага на форме логина поменял POST на GET
код ушел в прод, случайно заметили через пару недель и исправили
следующая проверка тоже прошла успешно :)
Спасибо за статью, я начинающий разработчик и как раз задумываюсь о создании своего проекта на стеке VueJS+Django. Как раз думал над аунтефикацией. Много разного предлагают разные авторы, но я уже недели 2 не могу выбрать на чем же остановится.
Склоняюсь к использованию встроенной JWT аунтефикации которая имеется в DRF.
Склоняюсь к использованию встроенной JWT аунтефикации которая имеется в DRF.
Где можно скачать библиотеку аутентификации на php для своего сайта? Какие существуют?
Корневое утверждение статьи абсолютно верно — многие недооценивают сложность авторизации и аутентификации, особенно, при использовании разных способов входа и разных уровней доступа. Поэтому писать их самому абсолютно необязательно — существует огромное количество качественных библиотек и boilplates, решающих эту проблему :). Единственный весомый аргумент в пользу IDaaS — перенос ответственности за личные данные пользователя на третью сторону. Но, как написали выше, ответственность в IT понятие весьма размытое, так что…
Помнится не так давно в одной из самых популярных PHP либ был найден занятный баг — в alg можно было указать none и скрафтить какой угодно токен.
Но в целом с посылом статьи я согласен — чаще самопис и простые решения из коробки просто пугают.
Есть и третий путь. Не писать аутентификацию самостоятельно и не отдавать на откуп неизвестному дяде, который мамой клянётся что у него всё хорошо с безопасностью, он не закроется сам и не отключит вас от своего сервиса по ему одному известной причине или из-за каких-нибудь "санкций" — можно поставить у себя отдельный сервис аутентификации.
Мы часто используем в своих проектах для этой цели Keycloak — он опенсорсный, умеет всё что надо в области в openid/oauth в т.ч. подключение сторонних провайдеров, типа гугла, фейсбука и т.п. А чего не умеет — можно дописать. Мы вот написали к нему провайдеры для всех основных российских соцсетей (https://github.com/playa-ru/keycloak-russian-providers) и даже для ЕСИА (этот пока на гитхаб не выкладывали).
Как по мне — Keycloak очень удобная штука. И пользователи ваши остаются при вас и велосипеды не надо изобретать.
А пользователя хоть кто-нибудь спрашивал?
Захожу на западные сайты — мне предлагают авторизоваться через, например, facebook/google.
Захожу на отечественные — предлагают вк/ок.
Мне придётся во всех (ну ладно, в некоторых) соцсетях регистрироваться для того. чтобы зайти на левый сайт?
Разработчикам для моего удобства приходится поддерживать авторизацию через десяток разных сервисов (или терять аудиторию, если юзер не пользуется нужным сервисом).
Если у меня iOS и нет гуглоучётки? Не сижу в фейсбуке? Если РКН «заблокировал» Телеграм, задев и «Телеграм паспорт»? Если ВК заблокировали вна Украине? Что будет?
Я не смогу зайти на ваш сайт.
А если я не хочу, чтобы в инете сохранилась связь сайт-мой аккаунт в соцсети? Например, при входе со смартфона pornhub просит авторизоваться через ВК. Что-то типа Сбербанк ID / Paypal вообще нет желания привязывать ни к одному сервису, на котором есть возможность оплаты/подписки/покупки (а сейчас, считай, что и нет сервисов, у которых нет платных возможностей или их нельзя было бы прикрутить).
Из-за этого везде, где можно — выбираю «Зарегистрироваться через email». А это значит, что разработчикам, помимо сторонних сервисов, все равно приходится пилить свои велосипеды.
Само собой, пример не показательный, но я не встречал ни одного сайта, на котором была бы нужда зарегистрироваться и не было бы возможности сделать это «по старинке» через email или, хотя бы, номер телефона.
Захожу на западные сайты — мне предлагают авторизоваться через, например, facebook/google.
Захожу на отечественные — предлагают вк/ок.
Мне придётся во всех (ну ладно, в некоторых) соцсетях регистрироваться для того. чтобы зайти на левый сайт?
Разработчикам для моего удобства приходится поддерживать авторизацию через десяток разных сервисов (или терять аудиторию, если юзер не пользуется нужным сервисом).
Если у меня iOS и нет гуглоучётки? Не сижу в фейсбуке? Если РКН «заблокировал» Телеграм, задев и «Телеграм паспорт»? Если ВК заблокировали вна Украине? Что будет?
Я не смогу зайти на ваш сайт.
А если я не хочу, чтобы в инете сохранилась связь сайт-мой аккаунт в соцсети? Например, при входе со смартфона pornhub просит авторизоваться через ВК. Что-то типа Сбербанк ID / Paypal вообще нет желания привязывать ни к одному сервису, на котором есть возможность оплаты/подписки/покупки (а сейчас, считай, что и нет сервисов, у которых нет платных возможностей или их нельзя было бы прикрутить).
Из-за этого везде, где можно — выбираю «Зарегистрироваться через email». А это значит, что разработчикам, помимо сторонних сервисов, все равно приходится пилить свои велосипеды.
Само собой, пример не показательный, но я не встречал ни одного сайта, на котором была бы нужда зарегистрироваться и не было бы возможности сделать это «по старинке» через email или, хотя бы, номер телефона.
Все круто. Вот только недавно несколько раз падал mobilePass(не помню какой сервис под ним). Изза чего были проблемы при подключении к корпоративной сети через vpn.
То есть я правильно понимаю, что ради обеспечения «безопасности» моего маленького сайта мне предлагают дать фейсбуку, гуглу, apple и подобным им компаниям полный доступ к списку моих пользователей? А так же техническую возможность выполнять на моём сайте любые действия от их имени? Я надеялся по заголовку, что нам расскажут про какие-нибудь либы/плагины для apache или nginx, позволяющие стандартизировать процессы регистрации и входа, а здесь такое…
Вот допустим, я пользователь, хочу зарегистрироваться на очередном сайте, example.com. И я вижу, что мне для этого нужно ещё и создать аккаунт на фейб**ке (© Носик), слить им кучу инфы, а потом (и это самое главное) каждый день трястись, чтобы этот fb-аккаунт не забанили «за ботовотство». Потому что если я потреяю этот fb-аккаунт, то в example.com тоже войти не смогу. А фейсбук, по статистике, сейчас в течение 2-3 дней банит 90% аккаунтов с минимально заполненными анкетами и отсутствием активности после регистраиции, поскольку считает их ботами (даже несмотря на привязку к телефону). То есть мне, чтобы сохранить аккаунт на example.com, придётся ещё и каждый день заходить на fb и что-то там искать/писать. А не обойдётесь ли вы, господа с example.com?
Вот допустим, я пользователь, хочу зарегистрироваться на очередном сайте, example.com. И я вижу, что мне для этого нужно ещё и создать аккаунт на фейб**ке (© Носик), слить им кучу инфы, а потом (и это самое главное) каждый день трястись, чтобы этот fb-аккаунт не забанили «за ботовотство». Потому что если я потреяю этот fb-аккаунт, то в example.com тоже войти не смогу. А фейсбук, по статистике, сейчас в течение 2-3 дней банит 90% аккаунтов с минимально заполненными анкетами и отсутствием активности после регистраиции, поскольку считает их ботами (даже несмотря на привязку к телефону). То есть мне, чтобы сохранить аккаунт на example.com, придётся ещё и каждый день заходить на fb и что-то там искать/писать. А не обойдётесь ли вы, господа с example.com?
Как-то вы выборочно читали статью, если увидели в ней только авторизацию через соцсети. Например, упоминание auth0.com вы явно не заметили.
Как-то вы выборочно читали комментарий, если увидели в нём только авторизацию через соцсети. Например, первый абзац вы явно не заметили
Я писал свой комментарий (точнее, как вам правильно заметили, вторую его часть) про фейсбук, потому что какое-то представление о нём имею, а про auth0.com слышу впервые.
Но в любом случае, общий принцип остаётся неизменным: при регистраиции на example.com через auth0.com у меня больше шансов словить бан по дури искусственного интеллекта или самодурству админа, чем при регистрации на example.com напрямую: к ИИ и админу example.com добавляется ИИ и админ auth0.com. Своих данных приходится тоже раскрывать больше. Насколько количественно больше этот риск бана и это раскрытие данных — зависит от реалий деятельности auth0.com (именно от реалий деятельности, а не от того, что они красивыми буковками пишут у себя на главной странице, это не узнаешь без независимого сбора статистики у тех, кто пытался этим auth0.com пользоваться), но в любом случае он больше.
Но в любом случае, общий принцип остаётся неизменным: при регистраиции на example.com через auth0.com у меня больше шансов словить бан по дури искусственного интеллекта или самодурству админа, чем при регистрации на example.com напрямую: к ИИ и админу example.com добавляется ИИ и админ auth0.com. Своих данных приходится тоже раскрывать больше. Насколько количественно больше этот риск бана и это раскрытие данных — зависит от реалий деятельности auth0.com (именно от реалий деятельности, а не от того, что они красивыми буковками пишут у себя на главной странице, это не узнаешь без независимого сбора статистики у тех, кто пытался этим auth0.com пользоваться), но в любом случае он больше.
Особенно весело пользоваться сайтами с авторизацией через сторонние сервисы на чужом компьютере.
Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке. Перед этим, наверняка, придётся деавторизовать хозяина этого компа, а после — выйти из фейсбука, выйти из example.com, да ещё и куки и кеш браузера потереть, если это не очень доверенный компьютер.
Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке. Перед этим, наверняка, придётся деавторизовать хозяина этого компа, а после — выйти из фейсбука, выйти из example.com, да ещё и куки и кеш браузера потереть, если это не очень доверенный компьютер.
Это как раз юзкейс для приватного режима. Хозяина деавторизовать не придется и ваша авторизация сбросится сразу после закрытия приватного окна.
Вы правы. Спасибо, что напомнили про приватный режим, совсем про него забыл.
Он действительно убирает проблему «хозяин компьютера уже зашел в свой аккаунт».
Осталась только проблема «Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке».
Дополню, почему это проблема для меня — поскольку к аккаунту соцсети или того же гугла уже привязано много других сервисов, то и пароли там немного сложнее, чем qwerty12345, и включена 2FA везде, где это возможно. Это обычно означает, что мне надо вспоминать сложный пароль или перепечатывать его из менеджера паролей (если он есть под рукой) и также тащиться за смартфоном (для 2FA).
Если смартфон уже есть поблизости, то обычно нет нужды заходить на example.com с чужого устройства, проще зайти сразу со смартфона.
Плюс тревожности добавляет тот факт, что я не могу гарантировать корректную работу приватного режима на чужом устройстве (необновлённый браузер, кривая реализация приватного режима, кастомные настройки, кастомная сборка браузера, фейковый браузер, прокси, кейлогеры, камера, направленная на клавиатуру и т.д.) и при этом должен вводить пароль от своего важного фейсбучного аккаунта только для того, чтобы попасть на какой-то левый example.com (доступ к которому мне может быть не жаль, пускай перехватывают)
Он действительно убирает проблему «хозяин компьютера уже зашел в свой аккаунт».
Осталась только проблема «Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке».
Дополню, почему это проблема для меня — поскольку к аккаунту соцсети или того же гугла уже привязано много других сервисов, то и пароли там немного сложнее, чем qwerty12345, и включена 2FA везде, где это возможно. Это обычно означает, что мне надо вспоминать сложный пароль или перепечатывать его из менеджера паролей (если он есть под рукой) и также тащиться за смартфоном (для 2FA).
Если смартфон уже есть поблизости, то обычно нет нужды заходить на example.com с чужого устройства, проще зайти сразу со смартфона.
Плюс тревожности добавляет тот факт, что я не могу гарантировать корректную работу приватного режима на чужом устройстве (необновлённый браузер, кривая реализация приватного режима, кастомные настройки, кастомная сборка браузера, фейковый браузер, прокси, кейлогеры, камера, направленная на клавиатуру и т.д.) и при этом должен вводить пароль от своего важного фейсбучного аккаунта только для того, чтобы попасть на какой-то левый example.com (доступ к которому мне может быть не жаль, пускай перехватывают)
Как пользователь, могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
Ну и еще хочу добавить одну идею. Может Яндекс люди читают или еще кто…
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Это расплата за лень. За то, что вы перекладываете труд по регистрации на плечи интернет-магазина и стороннего сервиса авторизации — вы расплачиваетесь своими данными (магазин получает данные о вас, соцсеть — данные о том, что вы пользуетесь этим магазином).
Пока вы считаете, что это адекватная плата за «труд» ввести свой email и пароль (это минимум, конечно, некоторые сайты требуют ещё кучу данных, но их можно заполнить фейками) — пользуйтесь авторизацией через сторонние сервисы.
Приведу аналогию:
вы в оффлайн магазине покупаете холодильник. Вам нужна доставка, т.е., надо сообщить продавцу адрес и имя получателя. Вы можете:
1) самому написать ему адрес и имя
2) дать ему папку, в которой лежат: свидетельство о рождении, фото «с уголком», диплом, школьный альбом, записная книжка со списком друзей, дневник с записями о значимых событиях (поездки, праздники, мероприятия), фотки из отпуска, справка из ЖЭКа, телефон любовницы, копия трудовой… Продавец берёт это всё, выбирает среди этого то, что ему нужно (напомню, ему нужны адрес и имя; если речь не о холодильнике, а о продукции 18+, то ещё может глянуть на св-во о рождении). Вам ничего делать не надо (ну только таскать в магазины эту папку)
P.s. пример выдуманный, специально гипертрофирован и подогнан под ваши два комментария. Ни капли не против того, чтобы сторонние сервисы выдавали токены, которые нельзя было бы связать с основным аккаунтом, но:
— сайту обычно нужен не только токен, но ещё и имя; некоторым — возраст; ещё может понадобиться email для связи; кто-то подтягивает фото из соцсети; и т.д. Хотелось бы это контролировать, но полный контроль — это огромная простыня галочек, какие данные предоставлять сайту, она неудобна, поэтому, у кого это есть, отдают данные более-менее связными блоками (например, показать общую информацию / показать друзей / показать подписки / дать возможность писать друзьям / и т.д.), т.е., чтобы показать только имя — нужно разрешить ещё доступ к городу/дате рождения и т.д. В деталях могу ошибаться, поскольку стараюсь не пользоваться такими сервисами.
— я, как пользователь, не хочу знать, какая соцсеть сегодня выдаёт обезличенные токены, а какая — предоставляет доступ ко всем данным, да ещё и разрешает постить друзьям от моего имени. Мне не интересно в этом разбираться, я просто хочу зарегистрироваться на сайте «и чтобы без последствий».
А в организации, поскольку у нас… ADТут можно не продолжать )
Да, мне лень. Я потому и привел аналогию с кредитной картой. Мне лениво носить с собой нал, отсчитывать деньги, проверять сдачу. Кроме того, оплатить картой гораздо быстрее.
И поэтому я пользуюсь картой. Но вот гугл озаботился вопросом о сохранении приватности данных моей карты и генерирует новый номер для каждой покупки, хотя физическая карта у меня одна и все платежи приходят на нее.
Почему бы так же не сделать с соцсетями? По мне так это было бы удобно.
И поэтому я пользуюсь картой. Но вот гугл озаботился вопросом о сохранении приватности данных моей карты и генерирует новый номер для каждой покупки, хотя физическая карта у меня одна и все платежи приходят на нее.
Почему бы так же не сделать с соцсетями? По мне так это было бы удобно.
Всё, что вы написали про карты — регулируется платежными системами, стандартами PCI DSS, банками. Например, Google не должен хранить реквизиты вашей реальной карты (но можно навыпускать виртуальных; или получить от банка-эмитента кучку одноразовых токенов для оплаты).
Авторизация пользователей — не регулируется никем. Сейчас мы можем только писать в комментариях «хотелось бы вот такую фишку...», но никто не обязан её реализовывать. Но если у кого-то это уже будет и все будут об этом говорить, тогда «отстающие» тоже реализуют (как это случилось с e2e шифрованием в мессенджерах).
Но всё равно останется необходимость передавать какие-то данные о вас (см. постскриптум предыдущего комментария)
Авторизация пользователей — не регулируется никем. Сейчас мы можем только писать в комментариях «хотелось бы вот такую фишку...», но никто не обязан её реализовывать. Но если у кого-то это уже будет и все будут об этом говорить, тогда «отстающие» тоже реализуют (как это случилось с e2e шифрованием в мессенджерах).
Но всё равно останется необходимость передавать какие-то данные о вас (см. постскриптум предыдущего комментария)
Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.
Ниже уже подсказали, что Apple как раз подобный сервис реализует. Думаю, должны, со временем, подтянуться и остальные. С нетерпением жду подобного от google.
Ниже уже подсказали, что Apple как раз подобный сервис реализует. Думаю, должны, со временем, подтянуться и остальные. С нетерпением жду подобного от google.
Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.
Да поправят меня более опытные хабраюзеры, ежели не прав, но это не совсем так. Номер виртуальной карты генерируется один раз при привязке карты, его должно быть видно в интерфейсе приложения и в чеках (в виде «номер карты ******1234»).
Если я правильно помню процесс, виртуальную карту генерирует тоже не гугл, а банк.
В момент привязки приложение «знает», что только что сгенерированную карту ****1234 надо привязать к физической карте ****5678, поэтому в приложении вы можете видеть часть номера физической карты, думая, что её данные хранятся в телефоне.
Но, возможно, это относится не к GooglePay, а к какому-то другому *Pay
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
BTW, в Azure AD так и сделано: по умолчанию (из идентифицирующих) передается только клейм sub, который, весьма неожиданно, уникален для клиентского приложения (т.е. разные сайты, использующие этот логин, получат разные идентификаторы). Чтобы получить сквозной идентификатор (oid), нужно запрашивать дополнительный профиль.
Sign in with Apple тоже может передавать не емейл пользователя, а сгенеренный емейл.
C азуром немного не понятно. Приложение просто попросит подтвердить доступ к email для регистрации и все.
А вот Эпл, действительно, делает то, о чем я думал, молодцы.
А вот Эпл, действительно, делает то, о чем я думал, молодцы.
Приложение просто попросит подтвердить доступ к email для регистрации и все.
Это если нужен емейл, а не просто аутентификация. А когда "не хочу вводить логин-пароль" — это как раз аутентификация, емейл тут ни при чем.
Ну, большинство сервисов хотят получить email. Так чтобы «просто аутентификация» даже и не припомню чтобы встречал. Просто будет форма при регистрации типа «разрешить доступ к таким-то полям в профайле» и все. Откажись — и регистрация не пройдет.
Так собственная аутентификация, силами самого ресурса — обычно email в качестве логина. Вот его и спрашивают, чтобы все более-менее единообразно было с точки зрения учетной записи.
Не, это не потому. Магазины хотят email чтобы иметь связь с клиентом.
А вот я, как клиент, хотел бы, чтобы для каждого магазина, в котором я регистрируюсь, сервис генерировал уникальный «виртуальный» email, примерно по тому же принципу, что и sub в Azure AD, который мы обсуждали выше.
Т.е. на claim email отдавалось бы что нибудь типа 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com, а не мой реальный email. При этом, когда магазин отправлял бы что нибудь на этот ящик, все автоматически бы форвардилось в мой реальный ящик.
А вот я, как клиент, хотел бы, чтобы для каждого магазина, в котором я регистрируюсь, сервис генерировал уникальный «виртуальный» email, примерно по тому же принципу, что и sub в Azure AD, который мы обсуждали выше.
Т.е. на claim email отдавалось бы что нибудь типа 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com, а не мой реальный email. При этом, когда магазин отправлял бы что нибудь на этот ящик, все автоматически бы форвардилось в мой реальный ящик.
И все это только ради того, чтобы нельзя было понять, что 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com не совпадает с a49a9740-b6d7-11ea-8b6e-0800200c9a66 и не является на самом деле username@google.com?
Уже упомянутая генерация номера карты для каждой покупки — это же костыль, вставленный для обхода уязвимости в системе, которую нельзя убрать из соображений совместимости. (А именно той уязвимости, что почему-то делает просто номер карты чем-то ценным, угрожающим мошенническим снятием денег и поэтому нуждающемся в защите). И всей это морокой с токинезацией никто бы не занимался, если бы этой уязвимости не было.
Да, только для этого, т.е. для анонимизации email. Ну и плюс, бывает полезно узнать, кто сливает твои данные и иметь возможность закрыть этот адрес безболезненно для остального.
Ну и плюс, бывает полезно узнать, кто сливает твои данные и иметь возможность закрыть этот адрес безболезненно для остального.
… то есть вам надо не только чтобы где-то создавался адрес, но еще и чтобы вы видели, какой адрес создался, кому передался, и на какой адрес в реальности пришло письмо.
Так это было бы естественно. Я же вижу в своем профайле список сайтов и приложений, которые я авторизовал. Можно было бы там же рядом показывать и уникальный email.
На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
А когда на этот адрес начнет валить спам, будет сразу понятно, из какого сайта или приложения произошла утечка.
На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
А когда на этот адрес начнет валить спам, будет сразу понятно, из какого сайта или приложения произошла утечка.
Так это было бы естественно.
Вопрос не в естественности, а в том, что это тоже надо реализовать.
На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
Это от реализации рилея зависит. Вы же не ожидаете, что ваш провайдер аутентификации и ваш почтовый провайдер — всегда одно и то же? Ну так почему ваш почтовый провайдер должен что-то знать про адреса, которые предоставлены провайдером аутентификации?
Так все надо реализовывать. С неба оно не упадет. Все ручками, ручками :-).
Ловить меня на максимы не надо ;-). Не всегда, но достаточно часто. Google, outlook, vk, yd etc. Рискну предположить, что в большинстве случаев для популярных сервисов это именно так и есть.
Кроме того, совсем не обязательно иметь полноценный почтовый сервис. Достаточно правильно организовать форвардинг. Так что FB, например, может запросто в своих токенах писать 4c78b3a1-b569-4c46-a05b-911411e0543e@fb.com в качестве email при регистрации и пересылать все на реальный адрес.
Ловить меня на максимы не надо ;-). Не всегда, но достаточно часто. Google, outlook, vk, yd etc. Рискну предположить, что в большинстве случаев для популярных сервисов это именно так и есть.
Кроме того, совсем не обязательно иметь полноценный почтовый сервис. Достаточно правильно организовать форвардинг. Так что FB, например, может запросто в своих токенах писать 4c78b3a1-b569-4c46-a05b-911411e0543e@fb.com в качестве email при регистрации и пересылать все на реальный адрес.
Так все надо реализовывать. С неба оно не упадет. Все ручками, ручками
Платить за это кто будет?
Хех, большинство из популярных сервисов, используемых для регистрации на сайтах (google, fb, vk, yd, outlook etc), для пользователей бесплатны. Более того, идет серьезная борьба за клиента путем предоставления новых сервисов и улучшения существующих. Насколько я понимаю, существуют различные пути монетизации. Реклама, продажа статистики, продажа «премиальных» сервисов и т.д.
Так что вопрос тут не в том, кто будет платить, а будет ли такой сервис востребован и интересен пользователям. Я вот, полагаю, что будет. И раз этим занялся apple, значит я, видимо, не столь одинок в своих выводах.
Так что вопрос тут не в том, кто будет платить, а будет ли такой сервис востребован и интересен пользователям. Я вот, полагаю, что будет. И раз этим занялся apple, значит я, видимо, не столь одинок в своих выводах.
Ну, большинство сервисов хотят получить email.
Хотеть-то можно сколько угодно. А вот нужен ли он им?
Просто хотеть, чтобы сервис аутентификации предоставлял еще и сервисы анонимных почтовых записей — это немножечко через край.
Ну, обычно распространенные сервисы уже и так предоставляют почтовый ящик. Не вижу большой сложности в генерации виртуальных ящиков для каждого клиента. В конце коцов, сервис анонимных CC гугл же предоставляет.
Ну, обычно распространенные сервисы уже и так предоставляют почтовый ящик.
Или нет. Фейсбук не предоставляет. Azure AD не предоставляет.
Не вижу большой сложности в генерации виртуальных ящиков для каждого клиента.
Вы готовы за это платить?
Именно только за эту фичу — нет.
За эту фичу в пакете типа «премиальный» — да.
Я сейчас плачу за свои сервисы почты, диска и т.д.
Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз. Даже не знаю, на чем он зарабатывает.
Azure AD клиенту в данном случае не нужен. Достаточно обычного hotmail.
За эту фичу в пакете типа «премиальный» — да.
Я сейчас плачу за свои сервисы почты, диска и т.д.
Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз. Даже не знаю, на чем он зарабатывает.
Azure AD клиенту в данном случае не нужен. Достаточно обычного hotmail.
Именно только за эту фичу — нет.
Вот поэтому этого и не будет.
Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз.
Не каждый раз, а при подключении карты.
И да, "бесплатно для вас" не означает "бесплатно для всех".
Ну, поживем — увидим. Раз у apple подобное появилось — появится и у других. Конкуренция. Я, знаете, и за какой нибудь excel отдельно платить не стал был. А в пакете office365 — почему бы и нет? К тому же, если бы мои предпочтения точно предсказывали бы поведение рынка, я бы уже наверное отбоя не знал от маркетологов, желающий отдать мне большие $$$ за мое мнение по поводу их продуктов :-). Скажу даже еще более страшное. Мне даже и даром не нужна продукция яблочной фирмы. Ну разве чтобы продать и купить что нибудь нормальное (типа Lenovo или Pixel). Удивительно, как эта фирма до сих пор не разорилась? Я же совершенно не готов платить за их продукты и сервисы :-))).
Не каждый раз, а при подключении карты.
Я так понимаю, имелась в виду EMV Payment Tokenisation
Насколько именно можно считать, что там 'при каждом платеже номер карты генерируется' — вопрос несколько спорный, но рекламируется оно именно так.
Почитал комменты, и не могу нарадоваться на то, что аутсорсинг аутентификации неопределённому кругу третьих лиц не мне одному кажется долбаным безумием.
Да, безусловно, пароли и управление ими очень сложная тема. Если в кратком изложении, займёт в книжке страницы три, а если с объяснениями, то аж целых десять. Не всякий осилит, это правда. Но разве это повод приказным тоном загонять всех в гиперцентрализованные сервисы аутентификации?
Когда я предоставляю услуги (особенно платные), а мой клиент их потребляет, это дело (а) моё, (б) клиента, и (в) больше ничьё. Я обязался предоставлять сервис, и это область моей ответственности. Клиент обязался следовать условиям предоставления сервиса, и это его область ответственности. И тут внезапно появляется третье лицо неизвестного происхождения с грамотно прописанным отказом от ответственности, которое для меня неотличимо от всех моих пользователей. И если кто-то имеет возможность прийти к этому третьему лицу и сделать предложение, от которого невозможно отказаться, этот "кто-то" тоже получает возможность быть для меня неотличимым от любого из моих пользователей.
Учитывая, что ИТ-гиганты почти всегда включают режим открытых дверей для всех спецслужб всех государств, а те в свою очередь бывает не брезгуют перепродавать данные кому попало, оно всё начинает как-то совсем нехорошо попахивать.
Implicit flow устарел. Следует использовать Authorization Code with PKCE.
И никто не написал, что все эти сервисы далеко не бесплатны — вплоть до 10$ за юзера в месяц!
Мой ребенок безумно хотел одну игруху на планшете, но вот незадача, регистрация только через фейсбук. Ну не хочу я вешать ее на свой акк. Но дите так просило, что создала акк для него. Так нас забанили сразу же, причем по непонятным причинам. Итог истории: при всем безумном желании клиента, мы не в проекте.
Sign up to leave a comment.
Не стоит создавать собственные решения для аутентификации пользователей