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

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

Info

Publication number
WO2020060432A1
WO2020060432A1 PCT/RU2018/000611 RU2018000611W WO2020060432A1 WO 2020060432 A1 WO2020060432 A1 WO 2020060432A1 RU 2018000611 W RU2018000611 W RU 2018000611W WO 2020060432 A1 WO2020060432 A1 WO 2020060432A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
authorization
request
channel
access
Prior art date
Application number
PCT/RU2018/000611
Other languages
English (en)
French (fr)
Inventor
Алексей Владимирович БУРЛИЦКИЙ
Original Assignee
Алексей Владимирович БУРЛИЦКИЙ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Алексей Владимирович БУРЛИЦКИЙ filed Critical Алексей Владимирович БУРЛИЦКИЙ
Priority to US17/276,835 priority Critical patent/US11799866B2/en
Priority to PCT/RU2018/000611 priority patent/WO2020060432A1/ru
Publication of WO2020060432A1 publication Critical patent/WO2020060432A1/ru

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • G06F21/43—User authentication using separate channels for security data wireless channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present solution relates to a system and methods for providing user authorization through a computer network, in particular using mobile authorization, in which a user can be granted access in multiple mobile channels.
  • OAuth Open Authorization
  • a disadvantage of existing approaches is the lack of multichannel authorization of users through the use of mobile channels, which the user himself can assign to interact with one or many resources interacting within a multichannel platform (system). Also, the disadvantage is that for each type of access form factor, its inherent authentication method is used, which increases the complexity of authentication processes, in particular, increasing the time to complete the necessary steps for authorization.
  • the present solution allows the user to use fewer authentication methods for various forms. factors of access to data, that is, the user can always use the same method of mobile authentication for all forms of factors for receiving data, as well as assign a preferred authorization method for different access resources. Also, the claimed solution provides the ability to use various access channels for a given access resource.
  • the authorization mechanism of this solution can be either part of the authentication of the first factor for accessing data directly from a mobile device, or a second authentication factor in which data is accessed on one device through another mobile device or on the same device, but from another authentication channel.
  • the mentioned mechanism can also work as a hybrid of loro and 2nd authentication factors on the same or different forms of factors, in cases where the authorization of the first factor did not pass or required additional proof (second factor) from another authentication channel.
  • the above-mentioned authorization channels may include, for example, an icon on the screen of a mobile device (installed or in the form of PWA, with or without permission to Push notifications), mobile instant messaging services (instant messengers and bots in instant messengers), SMS, e-mail , VOIP systems, QR codes and other channels.
  • a user authorization system comprising a user device and an access resource associated with an authentication system, connected with a data channel, in which:
  • a user device configured to generate an authorization request on an access resource using at least one mobile channel that is associated with said device
  • the access resource is configured to receive a user request for authorization and transmit the corresponding request to the authentication system; and an authentication system for authorizing a user on said resource using at least one mobile channel associated with a user device.
  • the mobile channel is a software application or a graphical user interface element.
  • the application is an instant messenger.
  • the authentication system contains data on available authorization channels for each of the access resources.
  • the authentication system stores user authorization data for each of the available mobile channels.
  • the authorization request contains at least information identifying the user.
  • the request further comprises access data of a selected mobile channel.
  • the authorization request is encrypted on the user's device and decrypted in the authentication system.
  • the authentication system further sends an authorization confirmation request to the mobile
  • the authentication system authorizes the user on the resource based on the response from the mobile channel of the user’s device.
  • the authentication system upon receipt of a request from a user device for authorization, the authentication system checks for available mobile channels for a given user.
  • the authentication system prioritizes the mobile channels to authorize the user.
  • the authentication system generates a request to the user's mobile channel with the highest priority.
  • user authorization is performed through additional verification.
  • the additional verification is a biometric verification, a pin code, a graphic code, a sound code, or combinations thereof.
  • the data channel is selected from the Internet, Intranet, LAN, Ethernet, TCP / IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi, Wi-Fi Direct, LPWAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, satellite communications, or combinations thereof.
  • the access resource is a website or software application.
  • the user device is a personal computer, smartphone, laptop, tablet, game console, or smart wearable device.
  • the implementation of a smart wearable device is selected from the group: smart watches, smart bracelet, smart ring, augmented reality tools, mixed reality tools, virtual reality tools.
  • a method for authorizing a user on an access resource using a data channel comprising the steps of:
  • the user authorization data includes at least a user identifier on an access resource in a selected mobile channel.
  • the authorization request is encrypted on the user's device.
  • the authentication system stores available mobile authorization channels for each resource.
  • At least one mobile channel for authorization on a resource is set for each user in the authentication system.
  • Another preferred embodiment of the claimed solution is a method of authorizing a user on an access resource using a data channel, comprising the steps of: form a request for access to a resource using a user device that contains user authorization data;
  • the authentication system when processing a user request for authorization, prioritizes the available mobile channels for user authorization.
  • the authentication system sends a request for confirmation of access to the user's mobile channel with the highest priority.
  • a confirmation policy associated with the mobile channel is established to confirm the access confirmation request.
  • an acknowledgment policy is selected from the group: time interval, acknowledgment of receipt of a message.
  • the authentication system if the specified confirmation policy is not executed, the authentication system generates a second request to another available mobile authorization channel based on the channel prioritization.
  • FIG. 1 illustrates the general scheme of the claimed solution.
  • FIG. 2 - FIG. 3 illustrates a user authorization method.
  • FIG. 4A - FIG. 4D illustrates examples of selecting a mobile authentication channel on a user device using a graphical user interface.
  • FIG. 5A - FIG. 5D illustrates authentication examples using two-factor verification.
  • FIG. 6 illustrates a general view of a user device
  • FIG. 1 shows a general system (100) for the interaction of elements of a claimed solution.
  • Authorization of the user (110) on the access resource (120) is carried out using a user (software) computing device that interacts via the data channel with the access resource (120).
  • the access resource (120) is connected via an appropriate data transmission channel to an authentication system (130), which performs data processing to perform user (110) authorization.
  • a user computing device can represent, for example, a smartphone, tablet, personal computer, laptop, game console, smart TV, wearable smart device (ring, bracelet, watch, glasses, etc.), virtual means reality, augmented reality, mixed reality, etc.
  • the device (software) must 1 provide the processing of the necessary program logic to perform the authorization procedure of the user on one or more resources (120).
  • resources 120.
  • a general description of the main components of the device (10) will be described later in the present description.
  • the data channel can be a different principle and protocols for transmitting information and providing information interaction, for example, Internet, Intranet, LAN, Ethernet, TCP / IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi Wi-Fi Direct, LPWAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, satellite communications, etc.
  • Various implementations and embodiments of the data transmission channel depend on the particular implementation of the information exchange network. It is also worth noting that the data channel can be a direct connection of two or more devices to each other.
  • An access resource (120) refers to an entity (object 1 , application, device, website, etc.) that a user accesses via a data channel, for example, the most common case is a website.
  • Access resource (120) in the current implementation of the technical solution means not only the data itself, for example, accounting data, media data, access information, but also the delivery mechanism, for example, an Internet browser window, a mobile application, elements of a graphical user interface.
  • the access resource (120) may also be an application installed on a user device (110).
  • the access resource (120) may also comprise a data store (121), for example, a database.
  • a data warehouse (121) is a mechanism associated with an access resource (120), which, upon receipt of an access request from a user (110), “recognizes” previously authenticated users (110) to speed up the process of subsequent authentication. This mechanism can use, for example, “cookies” for the resource (120) in the browser, or in another technical form that allows the task to be performed.
  • the authentication system (130) is a hardware-software solution for providing multi-channel access control for authorizing users (110).
  • the authentication system (130) can be integrated into the access resource (120), and the integration can be full or partial.
  • the authentication system (130) may be a remote service interacting by exchanging user authorization requests (110) through an access resource (120) to provide access.
  • the main elements of the authentication system (130) are a data store (131), an access channel assignment module for authentication (132), a user settings module (133), a mobile channel selection and prioritization module (134), a user notification module and a notification module access resource (135).
  • the set of modules may differ for a specific final implementation, in particular, notification modules may be an optional solution.
  • the data warehouse (131) contains basic information to support the process of authorization of users (software).
  • the module (131) stores channel data selected by each user (software) interacting with the system (130), keys / tokens / ID data corresponding to
  • each user in each mobile channel through which authorization is performed or performed.
  • the repository (131) stores algorithms, procedures, and the logic of authorization and notifications for each authorization channel, for example, but not exclusively: timeouts of operations, methods of confirming data delivery, launch rules, periods of repeated authentications, API calls, and other channel details.
  • the number of channels in the system (130) may be greater than the specific access resource (120) chosen to use to solve their own tasks for user authorization (110).
  • the storage (131) contains program logic for managing access keys, in particular, receiving, storing and transmitting authorization keys and / or identifiers (depending on the authorization channel) for each access resource (120) and for each channel selected access resource (120) for its work.
  • Information on all previously authenticated users for each access resource (120) is also transmitted and stored in the data warehouse (131). This information may be associated with stored key data in a data store (131) from a plurality of access resources (120) to provide a centralized authentication service.
  • All authentication events can also be stored in the store (131), including all important technical data about such events, for example, user identifiers, time and place, channel, type of user device, and so on.
  • the authentication access channel assignment module (132) provides keys / identifiers for a plurality of access resources (120).
  • This module (132) can be implemented, for example, in the form of a cloud service associated with access resources (120). Using the module (132), settings of the used authorization channels on access resources (132) are performed.
  • the mobile authorization channel selection module (133) provides an authorization channel selection for the user (110). This functionality can be called inside or outside the perimeter of the access resource (120) (depending on the form of the factor used). Module (133) contains data of only mobile authentication channels selected by the owner of the access resource (120) from the set of all mobile channels whose operation logic is available and stored in the storage (131) of the authentication system (130).
  • the multi-channel selection and prioritization module of mobile channels (134) provides selection and ranking of authentication channels based on the rules established by the logic of the module (134). Module (134) on execution prescribed functions can use user authentication history
  • the channel selection process begins with the selection of one channel (the highest priority) and then the authorization channels are searched until the authentication result is received.
  • the user notification module (135) provides a notification to the user (software) that authentication is currently taking place (may not be used in every implementation of this solution), including the logic of messages about the denial of authentication or expiration, or the need for additional confirmations.
  • the functioning of the logic of this module (135) may require additional actions on the part of the user (software). Most often, such additional actions are required when authenticating the second access factor.
  • the access resource notification module (136) provides notification of the access resource (120) of the authentication result, for example, module (136) can be implemented based on the OAuth protocol.
  • FIG. 2 shows a method of authorizing a user (software) using a mobile authentication channel on an access resource (120). On stage
  • the user initiates the authentication process on the access resource (120).
  • the initiation of a request for access to a resource (120) can be performed, for example, by activating a graphical interface element (GUI) on the device screen (110), for example, an icon, widget, etc., via a web browser or using a software application.
  • GUI graphical interface element
  • the resource (120) Upon receipt of the user request in step (202), the resource (120) processes it.
  • the request includes the user identifier, or a bunch of his authorization data (login / password), 1 user devices and another type of identifying information can also be used.
  • step (203) the authentication system verifies by comparing the received data in the user request and the data stored in the module system memory (131), for the presence of an authentication channel for the corresponding user (software). If a channel is not stored in the system (130) for the user requesting the authentication process, for example, the first access to the resource (120) is performed, then the channel is selected using the module
  • step 211 in which access data is created for the selected channel, which is stored in the storage (131) of the system (130) for the corresponding user. Subsequently, the stored data will be used for subsequent authorization using the selected authentication channel.
  • the source of the request direction is checked, in particular, is the user request from the previously assigned mobile channel for the current user (110) associated with the resource (120) to which
  • a messenger application can be used as a mobile authentication channel.
  • Each channel has its own set of user identification logic and the principle of data processing using algorithms, for example, the principles of data encryption, the formation and transmission of data packets, the notification algorithm, etc.
  • access to the resource is provided through authorization (step 207). Additionally, the data resource (120) can be notified by the system (130) of the fact of positive user authentication (110).
  • step (206) the authentication procedure does not complete successfully, then the logic of the user authentication algorithm (110) may again refer to the authentication system (130) at step (208) to analyze additional mobile authentication channels for the current user (110). If there are additional mobile channels for authentication for the user (software) in the authentication system, then the authentication process proceeds to step (300), which will be described later in the application materials. [0071] If at step (208) for the user (software) there are no additional channels for authentication, the authentication process may begin again.
  • step 209 with repeating the process for the current user-assigned (BUT) mobile authentication channel.
  • Reauthentication can be performed by generating a message, PU BN notification, or other type of alert displayed by the user device (110), in response to which the user (110) initiates reauthentication on the access resource (120).
  • the authentication system (130) informs the resource (120) about the prohibition of user authorization.
  • FIG. 3 illustrates a procedure (300) for selecting a mobile channel for user authentication (software).
  • the choice of a mobile channel can be made when the user (110) did not assign the mobile authentication channel for authorization on the selected access resource (120), or in the case when the user (110) was unable to authenticate using the previously set mobile channel .
  • the user authentication (110) is assigned an additional mobile channel for authentication.
  • step (301) a check is made available to the user (110) of the mobile channels for authentication, information about which is in the authentication system (130). If the user has not yet made the choice of the authentication channel for use on the current access resource (120), then the authentication system (130) checks all authentication channels available to the user, (110), as well as the possibility of using available mobile authentication channels for the current access resource (120) )
  • step (302) After receiving the list of mobile channels available to the user (110) for authorization on the current resource (120), at step (302), an activation check of the mobile channel prioritization mechanism installed in the authentication system (130) for the corresponding user (software) is performed. If the prioritization mechanism is not activated, then at step (303), a mobile channel is selected for user authentication (110), which was used during the last successful authorization on the current access resource (120).
  • step (304) with the mechanism for prioritizing the mobile authentication channels activated, the authentication system (130) performs ranking available mobile channels for implementing the user authorization process (110) on the current access resource (120).
  • Prioritization rules can consist of 1 ... N number of rules, in particular, how to choose the primary
  • Each access resource (120) may have different authentication rules configured. Priorities may include, but are not limited to, the channel usage price, access resource preferences (120), user authorization history, user reaction speed to the channel, the ability to use the channel at the user's location, and so on. Based on the priority of the channels, a channel is selected for authentication with the highest priority, and a subsequent sequence is built for the further use of authentication channels in case of a repeated authentication procedure.
  • the parameters for processing the ranking algorithm can be: the user's location (roaming, the presence of 3G / 4G networks), the conditions of the mobile operator (free access to instant messengers, social networks, etc.), the cost of data transfer using each type of mobile channel (SMS, Internet).
  • SMS mobile subscriber identity
  • the parameters inherent in one or another mobile channel are processed by the algorithm of the prioritization module (134) of the authentication system (130).
  • step (305) the authentication logic for the selected mobile channel is applied in steps (303) or (304) using the corresponding association of identification data (IDs / tokens, etc.) of the user (110) for the selected channel, which are stored in system (130). After processing the data in step (305), the sequence of operations described above for step (205) is performed.
  • step (208) in case of unsuccessful authentication of the user (SO) using the specified authentication channel or one of the channels that has been selected from the set of available authentication channels, the authentication method is performed starting from step (301). If, using the channel selection mechanism of system (130), a mobile channel has already been selected for authentication, the authentication parameters for the next priority channel are used.
  • the authentication system (130) can check the authorization cycle, for example, its duration in a given period of time, the number of iterations, until a positive / negative result is obtained.
  • the implementation has a mechanism for installing and storing these settings for use after checking the last available channel.
  • Resource (120) provides access to the user (BUT) in a manner that is applicable to a particular implementation. For example, if a user (software) requests authorization in a resource (120) through a desktop browser, then after mobile confirmation the user is allowed to access the resource (120). If the user (110) requests authorization in the mobile version of the resource (120), then immediate access may be allowed.
  • step (205) for each channel, its inherent policy for the implementation of the user verification procedure is established based on the received request for access to the resource (120).
  • the method used to execute it is determined by the corresponding mobile channel, for example, entering a code (PIN code, code from an electronic message, etc.), entering characters / words, using EDS, entering a user’s signature on the device’s screen 110), biometric identification (fingerprint, retinal scan, voice input, user image, vein pattern, etc.), the fact of viewing the message (PUSH message), graphic code (for example, QR code, bar code) , time interval for message processing, interaction e with GUI elements, etc.
  • a code PIN code, code from an electronic message, etc.
  • entering characters / words entering characters / words, using EDS
  • entering a user’s signature on the device’s screen 110 entering a user’s signature on the device’s screen 110
  • biometric identification fingerprint, retinal scan, voice input, user image, vein pattern, etc.
  • PUSH message the fact of viewing the message
  • graphic code for example, QR code, bar code
  • FIG. 4A shows an example of selecting authentication channels using a user device (software) GUI.
  • a device (software) interface contains an access resource information display area (112) and an icon location area (111) of mobile channels icons (1111) to (1113). Region (111) may be a popup or widget.
  • FIG. 4B illustrates an example of displaying channel options for user authentication, in addition to icons (1111) to (1113), the most preferred authentication channel (1114) for the current access resource (120) can also be displayed.
  • An icon or button for selecting a channel (1114) can be displayed both automatically when accessing the resource (120) and when certain specified conditions are met, for example, after a certain time period has elapsed, the channel prioritization mechanism has been activated, etc.
  • FIG. 4C shows an example of displaying a desktop version of the device (110), for example, a personal computer, laptop or all-in-one, in which a user can request authentication using mobile channels.
  • the channel is selected using the logic of primarily mobile channels, a link to which exists on the desktop in the form of installed applications or plug-ins, or a link to the selection is delivered to the user's mobile device by any suitable method, for example SMS, push, e-mail, etc. P.
  • the interface window (111) displays both the possible authentication channels (1111) - (1112) and preferred channels (1114).
  • Element (1115) is an interface element by which a list of icons of mobile channels (111) can be called up.
  • FIG. 4D shows an example of selecting an authentication channel in a locked device mode (110).
  • the area (111) with the channel icons (1111) - (1113) can be called up by interacting with the display of the device (110), for example, by swiping from the bottom edge of the screen.
  • GUI can be applied in any possible directions that are accessible through the operation of interface logic or operating system, shell, launcher, etc.
  • FIG. 5A-FIG. 5B illustrates an example of how the platform works using two-factor verification between two devices (110i) - (110 2 ), when one of the devices is in locked mode.
  • a request for user authentication on the resource (120) may enter the device (110 2 ), which may be in locked mode.
  • a notification of receipt in the selected mobile channel for authentication can be displayed in the form of an R&B notification (111), which also arrives in the corresponding mobile authentication channel selected by the user (1111).
  • the activation of the received P H notification (111) can be carried out, in particular, when interacting with an interface element that displays this notification, which will be a confirmation of user authentication using the device (110 2 ). Confirmation may be interaction with the RivN-notification area (111). If confirmation of notification (111) does not occur at the set time, then it is considered that authentication is not performed and either a different channel for authentication is selected or access is denied.
  • a particular authentication confirmation option may be used, in which the system (130) receives a notification from the mobile authentication channel on the device (110 2 ) about viewing the P And notification.
  • the authentication fact is also considered perfect.
  • Viewing also means receiving a response from a user's device
  • (111) may also be purely informational in nature and not require additional activity on the part of the user.
  • inputting information into the field (111) can be performed using text input using a text string generated by the GUI when interaction with the area (111) RiZN notifications.
  • FIG. 5B an example of interaction with the region (111) is presented, for example, using swipe movement with the display of options for confirming or rejecting authentication.
  • an option can be applied with an entrance on the device (110 g) to the installed mobile channel for authentication, for example, Telegram, in which options will be provided for performing or rejecting authentication.
  • An example of such an application is the well-known LoginTap solution.
  • the authentication process using the device (110) provided with a biometric sensor in the display area can be accomplished by transferring an icon with a mobile authentication channel via the operating system GUI to the biometric sensor area to confirm the user selection using the biometric verification.
  • FIG. 5C presents an example of performing two-factor user verification (software) by moving the icon (1112) of the selected authentication channel to the area of the biometric sensor (105) located in the display area of the device (software).
  • user authentication is performed upon recognition of the location of the finger in the area of the sensor (105) with the captured GUI element in the form of a channel icon (1112), which provides additional verification and access protection.
  • FIG. 5D shows an example of authentication using two-factor authentication, which is performed on a user device (software).
  • a confirmation can be sent to a mobile channel (1111), available on the same device (110), for example, Telegram.
  • a notification may be displayed, for example, in the form of a chat session request, with options for confirming or rejecting the authentication process.
  • the authentication parameters are transmitted to the access resource (120) (or the authentication system ((130)) for execution and subsequent provision of access to the resource (120) using the device (110).
  • FIG. 5D An alternative case illustrated in FIG. 5D of performing two-factor authentication on the device (110) when requesting access to the resource (120), there may be a fact of authentication confirmation in another mobile the channel that receives the user authentication request from the authentication system (130), in the case where the first mobile channel (1111), which originally received the request from the resource (120), did not perform authentication.
  • Such a case can occur when a user authentication error occurs with the first channel (1111), for example, the response time from the first authentication channel expires, technical communication problems, defective transmission of identification information (keys / tokens, etc.) from the first channel and etc.
  • access to the resource (120) will be provided upon receipt of user confirmation from the second authentication channel, for example, if the first request was sent to Telegram from the resource (120), then if information is not received or incomplete from the channel, then the request it forwards further to authentication to a second mobile channel accessible to the user, for example, WatsApp, in which, when performing the access confirmation procedure, confirmation information is transmitted to the access resource (120) to uschestvleniya user authorization.
  • WatsApp in which, when performing the access confirmation procedure, confirmation information is transmitted to the access resource (120) to uschestvleniya user authorization.
  • a corresponding mobile authentication channel can be assigned.
  • Such a solution can be organized using appropriate bundles of user identifiers, devices, resources and access channels.
  • an information loop can be formed to provide access, for example, to one access resource by means of a related application through which the participants of the said loop are authenticated.
  • FIG. 6 illustrates an example embodiment of a user device (110).
  • the device (110) can be selected from a wide range of electronic devices known from the prior art.
  • the device (software) contains one or more processors (101) or microcontroller (s), RAM (102), means of permanent data storage (103), input / output interfaces (104), input / output devices (105) , a networking tool (106).
  • the processor (101) is a basic computing module that provides logical processing of the algorithmic instructions necessary for the device (110) to perform the necessary functions.
  • RAM (102) is a standard random access memory designed to store instructions executed by the processor that implement the work of the embedded program logic.
  • Means for permanently storing data (103) may include, but are not limited to: hard disk (HDD), flash memory (NAND, EEPROM, SD cards, etc.), solid state drive (SSD), optical drives data (CD / DVD / BlueRay discs, etc.).
  • I / O Interfaces (104) may include, but are not limited to: ADC / DAC, USB (micro-, Tour C, mini-, etc.), PS / 2, PCI, VGA, RS232, RJ45, FireWire, SATA, IDE, COM, LPT, Audio Jack, HDMI, Display Port, Lightning, etc.
  • Means B (105) may include, but are not limited to: a display, a touch screen, a keyboard (mechanical, touch, projection, etc.), a trackball, joystick, touch pad, speakers, microphone, projector, light indicator, buzzer, biometric sensor (fingerprint, retina, iris, voice, palm, vein pattern, etc.), camera, optical sensor, accelerometer, gyroscope, light sensor, proximity sensor, gravity sensor, etc. .
  • the network interaction tool (106) may be, but not limited to: Bluetooth module, BLE module, NFC, Ethernet card, modem, router, IrDa, GSM modem, GPRS modem, LTE modem, SG modem, WLAN, 'Wi-Fi module, satellite modem, GNSS receiver, etc.

Abstract

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

Description

СПОСОБ И СИСТЕМА МУЛЬТИКАНАЛЬНОЙ АВТОРИЗАЦИИ
ПОЛЬЗОВАТЕЛЯ
Область техники
[0001] Настоящее решение относится к системе и способам для обеспечения авторизации пользователей посредством вычислительной сети, в частности, с помощью мобильной авторизации, в которой пользователю может быть предоставлен доступ в множестве мобильных каналов.
Уровень техники
[0002] Существующая проблема заключается в том, что пользователю необходимо помнить свои логины и пароли к множеству различных источников данных, при этом затраты ресурсов на поддержку пользователей и восстановление логинов/паролей являются достаточно высокими в рамках реализации различных бизнес систем и продуктов. Более того, любые дополнительные действия со стороны пользователя по запоминанию или восстановлению паролей ведут к снижению уровня использования программных продуктов, особенно если речь идет о некритичных для жизни/работы случаях, как например, сервисные приложения или электронная коммерция. 1
[0003] Существуют и вполне известны различные реализации алгоритмов безопасности, с различными степенями защиты, которые решают проблему необходимости помнить или восстанавливать логины/пароли. Начиная от хранения данных логинов в браузерах и от аутентификаций через сторонние сервисы (например, через Google или Facebook, VK, решения Single SignOn (SSO)) и до отдельных приложений“сейфов для паролей”. Некоторые из этих методов также собирают данные о пользователях, что часто не нравится пользователям. Другие известные реализации для решения данной проблемы включают методы требующие установки дополнительного программного обеспечения, производимого и контролируемого третьей стороной (например, Google Authenticator или одной из множества подобных) или требуют дорогостоящих технологических операций, например, отправка СМС сообщения с кодом подтверждения, e-mail подтверждение и т.п. Более того, эти методы безопасности требуют множества дополнительных действий со стороны пользователя, что нежелательно для быстрых и выверенных бизнес операций, особенно в случае с вышеупомянутым не критичным программным обеспечением, как то сервисным или для электронной коммерции. [0004] Другая проблема в том, что вышеописанные существующие методы реализации очень сильно отличаются друг от друга, в зависимости от форм фактора доставки требуемых данных пользователю. Например, между браузером на компьютере, установленным на компьютер приложением, установленным на мобильном устройстве приложением, браузером на мобильном устройстве или другими форм факторами доставки.
[0005] Таким образом, каждый пользователь должен знать разные методы аутентификации и помнить какой конкретно применяется им на конкретном источнике данных (программном обеспечении), что опять же уменьшает полезность источника данных, так как если пользователь забывает как войти, он часто перестает использовать данный источник.
[0006] Известны также решения по принципу авторизации с помощью протокола OAuth (Open Authorization), который представляет собой открытый протокол авторизации, позволяющий предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. Такие решения, например, раскрыты в таких источниках, как: US 20160028737, US20160330199, W02014130141. '
[0007] Недостатком существующих подходов является отсутствие обеспечения мультиканальной авторизации пользователей с помощью использования мобильных каналов, которые сам пользователь может назначать для взаимодействия с одним или множеством ресурсов, взаимодействующих в рамках многоканальной платформы (системы). Также, недостатком является то, что для каждого типа форм- фактора доступа применяется присущий ему метод авторизации, что повышает трудозатратность процессов аутентификации, в частности, увеличение времени для выполнения необходимых действий для авторизации.
Раскрытие изобретения
[0008] Настоящее решение использует только технологии уже установленные в техническом периметре пользователя (например, на его мобильном устройстве) и решает те же самые задачи, которые стремятся решать все вышеописанные подходы, но с высоким уровнем безопасности и с минимальным количеством действий на стороне пользователя, что значительно упрощает процесс его авторизации на ресурсе доступа.
[0009] Настоящее решение обеспечивает пользователю возможность использования меньшего количества методов аутентификации для различных форм факторов доступа к данным, то есть пользователь может всегда использовать один и тот же метод мобильной аутентификации для всех форм факторов получения данных, а также назначать предпочтительный метод авторизации для различных ресурсов доступа. Также, заявленное решение обеспечивает возможность использования различных каналов доступа для заданного ресурса доступа.
[0010] Механизм авторизации настоящего решения может быть как частью аутентификации первого фактора для доступа к данным непосредственно с мобильного устройства, так и вторым фактором аутентификации, при котором доступ к данным на одном устройстве осуществляется через другое мобильное устройство или на этом же устройстве, но из другого канала аутентифкации. Упомянутый механизм также может работать как гибрид loro и 2ого факторов аутентификации на том же самом или разным форм факторах, в тех случаях, когда авторизация первого фактора не прошла или потребовала дополнительного доказательства (второй фактор) из другого канала аутентификации.
[0011] Вышеупомянутые каналы авторизации могут включать, например, иконку на экране мобильного устройства (установленную или в форме PWA, имеющую или не имеющую разрешение на Push уведомления), мобильные службы мгновенных сообщений (мессенджеры и боты в мессенджерах), смс, e-mail, VOIP системы, QR коды и другие каналы.
[0012] В предпочтительном варианте осуществления заявленного решения представлена система авторизации пользователя, содержащая связанные каналом передачи данных устройство пользователя и ресурс доступа, связанный с системой аутентификации, в которой:
устройство пользователя, выполненное с возможностью формирования запроса на авторизацию на ресурсе доступа с помощью по меньшей мере одного мобильного канала, который связан с упомянутым устройством;
ресурс доступа выполнен с возможностью получения пользовательского запроса на авторизацию и передачи соответствующего запроса в систему аутентификации; и система аутентификации, обеспечивающая авторизацию пользователя на упомянутом ресурсе с помощью по меньшей мере одного мобильного канала, связанного с устройством пользователя.
[0013] В частном случае реализации мобильный канал представляет собой программное приложение или элемент графического интерфейса пользователя.
[0014] В другом частном случае реализации приложение представляет собой мессенджер. [0015] В другом частном случае реализации система аутентификации содержит данные о доступных каналах авторизации для каждого из ресурсов доступа.
[0016] В другом частном случае реализации система аутентификации хранит данные авторизации пользователей для каждого из доступных мобильных каналов.
[0017] В другом частном случае реализации запрос на авторизацию содержит по меньшей мере информацию, идентифицирующую пользователя.
[0018] В другом частном случае реализации запрос дополнительно содержит данные доступа выбранного мобильного канала.
[0019] В другом частном случае реализации запрос на авторизацию шифруется на устройстве пользователя и дешифруется в системе аутентификации.
[0020] В другом частном случае реализации система аутентификации дополнительно направляет запрос на подтверждение авторизации в мобильный
I
канал устройства пользователя.
[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] Фиг. 4A - Фиг. 4D иллюстрируют примеры выбора мобильного канала аутентификации на устройстве пользователя с помощью графического интерфейса пользователя.
[0045] Фиг. 5А - Фиг. 5D иллюстрируют примеры аутентификации при использовании двухфакторной верификации.
[0046] Фиг. 6 иллюстрирует общий вид пользовательского устройства
Осуществление изобретения
[0047] На Фиг. 1 представлена общая система (100) взаимодействия элементов заявленного решения. Авторизация пользователя (110) на ресурсе доступа (120) осуществляется с помощью пользовательского (ПО) вычислительного устройства, осуществляющего взаимодействие посредством канала передачи данных с ресурсом доступа (120). Ресурс доступа (120) подключен посредством соответствующего канала передачи данных к системе аутентификации (130), которая выполняет обработку данных для осуществления пользовательской (110) авторизации.
[0048] Пользовательское вычислительное устройство (ПО) может представлять, например, смартфон, планшет, персональный компьютер, ноутбук, игровую приставку, смарт-телевизор, носимое умное устройство (кольцо, браслет, часы, очки и т.п.), средство виртуальной реальности, средство дополненной реальности, средство смешанной реальности и т.п. Устройство (ПО) должно1 обеспечивать обработку необходимой программной логики для выполнения процедуры авторизации пользователя на одном или более ресурсах (120). Общее описание основных компонентов устройства (10) будет раскрыто далее в настоящем описании.
[0049] Канал передачи данных может представлять собой различный принцип и протоколы для передачи информации и обеспечения информационного взаимодействия, например, Интернет, Интранет, LAN, Ethernet, TCP/IP, WAN, WLAN, MAN, CAN, SAN, PAN, Wi-Fi, Wi-Fi Direct, LPWAN, GSM, GPRS, LTE, 5G, Bluetooth, BLE, IrDa, NFC, спутниковая связь и т.п. Различные имплементации и воплощения канала передачи данных зависят от конкретной реализации информационной сети обмена. Стоит также отметить, что канал передачи данных может представлять собой прямое подключение двух и более устройств между собой.
[0050] Под ресурсом доступа (120) понимается сущность (объект1, приложение, устройство, веб-сайт и т.п.), к которой пользователь получает доступ с помощью канала передачи данных, например, наиболее распространенный случай - веб-сайт. Ресурс доступа (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) содержит основную информацию для обеспечения процесса авторизации пользователей (ПО). В модуле (131) хранятся данные каналов, выбранные каждым пользователем (ПО), осуществляющим взаимодействие с системой (130), ключи/токены/ID данные, соответствующие
I
каждому пользователю (ПО) в каждом мобильном канале, с помощью которого выполняется или выполнялась авторизация.
[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) при выполнении предписанных функций может использовать историю аутентификаций пользователя
(ПО) и данные о разрешённых каналах ресурсом доступа (120). Процесс выбора канала начинается с выбора одного канала (наиболее приоритетного) и далее выполняется перебор каналов авторизации до получения результата аутентификации.
[0062] Модуль уведомления пользователя (135) обеспечивает уведомление пользователя (ПО) о том, что аутентификация происходит в данный момент (может не применяться в каждой реализации настоящего решения), включая логику сообщений об отказе в аутентификации или о просрочке, или о необходимости дополнительного подтверждения. Функционирование логики данного модуля (135) может требовать дополнительных действий со стороны пользователя (ПО). Чаще всего такие дополнительные действия требуются при аутентификации второго фактора доступа.
[0063] Модуль уведомления ресурса доступа (136) обеспечивает уведомление ресурса доступа (120) о результате аутентификации, например, модуль (136) может быть реализован на основании протокола OAuth.
[0064] На Фиг. 2 представлен способ авторизации пользователя (ПО) с помощью мобильного канала аутентификации на ресурсе доступа (120). На этапе
(201) пользователь инициирует процесс аутентификации на ресурсе доступа (120). Инициирование запроса на доступ к ресурсу (120) может выполняться, например, через активацию элемента графического интерфейса (GUI) на экране устройства (110), например, иконку, виджет и т.п., через веб-браузер или с помощью программного приложения. Далее запрос от устройства пользователя (110) на этапе
(202) передается на ресурс доступа (120).
[0065] При получении пользовательского запроса на этапе (202) ресурс (120) осуществляет его обработку. Запрос, как правило, включает в себя идентификатор пользователя, либо связку его данных авторизации (логин/пароль),1 также может дополнительно использоваться Ш устройства пользователя и иной тип идентифицирующей информации. Ресурс доступа (120) на этапе (203) по полученным идентификаторам пользователя осуществляет проверку наличия для данного пользователя (110) установленного мобильного канала аутентификации, с помощью передачи упомянутых данных идентификации в систему аутентификации (130) (этап 203).
[0066] На этапе (203) система аутентификации проверяет с помощью сравнения полученных данных в пользовательском запросе и данных, хранящихся в модуле памяти системы (131), на наличие канала аутентификации для соответствующего пользователя (ПО). Если для пользователя, запрашивающего процесс аутентификации, в системе (130) не сохранено канала, например, выполняется первый доступ к ресурсу (120), то осуществляется выбор канала с помощью модуля
(133) (этап 211), при котором для выбранного канала создаются данные доступа, которые сохраняются в хранилище (131) системы (130) для соответствующего пользователя. Впоследствии сохраненные данные будут применяться для последующей авторизации с помощью выбранного канала аутентификации.
[0067] На этапе (204) проверяется источник направления запроса, в частности, осуществляется ли пользовательский запрос из ранее назначенного мобильного канала для текущего пользователя (110), связанный с ресурсом (120), к которому
1
выполняется запрос на аутентификацию. Если мобильный канал уже назначен и его данные сохранены для текущего пользователя (ПО) и соответствующего ресурса доступа (120)в системе аутентификации (130), то осуществляется дальнейшее выполнение логики и правил аутентификации, заложенных для данного мобильного канала (этап 205).
[0068] Например, в качестве мобильного канала аутентификации может использоваться приложение мессенджер (Telegram, WhatsApp, FaceBook Messenger, Slack, Viber и т.п.). Каждый канал имеет свою заданную логику идентификации пользователей и принцип обработки данных с помощью алгоритмов, например, принципы шифрования данных, формирование и передачу пакетов данных, алгоритм уведомления и т.п.
[0069] При выполнении необходимых требований по организации аутентификации с помощью логики мобильного канала на этапе (206), пользователю
I
предоставляется доступ к ресурсу с помощью его авторизации (этап 207). Дополнительно ресурс данных (120) может уведомляться системой (130) о факте положительной аутентификации пользователя (110).
[0070] Если на этапе (206) процедура аутентификации завершается не успешно, то логика алгоритма аутентификации пользователя (110) может заново обратиться к системе аутентификации (130) на этапе (208) для анализа дополнительных мобильных каналов аутентификации для текущего пользователя (110). Если для пользователя (ПО) в системе аутентификации имеются дополнительные мобильные каналы для аутентификации, то процесс аутентификации переход на этап (300), который будет описан далее в материалах заявки. [0071] В случае, если на этапе (208) для пользователя (ПО) нет дополнительных каналов для аутентификации, то процесс аутентификации может начаться заново
(этап 209) с повторением процесса для текущего назначенного пользователем (НО) мобильным каналом аутентификации. Повторная аутентификация может выполняться с помощью генерирования сообщения, PU БН-уведомл ени я или иного типа оповещения, отображаемого с помощью устройства пользователя (110), в ответ на которое пользователь (110) инициирует повторную аутентификацию на ресурсе доступа (120). При отказе от повторной процедуры аутентификации, на этапе (210) система аутентификации (130) сообщает ресурсу (120) о запрете авторизации пользователя.
[0072] На Фиг. 3 представлена процедура (300) выбора мобильного канала для аутентификации пользователем (ПО). Как было указано выше, выбор мобильного канала может осуществляться когда пользователь (110) не осуществлял назначение мобильного канала аутентификации для авторизации на выбранном ресурсе доступа (120), либо в случае, когда пользователь (110) не смог выполнить аутентификацию с помощью установленного заранее мобильного канала. При таком сценарии выполнения аутентификации пользователя (110) осуществляется назначение дополнительного мобильного канала для аутентификации.
[0073] На этапе (301) выполняется проверка доступных для пользователя (110) мобильных каналов для аутентификации, информация о которых находится в системе аутентификации (130). Если пользователь еще не выполнял выбор канала аутентификации для использования на текущем ресурсе доступа (120), то система аутентификации (130) проверяет все доступные для пользователя ,(110) каналы аутентификации, а также возможность применения доступных мобильных каналов аутентификации для текущего ресурса доступа (120).
[0074] После получения перечня мобильных каналов, доступных пользователю (110) для авторизации на текущем ресурсе (120), на этапе (302) выполняется проверка активации механизма приоритезации мобильных каналов, установленного в системе аутентификации (130) для соответствующего пользователя (ПО). Если механизм приоритезации не активирован, то на этапе (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) в случае неуспешной аутентификации пользователя (ПО) с помощью заданного канала аутентификации или одного из каналов, который был выбран из набора доступных каналов аутентификации, способ аутентификации выполняется процедуру, начиная с этапа (301). Если с помощью механизма выбора каналов системы (130) уже выполнялся выбор мобильного канала для аутентификации, то используются параметры аутентификации для следующего приоритетного канала.
[0080] Также, система аутентификации (130) может проверять цикл авторизации, например, его продолжительность в заданный промежуток времени, количество итераций, до получения положительного/отрицательного результата. В таком случае реализация имеет механизм установки и хранения этих установок для применения их после проверки последнего доступного канала.
[0081] Ресурс (120) предоставляет доступ пользователю (НО) тем способом, который применим для конкретной реализации. Например, если пользователь (ПО) запрашивает авторизацию в ресурсе (120) через десктоп браузер, то после мобильного подтверждения пользователь допускается на ресурс доступа (120). Если пользователь (110) запрашивает авторизацию в мобильной версии ресурса (120), тогда незамедлительный доступ может быть разрешен.
[0082] Дополнительно для процесса аутентификации устройства пользователя (110) может применяться дополнительная верификация пользователя в мобильном канале доступа, например, двухфакторная аутентификации (2FA - Two factor authentication). На этапе (205) для каждого из каналов устанавливается присущая ему политика осуществления процедуры верификации пользователя, исходя из полученного запроса на доступ к ресурсу (120). При условии, применении 2FA определяется используемый соответствующим мобильным каналом способ ее выполнения, например, ввод кода (PIN-код, код из электронного сообщения и т.п.), ввод символов/слов, применение средств ЭЦП, ввод подписи пользователя на экране устройства (110), биометрическая идентификация (отпечаток пальца, сканирование сетчатки глаза, голосовой ввод, изображения пользователя, рисунок вен и т.п.), факт просмотра сообщения (PUSH-сообщения), графический код (например, QR-код, bar- код), временной интервал обработки сообщения, взаимодействие с элементами графического интерфейса и т.п. Могут применяться различные известные из уровня техники принципы подтверждения доступа пользователя (110) к выбранному каналу данных.
[0083] При передаче пользовательского запроса в систему аутентификации (130), к запросу может применяться один или несколько алгоритмов шифрования, например, RSA, SHA-256 и т.п. Данный подход обеспечивает дополнительную защиту при обмене информационными пакетами, содержащими идентификационные данные пользователя (ПО) и данные для выполнения процедуры аутентификации в канале пользователя. [0084] На Фиг. 4А представлен пример выбора каналов аутентификации с помощью GUI пользовательского устройства (ПО).Интерфейс устройства (ПО) содержит область отображения информации о ресурсе доступа (112) и область (111) расположения иконок (1111)-(1113) мобильных каналов. Область (111) может представлять собой всплывающее окно или виджет. При активации выбранной иконки с каналом доступа выполняется процедура связывания выбранного канала аутентификации с текущим ресурсом доступа или, например, ресурсом, связанным с данной иконкой.
[0085] Фиг. 4В иллюстрирует пример с отображением вариантов каналов для аутентификации пользователя, в котором помимо иконок (1111)-(1113) может также отображаться наиболее предпочтительный канал аутентификации (1114) для текущего ресурса доступа (120). Иконка или кнопка для выбора канала (1114) может отображаться как автоматически при осуществлении доступа к ресурсу (120), так и при выполнении определенных заданных условий, например, прошествии определенного временного периода, активации механизма приоритезации каналов и т.п.
[0086] На Фиг. 4С представлен пример отображения десктопной версии устройства (110), например, персональный компьютер, ноутбук или моноблок, в которой пользователь может запросить аутентификацию с помощью мобильных каналов. В этом случае выбор канала делается, используя логику первично мобильных каналов, связка с которыми существует на десктопе в виде установленных приложений или плагинов, или ссылка на выбор доставляется на мобильное устройство пользователя любым приемлемым методом, например СМС, push, e-mail и т.п. Окно интерфейса (111) отображает как возможные варианты выбора каналов аутентификации (1111)-(1112), так и предпочтительные каналы (1114). Элемент (1115) представляет собой элемент интерфейса, с помощью которого может выполняться вызов списка иконок мобильных каналов (111).
[0087] На Фиг. 4D представлен пример выбора канала аутентификации при заблокированном режиме устройства (110). Область (111) с иконками каналов (1111)-(1113) может вызываться при помощи взаимодействия с дисплеем устройства (110), например, с помощью свайп- движения от нижней кромки экрана. Специалисту должно быть очевидно, что могут применятся другие варианты взаимодействия с GUI устройства (ПО) в любых возможных направлениях, доступных с помощью работы логики интерфейса или операционной системы, оболочки, лаунчера и т.п. [0088] Фиг. 5А-Фиг. 5В иллюстрируют пример работы платформы с помощью двухфакторной верификации между двумя устройствами (110i)-(1102), в случае когда одно из устройств находится в заблокированном режиме. При необходимости аутентификации на ресурсе доступа (120) на первом устройстве (110i), если для ресурса (120) имеется назначенный канал доступа или пользователь имеет несколько доступных каналов для осуществления процесса аутентификации на упомянутом ресурсе (120), то запрос на аутентификацию пользователя на ресурсе (120) может поступать на устройство (1102), которое может находиться в заблокированном режиме. В этом случае уведомление о поступлении в выбранный мобильный канал для аутентификации может отображаться в виде РиБН-уведомления (111), которое также приходит в соответствующий выбранный пользователем мобильный канал аутентификации (1111). Активация полученного Р Н-уведомления (111) может осуществляться, в частности, при взаимодействии с элементом интерфейса, отображающим данное уведомление, что будет являться, подтверждением пользовательской аутентификации с помощью устройства (1102). Подтверждением может являться взаимодействие с областью РивН-уведомления (111). Если подтверждение уведомления (111) не происходит в установленное время, то считается, что аутентификация не выполняется и осуществляется либо выбор другого канала для аутентификации, либо запрет на предоставление доступа.
[0089] В то же время, может использоваться частный вариант подтверждения аутентификации, при котором, система (130) получает уведомление из мобильного канала аутентификации на устройстве (1102) о просмотре Р И-уведомления. В этом случае факт аутентификации также считается совершенным. Под термином
“просмотр” также подразумевается получения отклика от устройства пользователя
(1102), подтверждающего, что пользователь увидел PUSH-уведомление (111), например, с помощью получения данных от сенсоров мобильного устройства (1102)
(гироскоп, камера, датчик приближения и т.п.). Само по себе PU БН-уведомление
(111) также может носить сугубо информационный характер и не требовать дополнительной активности со стороны пользователя.
[0090] Также, одним из частных примеров подтверждения аутентификации пользователя устройства (1102) при отправке подтверждения от другого устройства с помощью PUSH-уведомления, ввод информации в поле (111) может выполняться с помощью текстового ввода с помощью текстовой строки, генерируемой GUI при взаимодействии с областью (111) РиЗН-уведомления. [0091] На Фиг. 5В представлен пример взаимодействия с областью (111), например, с помощью свайп движения с отображением вариантов для подтверждения или отклонения аутентификации. Также, дополнительно может применяться вариант со входом на устройстве (110г) в установленный мобильный канал для аутентификации, например, Telegram, в котором будут предоставляться варианты для выполнения или отклонения аутентификации. Примером таких приложения может служить известное решение LoginTap.
[0092] В различных вариантах осуществления, выполнение процесса аутентификации с помощью устройства (110) снабженного биометрическим сенсором в области дисплея, может выполнятся с помощью переноса посредством GUI операционной системы иконки с мобильным каналом аутентификации в область биометрического сенсора для осуществления подтверждения пользовательского выбора с помощью биометрической верификации.
[0093] На Фиг. 5С представлен представлен пример выполнения двухфакторной верификации пользователя (ПО) с помощью перемещения иконки (1112) выбранного канала аутентификации в область биометрического сенсора (105), расположенного в зоне дисплея устройства (ПО). В такой реализации аутентификация пользователя выполняется при распознавании нахождения пальца области в области сенсора (105) с захваченным элементом GUI в виде иконки (1112) канала, что обеспечивает дополнительную верификацию и защиту обеспечения доступа.
[0094] На Фиг. 5D изображен пример выполнения аутентификации с помощью двухфакторной аутентификации, которая выполняется на устройстве (ПО) пользователя. При запросе на доступ к ресурсу (120), например, веб-сайту или приложению (установленному на устройстве (ПО) или веб-приложёнию и т.п.) с устройства (ПО), подтверждение может отправляться в мобильный канал (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) может выбираться из широкого перечня электронных устройств, известных из уровня техники. В общем случае устройство (ПО) содержит один или несколько процессоров (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-модем, SG-модем, WLAN, 'Wi-Fi модуль, спутниковый модем, ГНСС - приемник и т.п.
[0104] Представленные описание заявленного решения раскрывает лишь предпочтительные примеры его реализации и не должно трактоваться как ограничивающее иные, частные примеры его осуществления, не выходящие за рамки объема правовой охраны, которые являются очевидными для специалиста соответствующей области техники.

Claims

Формула
1. Система авторизации пользователя, содержащая связанные каналом передачи данных устройство пользователя и ресурс доступа, связанный с системой аутентификации, в которой:
- устройство пользователя, выполненное с возможностью формирования запроса на авторизацию на ресурсе доступа с помощью по меньшей мере одного мобильного канала, который связан с упомянутым устройством;
- ресурс доступа выполнен с возможностью получения пользовательского запроса на авторизацию и передачи соответствующего запроса в систему аутентификации; и
- система аутентификации, обеспечивающая авторизацию пользователя на упомянутом ресурсе с помощью по меньшей мере одного мобильного канала, связанного с устройством пользователя.
2. Система по п.1, характеризующаяся тем, что мобильный канал представляет собой программное приложение или элемент графического интерфейса пользователя.
3. Система по п.2, характеризующаяся тем, что приложение представляет собой мессенджер.
4. Система по п.1, характеризующаяся тем, что система аутентификации содержит данные о доступных каналах авторизации для каждого из ресурсов доступа.
5. Система по п.1, характеризующаяся тем, что система аутентификации хранит данные авторизации пользователей для каждого из доступных мобильных каналов.
6. Система по п.1 , характеризующаяся тем, что запрос на авторизацию содержит по меньшей мере информацию, идентифицирующую пользователя.
7. Система по п.6, характеризующаяся тем, что запрос дополнительно содержит данные доступа выбранного мобильного канала.
8. Система по п.7, характеризующаяся тем, что запрос на авторизацию шифруется на устройстве пользователя и дешифруется в системе аутентификации.
9. Система по п.5, характеризующаяся тем, что система аутентификации дополнительно направляет запрос на подтверждение авторизации в мобильный канал устройства пользователя.
10. Система по п.9, характеризующаяся тем, что система аутентификации осуществляет авторизацию пользователя на ресурсе на основании получения ответа от мобильного канала устройства пользователя.
11. Система по п.9, характеризующаяся тем, что при получении запроса от устройства пользователя на авторизацию, система аутентификации осуществляет проверку доступных мобильных каналов для данного пользователя.
12. Система по п.12, характеризующаяся тем, что система аутентификации выполняет приоритезацию мобильных каналов для авторизации пользователя.
13. Система по п.13, характеризующаяся тем, что система аутентификации формирует запрос в мобильный канал пользователя с наибольшим приоритетом.
14. Система по п.1, характеризующаяся тем, что авторизация пользователя выполняется посредством дополнительной верификации.
15. Система по п.15, характеризующаяся тем, что дополнительная верификация представляет собой биометрическую верификацию, пин-код, графический код, звуковой код или их сочетания.
16. Система по п.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, спутниковая связь или их сочетания.
17. Система по п.1, характеризующаяся тем, что ресурс представляет собой веб- сайт или программное приложение.
18. Система по п.1, характеризующаяся тем, что устройство пользователя представляет собой персональный компьютер, смартфон, ноутбук, планшет, игровую приставку или умное носимое устройство.
19. Система по п.19, характеризующаяся тем, что умное нрсимое устройство выбирается из группы: смарт-часы, смарт-браслет, смарт-кольцо, средства дополненной реальности, средства смешанной реальности, средства виртуальной реальности.
20. Способ авторизации пользователя на ресурсе доступа с помощью канала передачи данных, содержащий этапы, на которых:
- формируют запрос на доступ к ресурсу с помощью устройства пользователя, который содержит данные авторизации пользователя, причем запрос выполняется из мобильного канала, доступного на упомянутом устройстве пользователя;
- передают упомянутый запрос на доступ к ресурсу в связанную с упомянутым ресурсом систему аутентификации;
- осуществляют сравнение с помощью системы аутентификации данных авторизации пользователя для выбранного мобильного канала из полученного запроса, с данными доступа, хранящимися в системе аутентификации; и
- обеспечивают авторизацию упомянутого пользователя на упомянутом ресурсе с помощью упомянутого мобильного канала, в случае успешной проверки пользовательского запроса.
21. Способ по п.20, характеризующийся тем, что данные авторизации пользователя включают в себя по меньшей мере идентификатор пользователя на ресурсе доступа в выбранном мобильном канале.
22. Способ по п.21, характеризующийся тем, что запрос на авторизацию шифруется на устройстве пользователя.
23. Способ по п.20, характеризующийся тем, что система аутентификации хранит для каждого ресурса доступные мобильные каналы авторизации.
24. Способ по п.23, характеризующийся тем, что для каждого пользователя в системе аутентификации установлен по меньшей мере один мобильный канал для авторизации на ресурсе доступа.
25. Способ авторизации пользователя на ресурсе доступа с помощью канала передачи данных, содержащий этапы, на которых:
- формируют запрос на доступ к ресурсу с помощью устройства пользователя, который содержит данные авторизации пользователя;
- передают упомянутый запрос на доступ к ресурсу в связанную с упомянутым ресурсом систему аутентификации;
- проверяют в системе аутентификации доступность для упомянутого пользователя одного или более мобильных каналов для авторизации с помощью сравнения данных авторизации пользователя с данными, хранящимися в системе аутентификации;
- направляют в по меньшей мере один мобильный канал авторизации, доступный пользователю, запрос подтверждения доступа;
- осуществляют подтверждение доступа с помощью мобильного канала на устройстве пользователя, в который поступил запрос от системы аутентификации, или получают отрицательное подтверждение о несанкционнированном доступе в упомянутом мобильном канале; и
- выполняют авторизацию пользователя на упомянутом ресурсе, в случае успешного подтверждения запроса доступа, или запрещают доступ при получении отрицательного подтверждения.
26. Способ по п.25, характеризующийся тем, что при обработке пользовательского запроса на авторизацию система аутентификации осуществляет приоритезацию доступных мобильных каналов для авторизации пользователя.
27. Способ по п.26, характеризующийся тем, что система аутентификации направляет запрос на подтверждение доступа в мобильный канал пользователя с наибольшим приоритетом.
28. Способ по п.27, характеризующийся тем, что для подтверждения запроса на подтверждение доступа устанавливается политика подтверждения, связанная с мобильным каналом.
29. Способ по п.28, характеризующийся тем, что политика подтверждения выбирается из группы: временной интервал, подтверждение получение сообщения.
30. Способ по п.29, характеризующийся тем, что при невыполнении заданной политики подтверждения система аутентификации формирует повторный запрос в другой доступный мобильный канал авторизации, на основании приоритезации каналов.
PCT/RU2018/000611 2018-09-18 2018-09-18 Способ и система мультиканальной авторизации пользователя WO2020060432A1 (ru)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/276,835 US11799866B2 (en) 2018-09-18 2018-09-18 Method and system of multi-channel user authorization
PCT/RU2018/000611 WO2020060432A1 (ru) 2018-09-18 2018-09-18 Способ и система мультиканальной авторизации пользователя

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2018/000611 WO2020060432A1 (ru) 2018-09-18 2018-09-18 Способ и система мультиканальной авторизации пользователя

Publications (1)

Publication Number Publication Date
WO2020060432A1 true WO2020060432A1 (ru) 2020-03-26

Family

ID=69887682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2018/000611 WO2020060432A1 (ru) 2018-09-18 2018-09-18 Способ и система мультиканальной авторизации пользователя

Country Status (2)

Country Link
US (1) US11799866B2 (ru)
WO (1) WO2020060432A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200143375A1 (en) * 2018-11-05 2020-05-07 Mastercard International Incorporated Methods and systems for adapting timeout period for authentication in payment processing

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112511569B (zh) * 2021-02-07 2021-05-11 杭州筋斗腾云科技有限公司 网络资源访问请求的处理方法、系统及计算机设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090119754A1 (en) * 2006-02-03 2009-05-07 Mideye Ab System, an Arrangement and a Method for End User Authentication
US20150172292A1 (en) * 2009-02-03 2015-06-18 Inbay Technologies Inc. Method and system for authenticating a security device
US20160292412A1 (en) * 2015-03-31 2016-10-06 Yahoo! Inc. Auto-creation of application passwords
US20160300054A1 (en) * 2010-11-29 2016-10-13 Biocatch Ltd. Device, system, and method of three-dimensional spatial user authentication

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112012004781T5 (de) * 2011-11-16 2014-08-07 Flextronics Ap, Llc Versicherungsverfolgung
US11164254B1 (en) * 2018-02-14 2021-11-02 Equity Shift, Inc. Blockchain instrument for transferable equity
US20210058970A1 (en) * 2019-11-08 2021-02-25 Intel Corporation Mechanisms to operate on a downlink wideband carrier in unlicensed band

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090119754A1 (en) * 2006-02-03 2009-05-07 Mideye Ab System, an Arrangement and a Method for End User Authentication
US20150172292A1 (en) * 2009-02-03 2015-06-18 Inbay Technologies Inc. Method and system for authenticating a security device
US20160300054A1 (en) * 2010-11-29 2016-10-13 Biocatch Ltd. Device, system, and method of three-dimensional spatial user authentication
US20160292412A1 (en) * 2015-03-31 2016-10-06 Yahoo! Inc. Auto-creation of application passwords

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200143375A1 (en) * 2018-11-05 2020-05-07 Mastercard International Incorporated Methods and systems for adapting timeout period for authentication in payment processing
US11587090B2 (en) * 2018-11-05 2023-02-21 Mastercard International Incorporated Methods and systems for adapting timeout period for authentication in payment processing

Also Published As

Publication number Publication date
US11799866B2 (en) 2023-10-24
US20220038463A1 (en) 2022-02-03

Similar Documents

Publication Publication Date Title
US11019048B2 (en) Password state machine for accessing protected resources
JP6895431B2 (ja) アクセス管理のためのパスワードレス認証
US11657396B1 (en) System and method for bluetooth proximity enforced authentication
EP3420677B1 (en) System and method for service assisted mobile pairing of password-less computer login
EP3365827B1 (en) End user initiated access server authenticity check
US10009340B2 (en) Secure, automatic second factor user authentication using push services
US10225283B2 (en) Protection against end user account locking denial of service (DOS)
US10116448B2 (en) Transaction authorization method and system
EP3916593B1 (en) System and method for efficiently enrolling, registering, and authenticating with multiple authentication devices
US9781105B2 (en) Fallback identity authentication techniques
US11290443B2 (en) Multi-layer authentication
EP3272093B1 (en) Method and system for anti-phishing using smart images
CN112425114A (zh) 受公钥-私钥对保护的密码管理器
EP3584731A1 (en) Authentication management method and system
US11799866B2 (en) Method and system of multi-channel user authorization
RU2786176C2 (ru) Способ и система мультиканальной авторизации пользователя
EP4203535A1 (en) Systems and methods for credentials sharing
US20230171238A1 (en) Systems and Methods for Using an Identity Agent to Authenticate a User

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18934209

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18934209

Country of ref document: EP

Kind code of ref document: A1