company_banner

Не стоит создавать собственные решения для аутентификации пользователей

Автор оригинала: Alessandro Segala
  • Перевод
Автор статьи, перевод которой мы публикуем, предлагает прекратить писать собственный код для аутентификации пользователей. Он полагает, что пришло время внедрять более безопасные решения, которые, если даже не говорить о других их плюсах, позволяют экономить время и деньги.

В большинстве приложений необходима некая подсистема аутентификации пользователей. Может быть вы — программист, работающий в крупной компании над бизнес-приложениями, в которых требуется ограничить доступ к неким материалам неавторизованным сотрудникам компании и нужно проверять разрешения этих пользователей. Возможно вы пишете код новой SaaS-платформы, и вам нужно, чтобы её пользователи могли бы создавать учётные записи и управлять ими.



В обоих этих случаях, да и во многих других, вы, вероятнее всего, начнёте работу над приложением с создания подсистем аутентификации и средств для управления пользователями. То есть, как минимум, создадите форму регистрации и страницу для входа в систему. Подсистемы аутентификации — это именно то, что чаще всего просят реализовать веб-разработчиков, занятых некими проектами. Но, несмотря на это, такие подсистемы, это ещё и то, на что обычно обращают очень мало внимания.

Разработка безопасной системы аутентификации пользователей — это по-настоящему сложная задача. Она гораздо масштабнее, чем многие думают. Эту задачу очень легко решить неправильно. Хуже того: ошибки при создании подсистем аутентификации могут повлечь за собой катастрофические последствия. В базовую структуру систем аутентификации и управления пользователями входит всего несколько форм. Из-за этого создание подобных систем может показаться весьма простым делом. Но, как известно, дьявол кроется в деталях. Нужно немало потрудиться для того чтобы сделать такие системы безопасными (и, когда это возможно или даже необходимо, учесть в них требования конфиденциальности персональных данных).

IDaaS


К счастью, у современного веб-разработчика нет необходимости в развёртывании собственной системы для аутентификации пользователей и для управления ими. Сейчас, в 2020 году, существует множество хороших IDaaS-решений (Identity as a Service, идентификация как сервис). Применение таких решения значительно упрощает оснащение веб-проектов возможностями по аутентификации пользователей.

Вот несколько популярных IDaaS-проектов (в алфавитном порядке): Auth0, Azure AD, Google Identity Platform и Okta.

Кроме того, существуют поставщики идентификационной информации, основанной на чём-то наподобие учётных записей пользователей социальных сетей. Это, например, Apple, Facebook, GitHub, Twitter. Разработчикам очень легко внедрять в свои проекты возможности этих систем. Тот, кто работает с провайдерами аутентификации, может очень быстро создать соответствующую подсистему приложения, имеющую доступ к большому массиву данных о пользователях. Но иногда взаимодействие проекта с провайдерами может иметь негативное влияние на конфиденциальность данных пользователей.

На самом деле, нельзя назвать реальную причину, по которой некоему разработчику не стоит пользоваться услугами поставщика идентификационной информации. Работа с подобным сервисом позволит сэкономить массу времени, которое можно будет потратить на разработку самого приложения. Эти сервисы дают разработчику, без каких-либо существенных усилий с его стороны, множество возможностей. А самое важное здесь то, что они гораздо безопаснее, чем некое самописное решение.

Чем больше пользователей — тем безопаснее решение


Большинство поставщиков идентификационной информации предлагаю дополнительные возможности, касающиеся безопасности. Такие, как поддержка многофакторной аутентификации (MFA, multi-factor authentication), поддержка сертификатов безопасности или ключей (в том числе — U2F, FIDO2, WebAuthn и прочее подобное).

Не стоит недооценивать важность этих технологий. В соответствии с отчётом Microsoft, включение MFA позволяет предотвратить до 99,9% атак на учётные записи.

Однако в деле использования сторонних сервисов аутентификации вместо собственных решений есть ещё один аспект, менее известный. А именно, речь идёт о том, что благодаря очень большому количеству пользователей, с которыми работают подобные сервисы, они могут отслеживать паттерны поведения злоумышленников и легче предотвращать атаки на учётные записи.

Большие провайдеры, благодаря тому, что у них имеются миллионы пользователей, которые ежедневно выполняют бесчисленное множество входов в систему, собирают достаточно данных для построения моделей, основанных на возможностях искусственного интеллекта. Такие модели позволяют лучше идентифицировать подозрительные паттерны поведения.

Например, предположим, один из ваших пользователей, живущий в Канаде, входит в систему из дома. А через два часа вход в тот же аккаунт выполняется из Украины. Сервисы поставщика идентификационной информации способны счесть такое поведение подозрительным и могут либо сразу запретить вход, либо предложить пользователю пройти дополнительную верификацию (например, с использованием MFA-токена). Они, кроме того, могут уведомлять пользователей, которые подверглись атаке, или системных администраторов, а возможно — и тех, и других.

Распространённые возражения, высказываемые об использовании сторонних сервисов аутентификации


▍На самом деле, не так уж и сложно создать собственную систему для аутентификации пользователей и для управления ими


Формы для регистрации в проекте и для входа в него — это лишь одна сторона «медали» системы аутентификации. Разработчику, создавая подобную систему, придётся решить гораздо больше задач, чем разработка пары форм.

Для начала, нужно решить дополнительные задачи, связанные с управлением пользователями. Такие, как применение политик безопасности паролей, создание системы подтверждения адресов электронной почты или номеров телефонов, разработка механизмов безопасного сброса паролей. Правда, в том, что касается управления паролями, прошу всех прислушаться к NIST и не оснащать систему неотключаемым механизмом, работа которого направлена на то, чтобы срок действия паролей истекал бы по прошествии определённого времени. Не стоит и принуждать пользователей к тому, чтобы они создавали бы «креативные» пароли, содержащие символы верхнего и нижнего регистра, специальные символы и так далее.

При проектировании подобных систем нужно держать в голове массу мелких деталей. При этом тут очень легко совершить ошибки. Огромные компании были замечены в том, что они, например, не хешируют пароли в своих базах данных (или хешируют их неправильно), в том, что они случайно сбрасывают пароли в лог-файлы в виде обычного текста, в том, что их механизмы сброса паролей очень легко взломать, пользуясь методами социальной инженерии. Этот список можно продолжать.

