Способ и система мультиканальной авторизации пользователя

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

 

Область техники

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

Уровень техники

[0002] Существующая проблема заключается в том, что пользователю необходимо помнить свои логины и пароли к множеству различных источников данных, при этом затраты ресурсов на поддержку пользователей и восстановление логинов/паролей являются достаточно высокими в рамках реализации различных бизнес систем и продуктов. Более того, любые дополнительные действия со стороны пользователя по запоминанию или восстановлению паролей ведут к снижению уровня использования программных продуктов, особенно если речь идет о некритичных для жизни/работы случаях, как например сервисные приложения или электронная коммерция.

[0003] Существуют и вполне известны различные реализации алгоритмов безопасности, с различными степенями защиты, которые решают проблему необходимости помнить или восстанавливать логины/пароли. Начиная от хранения данных логинов в браузерах и от аутентификаций через сторонние сервисы (например, через Google или Facebook, VK, решения Single SignOn (SSO)) и до отдельных приложений "сейфов для паролей". Некоторые из этих методов также собирают данные о пользователях, что часто не нравится пользователям. Другие известные реализации для решения данной проблемы включают методы требующие установки дополнительного программного обеспечения, производимого и контролируемого третьей стороной (например, Google Authenticator или одной из множества подобных) или требуют дорогостоящих технологических операций, например, отправка CMC сообщения с кодом подтверждения, e-mail подтверждение и т.п. Более того, эти методы безопасности требуют множества дополнительных действий со стороны пользователя, что нежелательно для быстрых и выверенных бизнес операций, особенно в случае с вышеупомянутым не критичным программным обеспечением, как то сервисным или для электронной коммерции.

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

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

[0006] Известны также решения по принципу авторизации с помощью протокола OAuth (Open Authorization), который представляет собой открытый протокол авторизации, позволяющий предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. Такие решения, например, раскрыты в таких источниках, как: US 20160028737, US20160330199, WO2014130141.

[0007] Недостатком существующих подходов является отсутствие обеспечения мультиканальной авторизации пользователей с помощью использования мобильных каналов, которые сам пользователь может назначать для взаимодействия с одним или множеством ресурсов, взаимодействующих в рамках многоканальной платформы (системы). Также, недостатком является то, что для каждого типа форм-фактора доступа применяется присущий ему метод авторизации, что повышает трудозатратность процессов аутентификации, в частности, увеличение времени для выполнения необходимых действий для авторизации.

Раскрытие изобретения

[0008] Настоящее решение использует только технологии уже установленные в техническом периметре пользователя (например, на его мобильном устройстве) и решает те же самые задачи, которые стремятся решать все вышеописанные подходы, но с высоким уровнем безопасности и с минимальным количеством действий на стороне пользователя, что значительно упрощает процесс его авторизации на ресурсе доступа.

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

[0010] Механизм авторизации настоящего решения может быть как частью аутентификации первого фактора для доступа к данным непосредственно с мобильного устройства, так и вторым фактором аутентификации, при котором доступ к данным на одном устройстве осуществляется через другое мобильное устройство или на этом же устройстве, но из другого канала аутентифкации. Упомянутый механизм также может работать как гибрид 1ого и 2ого факторов аутентификации на том же самом или разным форм факторах, в тех случаях, когда авторизация первого фактора не прошла или потребовала дополнительного доказательства (второй фактор) из другого канала аутентификации.

[0011] Вышеупомянутые каналы авторизации могут включать, например, иконку на экране мобильного устройства (установленную или в форме PWA, имеющую или не имеющую разрешение на Push уведомления), мобильные службы мгновенных сообщений (мессенджеры и боты в мессенджерах), смс, e-mail, VOIP системы, QR коды и другие каналы.

[0012] В предпочтительном варианте осуществления заявленного решения представлена система авторизации пользователя, содержащая связанные каналом передачи данных устройство пользователя и ресурс доступа, связанный с системой аутентификации, в которой:

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

ресурс доступа выполнен с возможностью получения пользовательского запроса на авторизацию и передачи соответствующего запроса в систему аутентификации; и

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

[0013] В частном случае реализации мобильный канал представляет собой программное приложение или элемент графического интерфейса пользователя.

[0014] В другом частном случае реализации приложение представляет собой мессенджер.

[0015] В другом частном случае реализации система аутентификации содержит данные о доступных каналах авторизации для каждого из ресурсов доступа.

[0016] В другом частном случае реализации система аутентификации хранит данные авторизации пользователей для каждого из доступных мобильных каналов.

[0017] В другом частном случае реализации запрос на авторизацию содержит по меньшей мере информацию, идентифицирующую пользователя.

[0018] В другом частном случае реализации запрос дополнительно содержит данные доступа выбранного мобильного канала.

