Для входа в веб приложение необходимо идентифицировать пользователя. Рассмотрим 4 наиболее распространенных варианта
1
Воспользоваться "цифровой идентичностью" пользователя в других цифровых сервисах: ВКонтакте, Яндекс, mail.ru, ГосУслуги и пр. Для этого нужно предварительно организовать интеграцию между вашим и сторонним веб сервисом. Заключить договор между двумя роботами об обмене данными. Тогда для пользователя все выглядит очень просто - есть привычная кнопка, например, "Вконтакте". Он нажимает кнопку и попадает в веб приложение. За кадром происходит обмен сообщениями между роботами (веб сервисами). В данном случае робот ВКонтакте присылает вашему роботу всю необходимую информацию о пользователе. ФИО, пол, фото и пр.
За удобство приходится платить. У данного подхода есть разные риски. Например, сторонний сервис может поменять свое API (причем внезапно) и вам придется срочно переписывать код связанный с данной интеграцией. Сервис может оказаться вне закона, как например, Facebook. Тогда вся ваша схема авторизации рушится полностью и надо выстраивать что-то новое.
Есть еще один минус данного подхода. У вас отсутствует обратная связь с пользователем. Вы не можете ему отправить сообщение по почте или в какой-нибудь мессенджер. Потому что данные сервисы такую информацию вам не предоставляют. Если у вас бизнес приложение и вы хотите оповещать пользователей о разных событиях, то это проблема.
За удобство приходится платить. У данного подхода есть разные риски. Например, сторонний сервис может поменять свое API (причем внезапно) и вам придется срочно переписывать код связанный с данной интеграцией. Сервис может оказаться вне закона, как например, Facebook. Тогда вся ваша схема авторизации рушится полностью и надо выстраивать что-то новое.
Есть еще один минус данного подхода. У вас отсутствует обратная связь с пользователем. Вы не можете ему отправить сообщение по почте или в какой-нибудь мессенджер. Потому что данные сервисы такую информацию вам не предоставляют. Если у вас бизнес приложение и вы хотите оповещать пользователей о разных событиях, то это проблема.
2
Можно использовать такую "цифровую идентичность" как email адрес пользователя. Почтовый адрес считается уникальным и это позволяется избежать дублирования пользователей при регистрации. При этом вы никак не связаны со сторонними цифровыми сервисами. Нет соответствующих рисков. Также у вас сразу есть адрес для обратной связи с пользователем - ваши роботы могут заваливать его сообщениями вне всяких лимитов
3
В крупных компаниях может существовать свои авторизационные центры, в которых происходит цифровой учет сотрудников. Например, в продуктах Microsoft это "учетные записи Active Directory", так называемая AD-авторизация. Тут схема такая же как в первом пункте, но только в данном случае авторизация происходит внутри закрытого корпоративного контура безопасности. Сотрудник заходит в веб приложение через свою привычную учетную запись на своем рабочем месте.
4
Есть вариант организовать авторизацию пользователя по номеру телефона. Схема аналогична второму варианту, только здесь вместо email уникальным идентификатором выступает номер телефона. Но у этой схемы есть существенный минус - нужно платить за отправку каждого СМС сообщения специальным шлюзам. Цена 1-1.5 рубля в зависимости от провайдера. При большом количестве пользователей и активном обмене сообщениями нужно закладывать отдельный ежемесячный бюджет.