То, что правильное управление паролями, это — непростая задача, не должно никого удивлять. А вы знали о том, что управление именами пользователей — это тоже сложно? Например, тот факт, что имена пользователей выглядят одинаково, ещё не означает, что система, при их сравнении, сочтёт их таковыми. В этом выступлении 2018 года высказаны ещё некоторые интересные идеи, касательно того, что может пойти не так при работе с такими «простыми» сущностями, как имена пользователей.

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

▍Использование сервисов аутентификации пользователей не всегда бесплатно, особенно — для крупных проектов


А знаете о том, что ещё, связанное с безопасностью, не является бесплатным? Необходимость возмещать ущерб от взломов. Этот ущерб может быть выражен в денежной форме, если те, кого взломали, понесли какие-то потери, это может быть время, потраченное на срочную доработку собственного проекта, это, что так же неприятно, как и другие последствия взломов, потеря доверия пользователей.

И даже если не говорить о взломах, реализация безопасной системы аутентификации и управление ей, работа с базой данных пользователей и решение прочих подобных задач, предусматривает трату времени и ресурсов. Это — и ресурсы, уходящие на разработку системы, и ресурсы, необходимые на её поддержание в работоспособном состоянии.

▍Я — очень опытный разработчик, поэтому знаю о том, как создать безопасную систему аутентификации


Для начала — примите поздравления. Дело в том, что настоящие знания о том, как создаются безопасные системы аутентификации, есть у гораздо меньшего числа разработчиков, чем вы думаете, и чем можете ожидать.

Но если вы и правда — опытнейший разработчик, тогда, вполне возможно, ваше время лучше потратить на реализацию других частей приложения, которые приносят пользователям этого приложения какую-то ощутимую пользу.

Или, если вы и правда хотите создать собственную систему аутентификации, то вы можете поразмыслить о поступлении на работу в компанию, вроде Microsoft, Auth0 или Facebook с целью улучшения их систем идентификации пользователей.

▍Я хочу держать под контролем пользователей моего проекта


Я, рассматривая данную идею, сразу хочу задать вам вопрос: «А зачем вам это?». Вполне возможно то, что вам это по-настоящему не нужно. Ну, если только вы не разрабатываете новый Facebook. В таком случае данные о пользователях — это ваш самый главный актив, и чем больше таких данных вы соберёте, тем лучше.

Кроме того, чем больше данных о пользователях вы собираете — тем выше вероятность того, что вам придётся потратиться на то, чтобы привести свою систему в соответствие с некими правилами, вроде GDPR. Далее, если вы храните большие объёмы данных о пользователях, это может утяжелить последствия взломов и потребовать дополнительных расходов на устранения этих последствий.

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

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

С чего начать?


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

Для начала — хорошая новость. Она заключается в том, что все четыре вышеперечисленных провайдера (Auth0, Azure AD, Google Identity Platform, Okta), да и многие другие, используют одни и те же протоколы: OpenID Connect / OAuth 2.0. Это — современные стандартные протоколы, клиентские библиотеки для поддержки которых существуют практически для всех языков программирования и фреймворков.

Для того чтобы приступить к использованию услуг какого-нибудь поставщика идентификационной информации, нужно, если не вдаваться в детали, сделать следующее:

  1. Зарегистрируйте приложение у поставщика идентификационной информации. Вам, после регистрации, выдадут идентификатор (Application ID, Client ID) и секретный ключ (Secret Key, Client Secret).
  2. Задайте разрешения, необходимые вашему приложению. В дополнение к тому, что приложению будет доступен профиль пользователя, вы, что зависит от выбранного провайдера, сможете получить доступ к гораздо большему объёму данных. Сюда может входить, например, доступ к сообщениям пользователей и доступ к их облачному хранилищу (например — через Office 365 или G Suite).
  3. Интегрируйте клиентскую библиотеку сервиса аутентификации в свой проект.

Я не стану пытаться рассказать в подробностях о том, как именно работает механизм OpenID Connect. Но, в целом, работа с сервисами аутентификации выглядит так:

  1. Приложение перенаправляет пользователя на страницу провайдера аутентификации.
  2. Пользователь аутентифицируется и перенаправляется на страницу вашего приложения.
  3. Приложение получает JWT-токен.

JWT-токен, криптографически подписанный и имеющий ограниченный срок действия, может быть использован для управления сессиями пользователя. То есть, до тех пор, пока токен действителен, если приложение получает его в запросе, оно может считать этот запрос поступающим от пользователя, которому принадлежит токен.

Тот же токен содержит некоторые сведения о пользователе. Набор этих сведений зависит от используемого сервиса аутентификации. Обычно это — имя пользователя, адрес его электронной почты, его идентификатор.

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

Как уже было сказано, JWT-токены криптографически подписаны. Поэтому вы, проверяя подпись токена, можете быть уверенными в том, что никто не подменил сведения о пользователе, которые содержатся в токене.

Использование OpenID Connect в клиент-серверных приложениях


То, как именно в конкретном приложении будет использоваться механизм OpenID Connect, сильно зависит от того, с использованием какого языка и фреймворка создано приложение.

На сайте jwt.io можно найти исчерпывающий список библиотек, которые можно использовать для верификации JWT-токенов.

Для некоторых стеков технологий, кроме того, можно воспользоваться решениями более высокого уровня. Например — это, в среде Node.js/Express, express-jwt или passport.

Использование OpenID Connect на статических сайтах или в нативных приложениях


Статические веб-приложения (их ещё называют «JAMstack-сайтами») и нативные приложения (то есть — настольные или мобильные приложения) тоже могут пользоваться OpenID Connect, но делается это немного не так, как в случае с обычными веб-проектами. В спецификации OAuth 2.0 это называется «implicit flow», или получение токена доступа напрямую от пользователя.