[0019] В другом частном случае реализации запрос на авторизацию шифруется на устройстве пользователя и дешифруется в системе аутентификации.

[0020] В другом частном случае реализации система аутентификации дополнительно направляет запрос на подтверждение авторизации в мобильный канал устройства пользователя.

[0021] В другом частном случае реализации система аутентификации осуществляет авторизацию пользователя на ресурсе на основании получения ответа от мобильного канала устройства пользователя.

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

[0023] В другом частном случае реализации система аутентификации выполняет приоритезацию мобильных каналов для авторизации пользователя.

[0024] В другом частном случае реализации система аутентификации формирует запрос в мобильный канал пользователя с наибольшим приоритетом.

[0025] В другом частном случае реализации авторизация пользователя выполняется посредством дополнительной верификации.

[0026] В другом частном случае реализации дополнительная верификация представляет собой биометрическую верификацию, пин-код, графический код, звуковой код или их сочетания.

[0027] В другом частном случае реализации канал передачи данных выбирается из Интернет, Интранет, LAN, Ethernet, TCP/IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi, Wi-Fi Direct, LPWAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, спутниковая связь или их сочетания.

[0028] В другом частном случае реализации ресурс доступа представляет собой веб-сайт или программное приложение.

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

[0030] В другом частном случае реализации умное носимое устройство выбирается из группы: смарт-часы, смарт-браслет, смарт-кольцо, средства дополненной реальности, средства смешанной реальности, средства виртуальной реальности.

[0031] В другом предпочтительном варианте осуществления заявленного решения представлен способ авторизации пользователя на ресурсе доступа с помощью канала передачи данных, содержащий этапы, на которых:

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

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

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

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

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

[0033] В другом частном примере реализации запрос на авторизацию шифруется на устройстве пользователя.

[0034] В другом частном примере реализации система аутентификации хранит для каждого ресурса доступные мобильные каналы авторизации.

[0035] В другом частном примере реализации для каждого пользователя в системе аутентификации установлен по меньшей мере один мобильный канал для авторизации на ресурсе.

[0036] Еще одним предпочтительным вариантом осуществления заявленного решения является способ авторизации пользователя на ресурсе доступа с помощью канала передачи данных, содержащий этапы, на которых:

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

передают упомянутый запрос на доступ к ресурсу в связанную с упомянутым ресурсом систему аутентификации;

проверяют в системе аутентификации доступность для упомянутого пользователя одного или более мобильных каналов для авторизации с помощью сравнения данных авторизации пользователя с данными, хранящимися в системе аутентификации;

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

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

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

[0037] В одном из частных примеров реализации при обработке пользовательского запроса на авторизацию, система аутентификации осуществляет приоритезацию доступных мобильных каналов для авторизации пользователя.

[0038] В другом частном примере реализации система аутентификации направляет запрос на подтверждение доступа в мобильный канал пользователя с наибольшим приоритетом.

[0039] В другом частном примере реализации для подтверждения запроса на подтверждение доступа устанавливается политика подтверждения, связанная с мобильным каналом.

[0040] В другом частном примере реализации политика подтверждения выбирается из группы: временной интервал, подтверждение получение сообщения.

[0041] В другом частном примере реализации при невыполнении заданной политики подтверждения система аутентификации формирует повторный запрос в другой доступный мобильный канал авторизации, на основании приоритезации каналов.

Описание чертежей

[0042] Фиг. 1 иллюстрирует общую схему работы заявленного решения.

[0043] Фиг. 2 Фиг. 3 иллюстрируют способ авторизации пользователя.

[0044] Фиг. 4А - Фиг. 4D иллюстрируют примеры выбора мобильного канала аутентификации на устройстве пользователя с помощью графического интерфейса пользователя.

[0045] Фиг. 5А - Фиг. 5D иллюстрируют примеры аутентификации при использовании двухфакторной верификации.

[0046] Фиг. 6 иллюстрирует общий вид пользовательского устройства.

Осуществление изобретения

[0047] На Фиг. 1 представлена общая система (100) взаимодействия элементов заявленного решения. Авторизация пользователя (110) на ресурсе доступа (120) осуществляется с помощью пользовательского (110) вычислительного устройства, осуществляющего взаимодействие посредством канала передачи данных с ресурсом доступа (120). Ресурс доступа (120) подключен посредством соответствующего канала передачи данных к системе аутентификации (130), которая выполняет обработку данных для осуществления пользовательской (110) авторизации.

[0048] Пользовательское вычислительное устройство (110) может представлять, например, смартфон, планшет, персональный компьютер, ноутбук, игровую приставку, с март-телевизор, носимое умное устройство (кольцо, браслет, часы, очки и т.п.), средство виртуальной реальности, средство дополненной реальности, средство смешанной реальности и т.п. Устройство (110) должно обеспечивать обработку необходимой программной логики для выполнения процедуры авторизации пользователя на одном или более ресурсах (120). Общее описание основных компонентов устройства (10) будет раскрыто далее в настоящем описании.

[0049] Канал передачи данных может представлять собой различный принцип и протоколы для передачи информации и обеспечения информационного взаимодействия, например, Интернет, Интранет, LAN, Ethernet, TCP/IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi, Wi-Fi Direct, LP WAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, спутниковая связь и т.п. Различные имплементации и воплощения канала передачи данных зависят от конкретной реализации информационной сети обмена. Стоит также отметить, что канал передачи данных может представлять собой прямое подключение двух и более устройств между собой.

[0050] Под ресурсом доступа (120) понимается сущность (объект, приложение, устройство, веб-сайт и т.п.), к которой пользователь получает доступ с помощью канала передачи данных, например, наиболее распространенный случай веб-сайт. Ресурс доступа (120) в настоящей реализации технического решения подразумеваются не только сами данные, например, данные бухгалтерского учета, медиа данные, информация доступа, но и механизм их доставки, например, окно интернет браузера, мобильное приложение, элементы графического интерфейса пользователя. Ресурс доступа (120) может также представлять собой приложение, установленное на устройстве пользователя (110).

[0051] Ресурс доступа (120) также может содержать хранилище данных (121), например, базу данных. Хранилище данных (121) представляет собой механизм, связанный с ресурсом доступа (120), который при получении запроса на доступ от пользователя (110) "узнает" ранее аутентифицированных пользователей (110) для ускорения процесса последующей аутентификации. Этот механизм может использовать, например, "куки-файлы" для ресурса (120) в браузере, или в другом техническом виде, позволяющем осуществлять задачу.

[0052] Система аутентификации (130) представляет собой программно-аппаратное решение по обеспечению многоканального управления доступом для осуществления авторизации пользователей (110). Система аутентификации (130) может быть интегрирована в ресурс доступа (120), причем интеграция может быть полной или частичной. Система аутентификации (130) может быть удаленным сервисом, взаимодействующим посредством обмена запросов авторизации пользователей (110) через ресурс доступа (120), для обеспечения доступа.

[0053] Основными элементами системы аутентификации (130) являются хранилище данных (131), модуль назначения канала доступа для аутентификации (132), модуль пользовательских настроек (133), модуль выбора и приоритезации мобильных каналов (134), модуль уведомления пользователя и модуль уведомления ресурса доступа (135). Набор модулей может отличаться при конкретной конечной реализации, в частности, модули уведомлений могут являться опциональным решением.

[0054] Хранилище данных (131) содержит основную информацию для обеспечения процесса авторизации пользователей (110). В модуле (131) хранятся данные каналов, выбранные каждым пользователем (110), осуществляющим взаимодействие с системой (130), ключи/токены/ID данные, соответствующие каждому пользователю (110) в каждом мобильном канале, с помощью которого выполняется или выполнялась авторизация.

[0055] Также, в хранилище (131) хранятся алгоритмы, процедуры и логика работы авторизации и уведомлений для каждого канала авторизации, например, но не исключительно: таймауты операций, способы подтверждений доставки данных, правила запуска, периоды повторных аутентификаций, АПИ (API) вызовы и другие детали канала. Количество каналов в системе (130) может быть больше, чем конкретный ресурс доступа (120) избрал использовать для решения собственных задач по авторизации пользователей (110).

[0056] В хранилище (131) содержится программная логика по управлению ключами доступа, в частности, получение, хранение и передача авторизационных ключей и/или идентификаторов (в зависимости от канала авторизации) для каждого ресурса доступа (120) и для каждого канала, выбранного ресурсом доступа (120) для своей работы.

[0057] В хранилище данных (131) также передается и хранится информацию о всех ранее аутентифицированных пользователях для каждого ресурса доступа (120). Данная информация может связываться с хранящимися данными ключей в хранилище данных (131) из множества ресурсов доступа (120), для обеспечения централизованного сервиса аутентификации.

[0058] В хранилище (131) также могут сохраняться все события аутентификации, включая все важные технические данные о таких событиях, например, идентификаторы пользователя, время и место, канал, тип устройства пользователя и так далее.

[0059] Модуль назначения канала доступа для аутентификации (132) обеспечивает работу с ключами/идентификаторами для множества ресурсов доступа (120). Данный модуль (132) может быть реализован, например, в виде облачного сервиса, связанного с ресурсами доступа (120). С помощью модуля (132) выполняется настройки используемых каналов авторизации на ресурсах доступа (132).

[0060] Модуль выбора мобильного канала авторизации (133) обеспечивает выбор канала авторизации для пользователя (110). Данный функционал может быть вызван изнутри или снаружи периметра ресурса доступа (120) (в зависимости от применяемого форм фактора). Модуль (133) содержит данные только мобильных каналов аутентификации, выбранных владельцем ресурса доступа (120) из набора всех мобильных каналов, чья логика работы доступна и хранится в хранилище (131) системы аутентификации (130).

[0061] Модуль многоканального выбора и приоритезации мобильных каналов (134) обеспечивает подбор и ранжирование каналов аутентификации, исходя из установленных логикой работы модуля (134) правил. Модуль (134) при выполнении предписанных функций может использовать историю аутентификаций пользователя (110) и данные о разрешенных каналах ресурсом доступа (120). Процесс выбора канала начинается с выбора одного канала (наиболее приоритетного) и далее выполняется перебор каналов авторизации до получения результата аутентификации.

[0062] Модуль уведомления пользователя (135) обеспечивает уведомление пользователя (110) о том, что аутентификация происходит в данный момент (может не применяться в каждой реализации настоящего решения), включая логику сообщений об отказе в аутентификации или о просрочке, или о необходимости дополнительного подтверждения. Функционирование логики данного модуля (135) может требовать дополнительных действий со стороны пользователя (110). Чаще всего такие дополнительные действия требуются при аутентификации второго фактора доступа.

[0063] Модуль уведомления ресурса доступа (136) обеспечивает уведомление ресурса доступа (120) о результате аутентификации, например, модуль (136) может быть реализован на основании протокола OAuth.

[0064] На Фиг. 2 представлен способ авторизации пользователя (110) с помощью мобильного канала аутентификации на ресурсе доступа (120). На этапе (201) пользователь инициирует процесс аутентификации на ресурсе доступа (120). Инициирование запроса на доступ к ресурсу (120) может выполняться, например, через активацию элемента графического интерфейса (GUI) на экране устройства (110), например, иконку, виджет и т.п., через веб-браузер или с помощью программного приложения. Далее запрос от устройства пользователя (110) на этапе (202) передается на ресурс доступа (120).

[0065] При получении пользовательского запроса на этапе (202) ресурс (120) осуществляет его обработку. Запрос, как правило, включает в себя идентификатор пользователя, либо связку его данных авторизации (логин/пароль), также может дополнительно использоваться ID устройства пользователя и иной тип идентифицирующей информации. Ресурс доступа (120) на этапе (203) по полученным идентификаторам пользователя осуществляет проверку наличия для данного пользователя (110) установленного мобильного канала аутентификации, с помощью передачи упомянутых данных идентификации в систему аутентификации (130) (этап 203).

[0066] На этапе (203) система аутентификации проверяет с помощью сравнения полученных данных в пользовательском запросе и данных, хранящихся в модуле памяти системы (131), на наличие канала аутентификации для соответствующего пользователя (110). Если для пользователя, запрашивающего процесс аутентификации, в системе (130) не сохранено канала, например, выполняется первый доступ к ресурсу (120), то осуществляется выбор канала с помощью модуля (133) (этап 211), при котором для выбранного канала создаются данные доступа, которые сохраняются в хранилище (131) системы (130) для соответствующего пользователя. Впоследствии сохраненные данные будут применяться для последующей авторизации с помощью выбранного канала аутентификации.

[0067] На этапе (204) проверяется источник направления запроса, в частности, осуществляется ли пользовательский запрос из ранее назначенного мобильного канала для текущего пользователя (110), связанный с ресурсом (120), к которому выполняется запрос на аутентификацию. Если мобильный канал уже назначен и его данные сохранены для текущего пользователя (110) и соответствующего ресурса доступа (120)в системе аутентификации (130), то осуществляется дальнейшее выполнение логики и правил аутентификации, заложенных для данного мобильного канала (этап 205).

[0068] Например, в качестве мобильного канала аутентификации может использоваться приложение мессенджер (Telegram, WhatsApp, FaceBook Messenger, Slack, Viber и т.п.). Каждый канал имеет свою заданную логику идентификации пользователей и принцип обработки данных с помощью алгоритмов, например, принципы шифрования данных, формирование и передачу пакетов данных, алгоритм уведомления и т.п.

[0069] При выполнении необходимых требований по организации аутентификации с помощью логики мобильного канала на этапе (206), пользователю предоставляется доступ к ресурсу с помощью его авторизации (этап 207). Дополнительно ресурс данных (120) может уведомляться системой (130) о факте положительной аутентификации пользователя (110).

[0070] Если на этапе (206) процедура аутентификации завершается не успешно, то логика алгоритма аутентификации пользователя (110) может заново обратиться к системе аутентификации (130) на этапе (208) для анализа дополнительных мобильных каналов аутентификации для текущего пользователя (110). Если для пользователя (110) в системе аутентификации имеются дополнительные мобильные каналы для аутентификации, то процесс аутентификации переход на этап (300), который будет описан далее в материалах заявки.

[0071] В случае, если на этапе (208) для пользователя (110) нет дополнительных каналов для аутентификации, то процесс аутентификации может начаться заново (этап 209) с повторением процесса для текущего назначенного пользователем (110) мобильным каналом аутентификации. Повторная аутентификация может выполняться с помощью генерирования сообщения, PUSH-уведомления или иного типа оповещения, отображаемого с помощью устройства пользователя (110), в ответ на которое пользователь (110) инициирует повторную аутентификацию на ресурсе доступа (120). При отказе от повторной процедуры аутентификации, на этапе (210) система аутентификации (130) сообщает ресурсу (120) о запрете авторизации пользователя.

[0072] На Фиг. 3 представлена процедура (300) выбора мобильного канала для аутентификации пользователем (110). Как было указано выше, выбор мобильного канала может осуществляться когда пользователь (110) не осуществлял назначение мобильного канала аутентификации для авторизации на выбранном ресурсе доступа (120), либо в случае, когда пользователь (110) не смог выполнить аутентификацию с помощью установленного заранее мобильного канала. При таком сценарии выполнения аутентификации пользователя (110) осуществляется назначение дополнительного мобильного канала для аутентификации.

[0073] На этапе (301) выполняется проверка доступных для пользователя (110) мобильных каналов для аутентификации, информация о которых находится в системе аутентификации (130). Если пользователь еще не выполнял выбор канала аутентификации для использования на текущем ресурсе доступа (120), то система аутентификации (130) проверяет все доступные для пользователя (110) каналы аутентификации, а также возможность применения доступных мобильных каналов аутентификации для текущего ресурса доступа (120).

[0074] После получения перечня мобильных каналов, доступных пользователю (110) для авторизации на текущем ресурсе (120), на этапе (302) выполняется проверка активации механизма приоритезации мобильных каналов, установленного в системе аутентификации (130) для соответствующего пользователя (110). Если механизм приоритезации не активирован, то на этапе (303) осуществляется выбор мобильного канала для аутентификации пользователя (110), который был использован при последней успешной авторизации на текущем ресурсе доступа (120).

[0075] На этапе (304) при активированном механизме приоритезации мобильных каналов аутентификации, система аутентификации (130) выполняет ранжирование доступных мобильных каналов для осуществления процесса авторизации пользователя (110) на текущем ресурсе доступа (120). Правила приоритезации могут состоять из 1…N количества правил, в частности, как выбирать первичный (приоритетный) и последующие каналы, как выстраивать последовательность использования мобильных каналов аутентификации и т.п.

[0076] Каждый ресурс доступа (120) может иметь по-разному настроенные правила аутентификации. Приоритеты могут содержать, но не исключительно, цену использования канала, предпочтения ресурса доступа (120), историю авторизаций пользователя, скорость реакции пользователя на канал, возможность использования канала в месте нахождения пользователя и так далее. На основании приоритета каналов осуществляется выбор канала для аутентификации с наибольшим приоритетом, а также выстраивается последующая очередность для дальнейшего использования каналов аутентификации в случае повторной процедуры аутентификации.

[0077] В качестве примера применения механизма ранжирования каналов аутентификации можно рассмотреть пример, в котором система (130) определяет ряда метрик для подбора наиболее релевантного канала для использования в качестве аутентификации. В частности, параметрами для обработки алгоритма ранжирования могут служить: местонахождение пользователя (роуминг, наличие сетей 3G/4G), условия сотового оператора (бесплатный доступ к мессенджерам, соцсетям и т.п.), стоимость передачи данных с использованием каждого типа мобильного канала (SMS, Интернет). На основании полученных метрик, параметры, присущие тому или иному мобильному каналу, обрабатываются алгоритмом модуля приоритезации (134) системы аутентификации (130).

[0078] Далее на этапе (305) применяется логика аутентификации для выбранного мобильного канала на этапах (303) или (304) с помощью соответствующей связки идентификационных данных (ID/токены и т.п.) пользователя (110) для выбранного канала, которые хранятся в системе (130). После обработки данных на этапе (305) выполняется последовательность действий, описанная выше для этапа (205).

[0079] Также, если на этапе (208) в случае неуспешной аутентификации пользователя (110) с помощью заданного канала аутентификации или одного из каналов, который был выбран из набора доступных каналов аутентификации, способ аутентификации выполняется процедуру, начиная с этапа (301). Если с помощью механизма выбора каналов системы (130) уже выполнялся выбор мобильного канала для аутентификации, то используются параметры аутентификации для следующего приоритетного канала.

[0080] Также, система аутентификации (130) может проверять цикл авторизации, например, его продолжительность в заданный промежуток времени, количество итераций, до получения положительного/отрицательного результата. В таком случае реализация имеет механизм установки и хранения этих установок для применения их после проверки последнего доступного канала.

[0081] Ресурс (120) предоставляет доступ пользователю (110) тем способом, который применим для конкретной реализации. Например, если пользователь (110) запрашивает авторизацию в ресурсе (120) через десктоп браузер, то после мобильного подтверждения пользователь допускается на ресурс доступа (120). Если пользователь (110) запрашивает авторизацию в мобильной версии ресурса (120), тогда незамедлительный доступ может быть разрешен.

[0082] Дополнительно для процесса аутентификации устройства пользователя (110) может применяться дополнительная верификация пользователя в мобильном канале доступа, например, двухфакторная аутентификации (2FA - Two factor authentication). На этапе (205) для каждого из каналов устанавливается присущая ему политика осуществления процедуры верификации пользователя, исходя из полученного запроса на доступ к ресурсу (120). При условии применении 2FA определяется используемый соответствующим мобильным каналом способ ее выполнения, например, ввод кода (PIN-код, код из электронного сообщения и т.п.), ввод символов/слов, применение средств ЭЦП, ввод подписи пользователя на экране устройства (110), биометрическая идентификация (отпечаток пальца, сканирование сетчатки глаза, голосовой ввод, изображения пользователя, рисунок вен и т.п.), факт просмотра сообщения (PUSH-сообщения), графический код (например, QR-код, bar-код), временной интервал обработки сообщения, взаимодействие с элементами графического интерфейса и т.п. Могут применяться различные известные из уровня техники принципы подтверждения доступа пользователя (110) к выбранному каналу данных.

[0083] При передаче пользовательского запроса в систему аутентификации (130), к запросу может применяться один или несколько алгоритмов шифрования, например, RSA, SHA-256 и т.п. Данный подход обеспечивает дополнительную защиту при обмене информационными пакетами, содержащими идентификационные данные пользователя (110) и данные для выполнения процедуры аутентификации в канале пользователя.

[0084] На Фиг. 4А представлен пример выбора каналов аутентификации с помощью GUI пользовательского устройства (110). Интерфейс устройства (110) содержит область отображения информации о ресурсе доступа (112) и область (111) расположения иконок (1111)-(1113) мобильных каналов. Область (111) может представлять собой всплывающее окно или виджет. При активации выбранной иконки с каналом доступа выполняется процедура связывания выбранного канала аутентификации с текущим ресурсом доступа или, например, ресурсом, связанным с данной иконкой.

[0085] Фиг. 4В иллюстрирует пример с отображением вариантов каналов для аутентификации пользователя, в котором помимо иконок (1111)-(1113) может также отображаться наиболее предпочтительный канал аутентификации (1114) для текущего ресурса доступа (120). Иконка или кнопка для выбора канала (1114) может отображаться как автоматически при осуществлении доступа к ресурсу (120), так и при выполнении определенных заданных условий, например, прошествии определенного временного периода, активации механизма приоритезации каналов и т.п.

[0086] На Фиг. 4С представлен пример отображения десктопной версии устройства (110), например, персональный компьютер, ноутбук или моноблок, в которой пользователь может запросить аутентификацию с помощью мобильных каналов. В этом случае выбор канала делается, используя логику первично мобильных каналов, связка с которыми существует на десктопе в виде установленных приложений или плагинов, или ссылка на выбор доставляется на мобильное устройство пользователя любым приемлемым методом, например CMC, push, e-mail и т.п. Окно интерфейса (111) отображает как возможные варианты выбора каналов аутентификации (1111)-(1112), так и предпочтительные каналы (1114). Элемент (1115) представляет собой элемент интерфейса, с помощью которого может выполняться вызов списка иконок мобильных каналов (111).

[0087] На Фиг. 4D представлен пример выбора канала аутентификации при заблокированном режиме устройства (110). Область (111) с иконками каналов (1111)-(1113) может вызываться при помощи взаимодействия с дисплеем устройства (110), например, с помощью свайп-движения от нижней кромки экрана. Специалисту должно быть очевидно, что могут применятся другие варианты взаимодействия с GUI устройства (110) в любых возможных направлениях, доступных с помощью работы логики интерфейса или операционной системы, оболочки, лаунчера и т.п.

[0088] Фиг. 5А - Фиг. 5В иллюстрируют пример работы платформы с помощью двухфакторной верификации между двумя устройствами (110₁)-(110₂), в случае когда одно из устройств находится в заблокированном режиме. При необходимости аутентификации на ресурсе доступа (120) на первом устройстве (110₁), если для ресурса (120) имеется назначенный канал доступа или пользователь имеет несколько доступных каналов для осуществления процесса аутентификации на упомянутом ресурсе (120), то запрос на аутентификацию пользователя на ресурсе (120) может поступать на устройство (110₂), которое может находиться в заблокированном режиме. В этом случае уведомление о поступлении в выбранный мобильный канал для аутентификации может отображаться в виде PUSH-уведомления (111), которое также приходит в соответствующий выбранный пользователем мобильный канал аутентификации (1111). Активация полученного PUSH-уведомления (111) может осуществляться, в частности, при взаимодействии с элементом интерфейса, отображающим данное уведомление, что будет являться подтверждением пользовательской аутентификации с помощью устройства (110₂). Подтверждением может являться взаимодействие с областью PUSH-уведомления (111). Если подтверждение уведомления (111) не происходит в установленное время, то считается, что аутентификация не выполняется и осуществляется либо выбор другого канала для аутентификации, либо запрет на предоставление доступа.

[0089] В то же время, может использоваться частный вариант подтверждения аутентификации, при котором, система (130) получает уведомление из мобильного канала аутентификации на устройстве (110₂) о просмотре PUSH-уведомления. В этом случае факт аутентификации также считается совершенным. Под термином "просмотр" также подразумевается получения отклика от устройства пользователя (110₂), подтверждающего, что пользователь увидел PUSH-уведомление (111), например, с помощью получения данных от сенсоров мобильного устройства (110₂) (гироскоп, камера, датчик приближения и т.п.). Само по себе PUSH-уведомление (111) также может носить сугубо информационный характер и не требовать дополнительной активности со стороны пользователя.

[0090] Также, одним из частных примеров подтверждения аутентификации пользователя устройства (110₂) при отправке подтверждения от другого устройства с помощью PUSH-уведомления, ввод информации в поле (111) может выполняться с помощью текстового ввода с помощью текстовой строки, генерируемой GUI при взаимодействии с областью (111) PUSH-уведомления.

[0091] На Фиг. 5В представлен пример взаимодействия с областью (111), например, с помощью свайп движения с отображением вариантов для подтверждения или отклонения аутентификации. Также, дополнительно может применяться вариант со входом на устройстве (1 Юг) в установленный мобильный канал для аутентификации, например, Telegram, в котором будут предоставляться варианты для выполнения или отклонения аутентификации. Примером таких приложения может служить известное решение LoginTap.

[0092] В различных вариантах осуществления, выполнение процесса аутентификации с помощью устройства (110) снабженного биометрическим сенсором в области дисплея, может выполнятся с помощью переноса посредством GUI операционной системы иконки с мобильным каналом аутентификации в область биометрического сенсора для осуществления подтверждения пользовательского выбора с помощью биометрической верификации.

[0093] На Фиг. 5С представлен представлен пример выполнения двухфакторной верификации пользователя (110) с помощью перемещения иконки (1112) выбранного канала аутентификации в область биометрического сенсора (105), расположенного в зоне дисплея устройства (110). В такой реализации аутентификация пользователя выполняется при распознавании нахождения пальца области в области сенсора (105) с захваченным элементом GUI в виде иконки (1112) канала, что обеспечивает дополнительную верификацию и защиту обеспечения доступа.

[0094] На Фиг. 5D изображен пример выполнения аутентификации с помощью двухфакторной аутентификации, которая выполняется на устройстве (110) пользователя. При запросе на доступ к ресурсу (120), например, веб-сайту или приложению (установленному на устройстве (110) или веб-приложению и т.п.) с устройства (110), подтверждение может отправляться в мобильный канал (1111), доступный на том же устройстве (110), например, Telegram. В мобильном канале (1111) может отображаться уведомление, например, в виде запроса чат-сессии, с вариантами подтверждения или отклонения процесса аутентификации. При подтверждении запроса в канале (1111) параметры аутентификации передаются на ресурс доступа (120) (или систему аутентификации ((130)) для выполнения и последующего предоставления доступа к ресурсу (120) с помощью устройства (110).

[0095] Альтернативным случаем, представленным на Фиг. 5D выполнения двухфакторной аутентификации на устройстве (110) при запросе на доступ к ресурсу (120), может являться факт подтверждения аутентификации в другом мобильном канале, который получает запрос на аутентификацию пользователя от системы аутентификации (130), в случае когда первый мобильный канал (1111), в который изначально поступил запрос от ресурса (120), не выполнил аутентификацию. Такой случай может иметь место при возникновении ошибки аутентификации пользователя с помощью первого канала (1111), например, истечение времени отклика от первого канала аутентификации, технические проблемы связи, неполноценная передача идентификационной информации (ключи/токены и т.п.) от первого канала и т.п. В этом случае доступ к ресурсу (120) будет предоставлен при получении пользовательского подтверждения из второго канала аутентификации, например, если от ресурса (120) первый запрос был направлен в Telegram, то при неполучении или неполного получения идентификационной пользователя информации из данного канала, то запрос на аутентификацию перенаправляет далее в доступный пользователю второй мобильный канал, например, WatsApp, в котором при выполнении процедуры подтверждения доступа, подтверждающая информация передается на ресурс доступа (120) для осуществления авторизации пользователя.

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

[0097] На Фиг. 6 представлен пример выполнения пользовательского устройства (110). В общем случае, как указывалось выше, устройство (110) может выбираться из широкого перечня электронных устройств, известных из уровня техники. В общем случае устройство (110) содержит один или несколько процессоров (101) или микроконтроллер(-ов), ОЗУ (102), средство постоянного хранения данных (103), интерфейсы ввода/вывода (104), устройства ввода/вывода (105), средство сетевого взаимодействия (106).

[0098] Процессор (101) представляет собой основной вычислительный модуль, обеспечивающий логическую обработку алгоритмических команд, необходимых для осуществления устройством (110) необходимых функций.

[0099] ОЗУ (102) представляет собой стандартную оперативную память, предназначенную для хранения исполняемых процессором инструкций, реализующих работу заложенной программной логики.

[0100] Средства для постоянного хранения данных (103) могут представлять собой, не ограничиваясь: жесткий диск (HDD), флэш-память (NAND, EEPROM, SD-карты и т.п.), твердотельный накопитель (SSD), оптические накопители данных (CD/DVD/BlueRay диски и т.п.).

[0101] Интерфейсы В/В (104) могут представлять собой, не ограничиваясь: АЦП/ЦАП, USB (micro-, Туре С, mini- и т.п.), PS/2, PCI, VGA, RS232, RJ45, FireWire, SATA, IDE, COM, LPT, Audio Jack, HDMI, Display Port, Lightning и т.п.

[0102] Средства В/В (105) могут представлять собой, не ограничиваясь: дисплей, сенсорный дисплей, клавиатуру (механическая, сенсорная, проекционная и т.п.), трекбол, джойстик, тач-пад, динамики, микрофон, проектор, световой индикатор, зуммер, биометрический сенсор (сканер отпечатка пальца, сетчатки глаза, радужной оболочки, голоса, ладони, рисунка вен и т.п.), камера, оптический сенсор, акселерометр, гироскоп, датчик освещенности, датчик приближения, грависенсор и т.п.

[0103] Средство сетевого взаимодействия (106) может представлять собой, не ограничиваясь: Bluetooth-модуль, BLE модуль, NFC, Ethernet карта, модем, роутер, IrDa, GSM - модем, GPRS-модем, LTE-модем, 50-модем, WLAN, Wi-Fi модуль, спутниковый модем, ГНСС - приемник и т.п.

[0104] Представленные описание заявленного решения раскрывает лишь предпочтительные примеры его реализации и не должно трактоваться как ограничивающее иные, частные примеры его осуществления, не выходящие за рамки объема правовой охраны, которые являются очевидными для специалиста соответствующей области техники.

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

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

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

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

2. Система по п. 1, характеризующаяся тем, что запрос дополнительно содержит данные доступа выбранного мобильного канала.

3. Система по п. 2, характеризующаяся тем, что запрос на авторизацию шифруется на устройстве пользователя и дешифруется в системе аутентификации.

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

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

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

7. Система по п. 1, характеризующаяся тем, что канал передачи данных выбирается из: Интернет, Интранет, LAN, Ethernet, TCP/IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi, Wi-Fi Direct, LPWAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, спутниковая связь или их сочетания.

8. Система по п. 1, характеризующаяся тем, что ресурс доступа представляет собой веб-сайт или программное приложение.

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

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

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

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

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

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

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

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

13. Способ по п. 11, характеризующийся тем, что запрос на авторизацию шифруется на устройстве пользователя.

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

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

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

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

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

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

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

- выполняют авторизацию пользователя на упомянутом ресурсе в случае успешного подтверждения запроса доступа или запрещают доступ при получении отрицательного подтверждения.

16. Способ по п. 15, характеризующийся тем, что для подтверждения запроса на подтверждение доступа устанавливается политика подтверждения, связанная с мобильным каналом.

17. Способ по п. 16, характеризующийся тем, что политика подтверждения выбирается из группы: временной интервал, подтверждение получение сообщения.

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