При таком подходе не нужно использовать механизм, в котором применяется секретный ключ (Client Secret). Дело в том, что приложение выполняется на клиенте, поэтому не существует безопасного способа распространения подобных ключей. Здесь применяется следующая последовательность действий:

  1. Приложение перенаправляет пользователя на аутентификационную конечную точку, проверяя, чтобы строка запроса содержала бы scope=id_token.
  2. Пользователь выполняет аутентификацию, пользуясь возможностями поставщика идентификационной информации.
  3. Пользователя перенаправляют к приложению, JWT-токен сессии прикрепляется к URL страницы в виде URL-фрагмента (URL-фрагмент — это то, что следует за знаком #). Он находится в поле, называемом id_token.
  4. Приложение получает JWT-токен из URL-фрагмента и проверяет его. Если токен успешно проходит проверку, пользователь считается аутентифицированным, а это значит, что приложение может использовать сведения о пользователе из токена.

Для того чтобы проверить JWT-токен в статическом веб-приложении можно использовать модуль idtoken-verifier. Настольные и мобильные приложения могут использовать похожие библиотеки. Конкретная библиотека зависит от технологии, использованной при разработке приложения.

При разработке клиент-серверных проектов, таких, как статические веб-ресурсы или нативные приложения, важно обеспечить то, чтобы токен был бы подписан с использованием RSA-SHA256 (в заголовке токена alg должно быть записано RS256). Речь идёт об использовании механизма асимметричного шифрования: поставщик идентификационной информации подписывает токены с использованием секретного ключа, а приложение может проверить токен с использованием публичного ключа. Ещё один распространённый алгоритм, применяемый для подписи токенов, это HMAC-SHA256 (или HS256). Тут используется симметричное шифрование, для подписи и проверки токенов применяется один и тот же ключ. Проблема тут в том, что нельзя организовать безопасное хранение подобных ключей в клиентских приложениях.

Затем клиентское приложение может использовать полученный и проверенный JWT-токен в запросах, выполняемых к серверным API. Обычно токены передают либо в заголовке Authorization, либо используя куки-файлы. В данном случае JWT функционирует как любой другой токен сессии, но он, при этом, ещё и содержит сведения о пользователе.

Серверный API, получив запрос, ищет в нём токен. Обнаружив токен, сервер снова его верифицирует. Если токен успешно проходит проверку (и если срок его действия ещё не истёк), сервер может счесть пользователя аутентифицированным и может воспользоваться идентификатором пользователя, взятым из токена.

Какие механизмы аутентификации пользователей применяете вы?



RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 77

    0
    Спасибо за перевод, не хватает только примеров кода. А в целом подход стар и в свое время широко раскручивался в виде отказа от собственной авторизации по логину-паролю, отдавая этот функционал стороннему сервису, который после авторизации отдаст токен. Маппинг в собственной базе при этом происходит либо по содержащемуся в токене id, либо по email.

    На практике используется широко и недостатков не так уж и много — только затраты времени на запросы в сторонний сервис для валидации токена и возня с апи различных сервисов и их схемами работы. Из библиотек могу посоветовать www.passportjs.org, но единую схему работы для нескольких провайдеров он не предоставляет, код будет выглядеть довольно перегруженным.
      +2
      Статья правильная в том смысле, что проверка имени/пароля и связанные с этим заботы не такие уж простые вещи и для небольших проектов гораздо разумней использовать чужие решения.

      Но уж очень резануло про некие правила GDPR: использование чужой аутентификации усложняет соответствии GDPR, вы ведь начинаете передавать данные пользователя третьим лицам, возможно в другую юрисдикцию со своими правилами обработки. А ответственность за все неправомерное использование этих данных будет на вас.

      Посыл того, что при этом у вас появляется возможность хранить меньше персональных данных он хороший, но неверный. Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше! По сути «спихнуть» на провайдера получается только хранения пароля.
        0
        > вы ведь начинаете передавать данные пользователя третьим лицам

        Но постойте, ведь все наоборот, это эти некие третьи лица начинают вам передавать (с согласия пользователей) эти данные, разве нет? А вы только используете их для аутентификации пользователя и авторизации запросов.
        Я плотно работал только с google sign-in но там на бэкенде даже запросов на валидацию идентити как таковых почти не происходит — полученный idToken расшифровывается/подтверждается локально скачанными ключами, которые экспайрятся конечно но не ежесекундно и даже не ежеминутно.

        > Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше

        Вам придется хранить какой-либо идентификатор пользователя, удобный пользователю для логина. Особенно если хочется иметь хотя бы формальную верификацию. Email там или никнэйм (хотя можно и заморочиться и сохранять только хэш конечно, но кто ж будет этим заниматься). И пароль в каком-то виде тоже придется хранить. В случае стороннего провайдера у себя можно вообще хранить только идентификатор или даже хэш от идентификатора. При этом в UI все еще удобно показывать и аватарку и имя с фамилией, если сторонний провайдер выдает эту информацию при логине.
          0
          С точки зрения бекенда может быть, но пользователь приходит не к нему, а к некоторому сервису, проекту. Представьте себе, что вы разрабатываете аналог порнохаба, как вы считаете, комфортно ли будет пользователю проходить аутентификацию через гугль/фейсбук/ГосУслуги?
            +1
            аналог порнохаба, как вы считаете, комфортно ли будет пользователю проходить аутентификацию через гугль/фейсбук/ГосУслуги?
            Ответ и так известен и даже пример есть, собственно тот самый порнохаб для рф просит авторизацию через ВК и находился как минимум один способ узнать кто использовал вход ВК для входа на порнохаб.
        +3

        Статья очень сильно мешает термины аутентификации(процесс проверки истинности сущности пользователя), и авторизации(процесс проверки наличия доступа у пользователя).


        Первое: Я полностью согласен по поводу "велосипедов". Если вы не ветеран семи морей аутентификации и авторизации, то вам лучше даже не стоит начинать изобретать свое. Наши же 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/

          +1
          Существенной частью вопроса «кто это?» может быть вопрос «как к этому отнесутся пользователи», потому что в определенных ситуациях, доля тех потенциальных пользователей, кто не захочет авторизоваться через соцсети вообще или через какую-то определенную соцсеть, может оказаться существенным. В этом могут быть замешаны самые разные мотивы, от откровенной паранойи до, например, политической аффилированности поставщика сервиса аутентификации (условно, «ВК = ФСБ» или «Google = коммунисты», смотря что реально может волновать целевую аудиторию).
          +1

          JWT-токен это как ИТ-технологии

            +3
            моделей, основанных на возможностях искусственного интеллекта. Такие модели позволяют лучше идентифицировать подозрительные паттерны поведения.

            Например, предположим, один из ваших пользователей, живущий в Канаде, входит в систему из дома. А через два часа вход в тот же аккаунт выполняется из Украины.

            Для этого действительно нужны модели искусственного интеллекта?..

              0
              Скорее просто веса давать разным изменениям:
              • Новый IP: +1 к подозрительности
              • Новый провайдер: +2 к подозрительности
              • Новая страна: +3 к подозрительности
              • Новое устройство: +10 к подозрительности

              А в конце задать уровни реагирования и если порог пройден, выдавать дополнительную защиту типа проверки капчи или второго фактора. Примерно так сделано у AWS Cognito в Advanced Security Features.
                0
                Или ИИ или блокчейн, иначе инвесторы денег не дадут.
                0

                А есть IdaaS сервис, который хостится в России?

                  –2
                  Свой велосипед знаешь по косточкам, а что там под капотом у сторонних решений, кто знает?
                  Почему такой аргумент не рассматривается в пользу своего решения?
                    0
                    А для чего это знать? Юзер авторизуется в стороннем сервисе, на бэк приходит токен, валидируешь его в стороннем сервисе и получаешь минимальный набор данных — email, id, срок действия токена. Формат поступивших данных, конечно, лучше провалидировать, но никакой опасности эта схема не представляет.

                    Очевидные недостатки лежат в другой плоскости — это доступность сервиса (и время отклика) и открытость информации. Так, сервис авторизации узнает, в какое время определенный человек (его регион, характеристики системы и часто имя, сохраненное во внутренней базе этого сервиса, телефон, email и т.п. — если брать например авторизацию через сервисы Google) заходил на определенный сайт и примерное время его пребывания (по количеству запросов на верификацию токена от нашего бэка). То есть подобные системы — часть «ока большого брата», которое в свои bigdata-хранилища собирает информацию о людях и их предпочтениях. А разработчики с удовольствием предоставляют эту информацию, так как реализовывать шифрование паролей и систему против взлома довольно морочно для проектов не-энтерпрайз уровня. Энтерпрайзные же приложения в большинстве случаев все равно используют один из сервисов аналитики (или несколько через GTM), так что в любом случае предоставляют эти данные, только через другой канал.

                    На самом деле это довольно резонный консерн, к которому серьезно относятся в приложениях, требующих высокого уровня конфиденциальности, но в остальных случаях никто особо не заморачивается.
                      +1
                      Очевидные недостатки лежат в другой плоскости


                      Я бы добавил
                      — logout сделать нельзя или очень сложно
                      — вместо безопасной cookie у нас токен, который легче стащить
                      — refresh токен, аналог пароля, нужно где-то хранить, чаще всего в plain text
                      — надо дополнительно заморочиться и синхронизировать данные пользователя, которые получаем из сервиса при логине
                      — настройка обмена токенами это всегда боль, у каждого сервиса есть свой глючный SDK, который трактует OAuth/OpenID Connect по своему
                        0

                        Вы бы почитали хоть про oauth...


                        — logout сделать нельзя или очень сложно


                        стереть токен не сложно


                        — вместо безопасной cookie у нас токен, который легче стащить


                        токен положить в безопасную куку


                        — refresh токен, аналог пароля, нужно где-то хранить, чаще всего в plain text


                        зашифровать и посолить, если припекло


                        — надо дополнительно заморочиться и синхронизировать данные пользователя, которые получаем из сервиса при логине


                        всмысле, а если сами делаете то заморачиваться не надо? данные от юзера сами валятся в открытый порт?))


                        — настройка обмена токенами это всегда боль, у каждого сервиса есть свой глючный SDK, который трактует OAuth/OpenID Connect по своему


                        Вот это единственное тут верное

                          0
                          стереть токен не сложно

                          даже не жестком диске хакера, который ваш токен перехватил?

                          токен положить в безопасную куку

                          Это очень правильная идея. После этого нужно будет еще руками написать код, который этот токен будет рефрешить, обращаясь в IDaaS.

                          зашифровать и посолить, если припекло

                          Нужно периодически этот refresh token посылать в IDaaS, а значит надо уметь его расшифровывать, а значит ключ доступен приложению, а значит и хакеру, который в него влез.

                          всмысле, а если сами делаете то заморачиваться не надо? данные от юзера сами валятся в открытый порт?))

                          Если база юзеров у вас, а не в IDaaS, то данные юзера вот так получаются.
                          select * from users where password_hash = @hash and email = @email;
                          
                            –1
                            стереть токен не сложно

                            Стереть где? И что вам это даст?

                          +5
                          А сам факт необходимости заставлять юзера авторизоваться в каком-то абсолютно левом с его точки зрения сервисе никого не смущает? Это может быть сколь угодно безопаснее, но выглядит прям фу-фу-фу, плюс юзабилити под большим вопросом.
                            +1
                            Точно, тоже хотел про это упомянуть) Авторизация через модальные окна работает не везде — в мобильных устройствах и при включенных блокировщиках рекламы либо особых настройках безопасности браузера они могут просто не открываться, соответственно нужно создавать систему «если не сработала модалка — применить схему редиректа». Во втором случае пользователя перебрасывает на сторонний сайт и обратно, это затраты его времени и трафика, а с точки зрения основного сайта — дополнительные запросы и нагрузка на сервер + лишние срабатывания событий аналитики (ведь обратный редирект считается новым заходом), и аналитикам приходится создавать дополнительные схемы для фильтрации подобного поведения.

                            Если же работает через модалку, то она не стилизуется под сайт и выглядит некрасивым инородным элементом.

                            Считается, что все эти ux-неудобства окупаются тем, что пользователю не требуется создавать новый логин-пароль и запоминать его, так как потерпеть +-10 секунд редиректы или некрасивые модалки — это проще, чем заставлять мозг креативить для создания новой пары ключей доступа и помещать это дело в хранилище (я, например, пользуюсь LastPass, поэтому это не проблема, но многие хранят в текстовых файлах или приватных сообщениях в мессенджерах, в худшем случае — только в памяти). А если сайт требует «безопасный пароль» с разным регистром, цифрами, спецсимволами и длинный, то тут очевидно справятся только самые стойкие и очень заинтересованные в использовании данного сервиса.

                            В общем, с точки зрения ux оба решения далеки от идеала. А технологии биометрической идентификации пока недостаточно внедрены в устройства, работающие с веб-сайтами, так что приходится выбирать из того, что есть.
                        +6
                        Очередная агитация в стиле «сделайте бекдор в своём проекте не только для спецслужб своей станы, но ещё и для крупных корпораций, а то им тоже хочется, а законного способа вас заставить нет» (один OCSP реализуемый запросом браузера чего стоит). Безопасность это как раз та область где нужно по-умолчанию считать всех врагами и не доверять никому, а не искать способы сделать полегче, да подешевле.

                        Возмещение ущерба, ответственность за взломы? Вы шутите? Да вся IT построена на том, что никто никому ничего не должен. Сколько раз взламывались всякие крупняки? Сколько раз они теряли не то что логины/пароли а данные кредиток миллионов человек? И? Понёс ли хоть кто-то ответственность большую чем пресс-релиз «извините»? Вот когда начнут реально наказывать всякие Гугло-фейсбуки за утечки, тогда, возможно, уже и обратят внимание на проекты поменьше.
                          0

                          А в чём конкретно проблема с OCSP?

                            0
                            Если запрос к OCSP делает браузер, а не сервер, то OCSP сервер получает полную статистику кто и когда обращается к ресурсу. Теперь следить за вами будет и CA.
                              0

                              Ну, это "теперь" — скорее давняя история, чем новая. OCSP stapling вроде везде поддерживается уже лет 7. Конечно, сложно оценить, на каком проценте сайтов его поддержку забыли включить, и посещения таких сайтов может отслеживать CA.

                                0
                                А ведь как просто можно было бы решить проблему по нормальному: просто если нет OCSP ответа от сервера — соединение не достоверное (никаких запросов от браузера к CA). И ошибки настройки бы сразу было видно, и утечек, даже потенциальных бы не было.
                            0
                            Скорее, когда начнут реально наказывать проекты поменьше, тогда возможно достанется всяким Гугло-фейсбукам.
                            0

                            У меня на заре карьеры был интересный случай.
                            Взялся поддерживать один сайт, который пару лет до этого переписали с php на python+django. Прошлые разработчики, наверно, хотели полностью отказаться от самописных решений, и в качестве аутентификации взяли библиотеку userena.


                            Одна беда — хэш функции паролей в библиотеке и старого сайта не совпадали. Поэтому те ребята не придумали ничего лучше, как полностью скопировать код userena себе в проект, и поменять пару строчек хеширования паролей. Осознав масштаб, я поменял хэш функцию назад, пр этом на некорректный пароль проверял и старой функцией, попутно обновляя записи в бд. Через пол года я удалил запатченую библиотеку и смог обновить её в requirments.


                            Эта история мне тогда открыла глаза на всю сложность и масштаб вопроса. Благодарю за статью!

                              0
                              один проект, с парой миллионов пользователей, успешно проходивший проверку на безопасность каждые пол года

                              в один прекрасный день, разработчик, для дебага на форме логина поменял POST на GET
                              код ушел в прод, случайно заметили через пару недель и исправили

                              следующая проверка тоже прошла успешно :)
                                +1
                                Спасибо за статью, я начинающий разработчик и как раз задумываюсь о создании своего проекта на стеке VueJS+Django. Как раз думал над аунтефикацией. Много разного предлагают разные авторы, но я уже недели 2 не могу выбрать на чем же остановится.
                                Склоняюсь к использованию встроенной JWT аунтефикации которая имеется в DRF.
                                  0
                                  Где можно скачать библиотеку аутентификации на php для своего сайта? Какие существуют?
                                  0
                                  Корневое утверждение статьи абсолютно верно — многие недооценивают сложность авторизации и аутентификации, особенно, при использовании разных способов входа и разных уровней доступа. Поэтому писать их самому абсолютно необязательно — существует огромное количество качественных библиотек и boilplates, решающих эту проблему :). Единственный весомый аргумент в пользу IDaaS — перенос ответственности за личные данные пользователя на третью сторону. Но, как написали выше, ответственность в IT понятие весьма размытое, так что…
                                    0

                                    Помнится не так давно в одной из самых популярных PHP либ был найден занятный баг — в alg можно было указать none и скрафтить какой угодно токен.
                                    Но в целом с посылом статьи я согласен — чаще самопис и простые решения из коробки просто пугают.

                                      +3

                                      Есть и третий путь. Не писать аутентификацию самостоятельно и не отдавать на откуп неизвестному дяде, который мамой клянётся что у него всё хорошо с безопасностью, он не закроется сам и не отключит вас от своего сервиса по ему одному известной причине или из-за каких-нибудь "санкций" — можно поставить у себя отдельный сервис аутентификации.
                                      Мы часто используем в своих проектах для этой цели Keycloak — он опенсорсный, умеет всё что надо в области в openid/oauth в т.ч. подключение сторонних провайдеров, типа гугла, фейсбука и т.п. А чего не умеет — можно дописать. Мы вот написали к нему провайдеры для всех основных российских соцсетей (https://github.com/playa-ru/keycloak-russian-providers) и даже для ЕСИА (этот пока на гитхаб не выкладывали).
                                      Как по мне — Keycloak очень удобная штука. И пользователи ваши остаются при вас и велосипеды не надо изобретать.

                                        +2
                                        А пользователя хоть кто-нибудь спрашивал?
                                        Захожу на западные сайты — мне предлагают авторизоваться через, например, facebook/google.
                                        Захожу на отечественные — предлагают вк/ок.
                                        Мне придётся во всех (ну ладно, в некоторых) соцсетях регистрироваться для того. чтобы зайти на левый сайт?
                                        Разработчикам для моего удобства приходится поддерживать авторизацию через десяток разных сервисов (или терять аудиторию, если юзер не пользуется нужным сервисом).

                                        Если у меня iOS и нет гуглоучётки? Не сижу в фейсбуке? Если РКН «заблокировал» Телеграм, задев и «Телеграм паспорт»? Если ВК заблокировали вна Украине? Что будет?
                                        Я не смогу зайти на ваш сайт.

                                        А если я не хочу, чтобы в инете сохранилась связь сайт-мой аккаунт в соцсети? Например, при входе со смартфона pornhub просит авторизоваться через ВК. Что-то типа Сбербанк ID / Paypal вообще нет желания привязывать ни к одному сервису, на котором есть возможность оплаты/подписки/покупки (а сейчас, считай, что и нет сервисов, у которых нет платных возможностей или их нельзя было бы прикрутить).

                                        Из-за этого везде, где можно — выбираю «Зарегистрироваться через email». А это значит, что разработчикам, помимо сторонних сервисов, все равно приходится пилить свои велосипеды.
                                        Само собой, пример не показательный, но я не встречал ни одного сайта, на котором была бы нужда зарегистрироваться и не было бы возможности сделать это «по старинке» через email или, хотя бы, номер телефона.
                                          0

                                          Захожу на порнохаб, предлагают логинится через ВК. Что, серьезно?

                                          0

                                          Все круто. Вот только недавно несколько раз падал mobilePass(не помню какой сервис под ним). Изза чего были проблемы при подключении к корпоративной сети через vpn.

                                            +1
                                            То есть я правильно понимаю, что ради обеспечения «безопасности» моего маленького сайта мне предлагают дать фейсбуку, гуглу, apple и подобным им компаниям полный доступ к списку моих пользователей? А так же техническую возможность выполнять на моём сайте любые действия от их имени? Я надеялся по заголовку, что нам расскажут про какие-нибудь либы/плагины для apache или nginx, позволяющие стандартизировать процессы регистрации и входа, а здесь такое…

                                            Вот допустим, я пользователь, хочу зарегистрироваться на очередном сайте, example.com. И я вижу, что мне для этого нужно ещё и создать аккаунт на фейб**ке (© Носик), слить им кучу инфы, а потом (и это самое главное) каждый день трястись, чтобы этот fb-аккаунт не забанили «за ботовотство». Потому что если я потреяю этот fb-аккаунт, то в example.com тоже войти не смогу. А фейсбук, по статистике, сейчас в течение 2-3 дней банит 90% аккаунтов с минимально заполненными анкетами и отсутствием активности после регистраиции, поскольку считает их ботами (даже несмотря на привязку к телефону). То есть мне, чтобы сохранить аккаунт на example.com, придётся ещё и каждый день заходить на fb и что-то там искать/писать. А не обойдётесь ли вы, господа с example.com?
                                              0
                                              Как-то вы выборочно читали статью, если увидели в ней только авторизацию через соцсети. Например, упоминание auth0.com вы явно не заметили.
                                                0
                                                Как-то вы выборочно читали комментарий, если увидели в нём только авторизацию через соцсети. Например, первый абзац вы явно не заметили
                                                  0
                                                  Я писал свой комментарий (точнее, как вам правильно заметили, вторую его часть) про фейсбук, потому что какое-то представление о нём имею, а про auth0.com слышу впервые.

                                                  Но в любом случае, общий принцип остаётся неизменным: при регистраиции на example.com через auth0.com у меня больше шансов словить бан по дури искусственного интеллекта или самодурству админа, чем при регистрации на example.com напрямую: к ИИ и админу example.com добавляется ИИ и админ auth0.com. Своих данных приходится тоже раскрывать больше. Насколько количественно больше этот риск бана и это раскрытие данных — зависит от реалий деятельности auth0.com (именно от реалий деятельности, а не от того, что они красивыми буковками пишут у себя на главной странице, это не узнаешь без независимого сбора статистики у тех, кто пытался этим auth0.com пользоваться), но в любом случае он больше.
                                                +1
                                                Особенно весело пользоваться сайтами с авторизацией через сторонние сервисы на чужом компьютере.
                                                Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке. Перед этим, наверняка, придётся деавторизовать хозяина этого компа, а после — выйти из фейсбука, выйти из example.com, да ещё и куки и кеш браузера потереть, если это не очень доверенный компьютер.
                                                  0
                                                  Это как раз юзкейс для приватного режима. Хозяина деавторизовать не придется и ваша авторизация сбросится сразу после закрытия приватного окна.
                                                    0
                                                    Вы правы. Спасибо, что напомнили про приватный режим, совсем про него забыл.
                                                    Он действительно убирает проблему «хозяин компьютера уже зашел в свой аккаунт».

                                                    Осталась только проблема «Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке».
                                                    Дополню, почему это проблема для меня — поскольку к аккаунту соцсети или того же гугла уже привязано много других сервисов, то и пароли там немного сложнее, чем qwerty12345, и включена 2FA везде, где это возможно. Это обычно означает, что мне надо вспоминать сложный пароль или перепечатывать его из менеджера паролей (если он есть под рукой) и также тащиться за смартфоном (для 2FA).
                                                    Если смартфон уже есть поблизости, то обычно нет нужды заходить на example.com с чужого устройства, проще зайти сразу со смартфона.
                                                    Плюс тревожности добавляет тот факт, что я не могу гарантировать корректную работу приватного режима на чужом устройстве (необновлённый браузер, кривая реализация приватного режима, кастомные настройки, кастомная сборка браузера, фейковый браузер, прокси, кейлогеры, камера, направленная на клавиатуру и т.д.) и при этом должен вводить пароль от своего важного фейсбучного аккаунта только для того, чтобы попасть на какой-то левый example.com (доступ к которому мне может быть не жаль, пускай перехватывают)
                                                  +2
                                                  Как пользователь, могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.
                                                  А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
                                                    0
                                                    Ну и еще хочу добавить одну идею. Может Яндекс люди читают или еще кто…
                                                    Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
                                                    Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
                                                    Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
                                                      0
                                                      могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.

                                                      Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.

                                                      Это расплата за лень. За то, что вы перекладываете труд по регистрации на плечи интернет-магазина и стороннего сервиса авторизации — вы расплачиваетесь своими данными (магазин получает данные о вас, соцсеть — данные о том, что вы пользуетесь этим магазином).
                                                      Пока вы считаете, что это адекватная плата за «труд» ввести свой email и пароль (это минимум, конечно, некоторые сайты требуют ещё кучу данных, но их можно заполнить фейками) — пользуйтесь авторизацией через сторонние сервисы.

                                                      Приведу аналогию:
                                                      вы в оффлайн магазине покупаете холодильник. Вам нужна доставка, т.е., надо сообщить продавцу адрес и имя получателя. Вы можете:
                                                      1) самому написать ему адрес и имя
                                                      2) дать ему папку, в которой лежат: свидетельство о рождении, фото «с уголком», диплом, школьный альбом, записная книжка со списком друзей, дневник с записями о значимых событиях (поездки, праздники, мероприятия), фотки из отпуска, справка из ЖЭКа, телефон любовницы, копия трудовой… Продавец берёт это всё, выбирает среди этого то, что ему нужно (напомню, ему нужны адрес и имя; если речь не о холодильнике, а о продукции 18+, то ещё может глянуть на св-во о рождении). Вам ничего делать не надо (ну только таскать в магазины эту папку)

                                                      P.s. пример выдуманный, специально гипертрофирован и подогнан под ваши два комментария. Ни капли не против того, чтобы сторонние сервисы выдавали токены, которые нельзя было бы связать с основным аккаунтом, но:
                                                      — сайту обычно нужен не только токен, но ещё и имя; некоторым — возраст; ещё может понадобиться email для связи; кто-то подтягивает фото из соцсети; и т.д. Хотелось бы это контролировать, но полный контроль — это огромная простыня галочек, какие данные предоставлять сайту, она неудобна, поэтому, у кого это есть, отдают данные более-менее связными блоками (например, показать общую информацию / показать друзей / показать подписки / дать возможность писать друзьям / и т.д.), т.е., чтобы показать только имя — нужно разрешить ещё доступ к городу/дате рождения и т.д. В деталях могу ошибаться, поскольку стараюсь не пользоваться такими сервисами.
                                                      — я, как пользователь, не хочу знать, какая соцсеть сегодня выдаёт обезличенные токены, а какая — предоставляет доступ ко всем данным, да ещё и разрешает постить друзьям от моего имени. Мне не интересно в этом разбираться, я просто хочу зарегистрироваться на сайте «и чтобы без последствий».

                                                      А в организации, поскольку у нас… AD
                                                      Тут можно не продолжать )
                                                        0
                                                        Да, мне лень. Я потому и привел аналогию с кредитной картой. Мне лениво носить с собой нал, отсчитывать деньги, проверять сдачу. Кроме того, оплатить картой гораздо быстрее.
                                                        И поэтому я пользуюсь картой. Но вот гугл озаботился вопросом о сохранении приватности данных моей карты и генерирует новый номер для каждой покупки, хотя физическая карта у меня одна и все платежи приходят на нее.
                                                        Почему бы так же не сделать с соцсетями? По мне так это было бы удобно.
                                                          0
                                                          Всё, что вы написали про карты — регулируется платежными системами, стандартами PCI DSS, банками. Например, Google не должен хранить реквизиты вашей реальной карты (но можно навыпускать виртуальных; или получить от банка-эмитента кучку одноразовых токенов для оплаты).

                                                          Авторизация пользователей — не регулируется никем. Сейчас мы можем только писать в комментариях «хотелось бы вот такую фишку...», но никто не обязан её реализовывать. Но если у кого-то это уже будет и все будут об этом говорить, тогда «отстающие» тоже реализуют (как это случилось с e2e шифрованием в мессенджерах).
                                                          Но всё равно останется необходимость передавать какие-то данные о вас (см. постскриптум предыдущего комментария)
                                                            0
                                                            Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.
                                                            Ниже уже подсказали, что Apple как раз подобный сервис реализует. Думаю, должны, со временем, подтянуться и остальные. С нетерпением жду подобного от google.
                                                              0
                                                              Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.

                                                              Да поправят меня более опытные хабраюзеры, ежели не прав, но это не совсем так. Номер виртуальной карты генерируется один раз при привязке карты, его должно быть видно в интерфейсе приложения и в чеках (в виде «номер карты ******1234»).
                                                              Если я правильно помню процесс, виртуальную карту генерирует тоже не гугл, а банк.
                                                              В момент привязки приложение «знает», что только что сгенерированную карту ****1234 надо привязать к физической карте ****5678, поэтому в приложении вы можете видеть часть номера физической карты, думая, что её данные хранятся в телефоне.

                                                              Но, возможно, это относится не к GooglePay, а к какому-то другому *Pay
                                                        0
                                                        Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.

                                                        BTW, в Azure AD так и сделано: по умолчанию (из идентифицирующих) передается только клейм sub, который, весьма неожиданно, уникален для клиентского приложения (т.е. разные сайты, использующие этот логин, получат разные идентификаторы). Чтобы получить сквозной идентификатор (oid), нужно запрашивать дополнительный профиль.


                                                        Sign in with Apple тоже может передавать не емейл пользователя, а сгенеренный емейл.

                                                          0
                                                          C азуром немного не понятно. Приложение просто попросит подтвердить доступ к email для регистрации и все.
                                                          А вот Эпл, действительно, делает то, о чем я думал, молодцы.
                                                            0
                                                            Приложение просто попросит подтвердить доступ к email для регистрации и все.

                                                            Это если нужен емейл, а не просто аутентификация. А когда "не хочу вводить логин-пароль" — это как раз аутентификация, емейл тут ни при чем.

                                                              0
                                                              Ну, большинство сервисов хотят получить email. Так чтобы «просто аутентификация» даже и не припомню чтобы встречал. Просто будет форма при регистрации типа «разрешить доступ к таким-то полям в профайле» и все. Откажись — и регистрация не пройдет.
                                                                0

                                                                Так собственная аутентификация, силами самого ресурса — обычно email в качестве логина. Вот его и спрашивают, чтобы все более-менее единообразно было с точки зрения учетной записи.

                                                                  +1
                                                                  Не, это не потому. Магазины хотят email чтобы иметь связь с клиентом.
                                                                  А вот я, как клиент, хотел бы, чтобы для каждого магазина, в котором я регистрируюсь, сервис генерировал уникальный «виртуальный» email, примерно по тому же принципу, что и sub в Azure AD, который мы обсуждали выше.
                                                                  Т.е. на claim email отдавалось бы что нибудь типа 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com, а не мой реальный email. При этом, когда магазин отправлял бы что нибудь на этот ящик, все автоматически бы форвардилось в мой реальный ящик.
                                                                    +1

                                                                    И все это только ради того, чтобы нельзя было понять, что 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com не совпадает с a49a9740-b6d7-11ea-8b6e-0800200c9a66 и не является на самом деле username@google.com?


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

                                                                      0
                                                                      Да, только для этого, т.е. для анонимизации email. Ну и плюс, бывает полезно узнать, кто сливает твои данные и иметь возможность закрыть этот адрес безболезненно для остального.
                                                                        0
                                                                        Ну и плюс, бывает полезно узнать, кто сливает твои данные и иметь возможность закрыть этот адрес безболезненно для остального.

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

                                                                          0
                                                                          Так это было бы естественно. Я же вижу в своем профайле список сайтов и приложений, которые я авторизовал. Можно было бы там же рядом показывать и уникальный email.
                                                                          На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
                                                                          А когда на этот адрес начнет валить спам, будет сразу понятно, из какого сайта или приложения произошла утечка.
                                                                            0
                                                                            Так это было бы естественно.

                                                                            Вопрос не в естественности, а в том, что это тоже надо реализовать.


                                                                            На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.

                                                                            Это от реализации рилея зависит. Вы же не ожидаете, что ваш провайдер аутентификации и ваш почтовый провайдер — всегда одно и то же? Ну так почему ваш почтовый провайдер должен что-то знать про адреса, которые предоставлены провайдером аутентификации?

                                                                              0
                                                                              Так все надо реализовывать. С неба оно не упадет. Все ручками, ручками :-).
                                                                              Ловить меня на максимы не надо ;-). Не всегда, но достаточно часто. Google, outlook, vk, yd etc. Рискну предположить, что в большинстве случаев для популярных сервисов это именно так и есть.
                                                                              Кроме того, совсем не обязательно иметь полноценный почтовый сервис. Достаточно правильно организовать форвардинг. Так что FB, например, может запросто в своих токенах писать 4c78b3a1-b569-4c46-a05b-911411e0543e@fb.com в качестве email при регистрации и пересылать все на реальный адрес.
                                                                                0
                                                                                Так все надо реализовывать. С неба оно не упадет. Все ручками, ручками

                                                                                Платить за это кто будет?

                                                                                  0
                                                                                  Хех, большинство из популярных сервисов, используемых для регистрации на сайтах (google, fb, vk, yd, outlook etc), для пользователей бесплатны. Более того, идет серьезная борьба за клиента путем предоставления новых сервисов и улучшения существующих. Насколько я понимаю, существуют различные пути монетизации. Реклама, продажа статистики, продажа «премиальных» сервисов и т.д.
                                                                                  Так что вопрос тут не в том, кто будет платить, а будет ли такой сервис востребован и интересен пользователям. Я вот, полагаю, что будет. И раз этим занялся apple, значит я, видимо, не столь одинок в своих выводах.
                                                                                    0
                                                                                    Хех, большинство из популярных сервисов, используемых для регистрации на сайтах (google, fb, vk, yd, outlook etc), для пользователей бесплатны.

                                                                                    Казалось бы, откуда деньги.

                                                                  0
                                                                  Ну, большинство сервисов хотят получить email.

                                                                  Хотеть-то можно сколько угодно. А вот нужен ли он им?


                                                                  Просто хотеть, чтобы сервис аутентификации предоставлял еще и сервисы анонимных почтовых записей — это немножечко через край.

                                                                    0
                                                                    Ну, обычно распространенные сервисы уже и так предоставляют почтовый ящик. Не вижу большой сложности в генерации виртуальных ящиков для каждого клиента. В конце коцов, сервис анонимных CC гугл же предоставляет.
                                                                      0
                                                                      Ну, обычно распространенные сервисы уже и так предоставляют почтовый ящик.

                                                                      Или нет. Фейсбук не предоставляет. Azure AD не предоставляет.


                                                                      Не вижу большой сложности в генерации виртуальных ящиков для каждого клиента.

                                                                      Вы готовы за это платить?

                                                                        0
                                                                        Именно только за эту фичу — нет.
                                                                        За эту фичу в пакете типа «премиальный» — да.
                                                                        Я сейчас плачу за свои сервисы почты, диска и т.д.
                                                                        Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз. Даже не знаю, на чем он зарабатывает.
                                                                        Azure AD клиенту в данном случае не нужен. Достаточно обычного hotmail.
                                                                          –1
                                                                          Именно только за эту фичу — нет.

                                                                          Вот поэтому этого и не будет.


                                                                          Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз.

                                                                          Не каждый раз, а при подключении карты.


                                                                          И да, "бесплатно для вас" не означает "бесплатно для всех".

                                                                            +1
                                                                            Ну, поживем — увидим. Раз у apple подобное появилось — появится и у других. Конкуренция. Я, знаете, и за какой нибудь excel отдельно платить не стал был. А в пакете office365 — почему бы и нет? К тому же, если бы мои предпочтения точно предсказывали бы поведение рынка, я бы уже наверное отбоя не знал от маркетологов, желающий отдать мне большие $$$ за мое мнение по поводу их продуктов :-). Скажу даже еще более страшное. Мне даже и даром не нужна продукция яблочной фирмы. Ну разве чтобы продать и купить что нибудь нормальное (типа Lenovo или Pixel). Удивительно, как эта фирма до сих пор не разорилась? Я же совершенно не готов платить за их продукты и сервисы :-))).
                                                                              0
                                                                              Не каждый раз, а при подключении карты.

                                                                              Я так понимаю, имелась в виду EMV Payment Tokenisation


                                                                              Насколько именно можно считать, что там 'при каждом платеже номер карты генерируется' — вопрос несколько спорный, но рекламируется оно именно так.

                                                            0

                                                            Почитал комменты, и не могу нарадоваться на то, что аутсорсинг аутентификации неопределённому кругу третьих лиц не мне одному кажется долбаным безумием.
                                                            Да, безусловно, пароли и управление ими очень сложная тема. Если в кратком изложении, займёт в книжке страницы три, а если с объяснениями, то аж целых десять. Не всякий осилит, это правда. Но разве это повод приказным тоном загонять всех в гиперцентрализованные сервисы аутентификации?
                                                            Когда я предоставляю услуги (особенно платные), а мой клиент их потребляет, это дело (а) моё, (б) клиента, и (в) больше ничьё. Я обязался предоставлять сервис, и это область моей ответственности. Клиент обязался следовать условиям предоставления сервиса, и это его область ответственности. И тут внезапно появляется третье лицо неизвестного происхождения с грамотно прописанным отказом от ответственности, которое для меня неотличимо от всех моих пользователей. И если кто-то имеет возможность прийти к этому третьему лицу и сделать предложение, от которого невозможно отказаться, этот "кто-то" тоже получает возможность быть для меня неотличимым от любого из моих пользователей.
                                                            Учитывая, что ИТ-гиганты почти всегда включают режим открытых дверей для всех спецслужб всех государств, а те в свою очередь бывает не брезгуют перепродавать данные кому попало, оно всё начинает как-то совсем нехорошо попахивать.

                                                              +1
                                                              Implicit flow устарел. Следует использовать Authorization Code with PKCE.
                                                                0
                                                                И никто не написал, что все эти сервисы далеко не бесплатны — вплоть до 10$ за юзера в месяц!
                                                                  0
                                                                  Мой ребенок безумно хотел одну игруху на планшете, но вот незадача, регистрация только через фейсбук. Ну не хочу я вешать ее на свой акк. Но дите так просило, что создала акк для него. Так нас забанили сразу же, причем по непонятным причинам. Итог истории: при всем безумном желании клиента, мы не в проекте.

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое