WO2018029564A1

WO2018029564A1 - System and method for authentication of a user of an application system by a central server, without using a password

Info

Publication number: WO2018029564A1
Application number: PCT/IB2017/054589
Authority: WO
Inventors: Guillaume Dorbes
Original assignee: Auvercloud
Priority date: 2016-08-09
Filing date: 2017-07-27
Publication date: 2018-02-15
Also published as: FR3055053A1

Abstract

The invention relates to a method for the authentication of a user of an application system (10) by a central server (20), comprising the steps in which: an application system (10) carries out (50) an authentication request; the central server (20) receives (51) the request and generates (55) a token with a limited duration for a plurality of authentication modes; the central server (20) sends (56) the generated tokens, in parallel, to a plurality of appliances (10) of the user to be authenticated; a reception/response module (31) of at least one of the user appliances (30) receives (57) the token therefor, modifies (58) the token, and sends it back to the central server (20); the central server (20) receives (59) the modified token; and the authentication module (24) of the central server (20) validates (61) the authentication and transmits said validation to the requesting application system (10).

Description

SYSTEM AND METHOD FOR AUTHENTICATION WITHOUT PASSWORD OF A USER OF AN APPLICATION SYSTEM BY A CENTRAL SERVER

TECHNICAL FIELD OF THE INVENTION [0001] The present invention relates to an authentication system without password of a user of an application system by a central server. It also relates to a method of authentication without password of a user of an application system by a central server. STATE OF THE PRIOR ART

[0002] In a conventional manner, when a user wishes to connect to an application system, he must first of all carry out an authentication phase. This phase ensures that the user requesting the identification is the real user. This aspect is even more important if the application system includes personal and / or confidential data concerning this user. Very often, the authentication process involves entering unique ID and password data. This mode of authentication is very widespread for thousands of application systems of all kinds. Many users have count or access to a large number of application systems. Managing multiple login and password data is a recurring problem, which has not yet found a truly satisfactory solution.

It is also observed that a large proportion of these application systems provide simple tools to allow users who have forgotten password data and / or unique identifier to retrieve this data by simply sending an email by the application system. For example, if a user forgets his password, he provides the data of his email address, or phone number, or other. The application system then sends the user an email, sms, or other type of message, including the requested data, such as the password. Other application systems send an email with a link that allows you to create a new password. In all these cases, it is assumed that the sending of data Authentication using a previously known e-mail address, telephone number, postal address, IP address, or other, has a level of security satisfactory to the user compared to the application system concerned. Some systems provide for the use of hardware, such as a smart card, to enable enhanced security authentication. These systems add levels of complexity that discourage some users.

The use of a single authentication mode for a given user may give rise to certain practical disadvantages. In addition, the mode of transmission concerned (email, sms, etc.) may be temporarily out of service or inaccessible to the user, making authentication impossible.

It therefore persists a long-standing need to simplify, make reliable, and perpetuate the authentication tools.

We also know some tools designed to try to answer this problem. For example, the document FR3015824 discloses a method of managing data connection to a device via a network, the method comprising a step of receiving, by a referencing server, from said equipment, connection data to said equipment. and at least one authentication token generated from at least one identifier assigned to said equipment and from at least one authentication data of a user of said equipment, a step of referencing said equipment by the server referencing by storage of the connection data received in association with at least one referencing key comprising said at least one authentication token, a step of reception by the server, from a terminal, of at least one request for obtaining connection data comprising a referencing key, a step of transmitting to said terminal connection data stored in association with iation with the received SEO key. This method also facilitates the connection between two devices, one for which the IP address is variable. [0009] Document FR 2940727 describes a method for authenticating a user of the Internet network on a machine offering a service based on the HTTP or HTTPS protocol, without compelling the user to remember a password, with a view to open a session uniquely identified on the server. At first, during his first registration request, the user provides his email address. It is then registered in the temporary account database and receives an email containing a hypertext link allowing it to be permanently registered in the account database. This email also contains a link that allows the user to log in later, once registered. In a second step, the user clicks on the registration link and the server then executes the final registration request. Subsequently, the user can continue to use the connection link to connect, until expiry of the validity of the latter or until its voluntary disconnection of the website. Beyond this period or after its disconnection, the user will have to receive a new login email. These emails constitute "connection tickets" making it possible to send a request to check the membership of the user to the account base. This authentication method is intended for all websites having a user account base. This method however has little flexibility due to the mandatory use of email to make a connection.

[0010] WO2015047555A1 discloses a method and system for automatically authenticating a user account using multiple services. According to some embodiments of the disclosed object, the methods of authenticating a user using multiple services are provided, the methods comprising: receiving, from a client device, first information of identification for a target service account; Authenticate the target service account based on the first credentials; issuing a redirection request that directs the client device to at least one responder service, in response to the authentication of the target service account; receiving a respondent response indicating that the client device has authenticated a respondent service account with at least one respondent service, wherein the respondent response includes a responder token; and provide the client device access to the account target service in response to determining that the respondent service account is associated with the target service account. This process is complex to implement and has little operational flexibility. Other methods involve the use of specific technical means. For example, the document WO 2008/060725 provides for the use of a biometric reader, intended to identify a user. This type of system is impractical because it requires a very specific equipment, properly set. Existing application systems must therefore be equipped before they can be considered for implementation of the process.

Document US2015249540 discloses an authentication method with several devices, for which a challenge is generated. This authentication mode is particularly common, but has some disadvantages. In addition, the user is asked and forced to answer the challenge questions. The user must therefore be both available and able to answer questions correctly, which is often a constraint for many users. To overcome these disadvantages, the invention provides different technical means.

SUMMARY OF THE INVENTION

First, a first object of the invention is to provide a system and an authentication method allowing the user to connect to an application system without having to memorize or even use a password.

Another object of the invention is to provide a system and an authentication method that ensures a fast and reliable implementation, regardless of the context of availability of the user and / or communication networks used. Yet another object of the invention is to provide a system and an authentication method easy and simple to set up and use, without having to install specific equipment in the users. Yet another object of the invention is to provide a system and an authentication method to achieve a satisfactory level of security for the user and the application service.

To do this, the invention provides a method of authenticating a user of an application system having a plurality of authentication modes by a central server with data from the users of the application system and data. authentication modes for each of the users, comprising the steps in which:

the application system performs a user authentication request to the central server;

the central server receives the authentication request from the application system; the central server takes into account the required data of the application system and the user identifier data;

according to the user identifier data, the central server takes into account the authentication mode data set up for this user; the central server generates a time-limited token for each of the authentication modes identified for that user;

the central server sends within a very short time interval, for each authentication mode of the user to authenticate the generated tokens, a token for each of the authentication modes;

a receiving / response module of at least one of the user devices receives the token that is intended for it;

upon receipt of a user command, the receiving / response module having received said token modifies the token and sends it back to the central server;

- the central server receives the modified token;

the authentication module of the central server validates the authentication and transmits this validation to the requesting application system, which in turn can accept the authentication request and launch the corresponding application;

-the authentication module of the central server deactivates the tokens sent in parallel that are still active.

By "substantially simultaneous" is meant within a very short time interval, such as for example less than or equal to a few tenths of a second between the first and the last sending, or up to a few seconds, for example 5 or 10 seconds between the first and the last sending.

The method allows a user to connect to an application system without the usual constraint of having to remember a password to provide the latter to enable authentication. The method also makes it possible to perform authentication automatically and very quickly. Indeed, if the authentication modes of the user are well informed, the method allows the user to have maximum assurance that at least one authentication mode will be available and will suit him at the time of authentication. The first token used will validate the authentication. Other tokens will be disabled. In practice, the user provides at least one authentication mode that he frequently uses and for which he receives the data easily and quickly. In case of unavailability, he can then resort to one or other of the other modes provided.

Simultaneous sending allows the user to have a choice. The first authentication mode chosen will be accepted, will allow authentication, and other modes, unused, will be disabled immediately. According to another advantageous embodiment, before the validation step of the authentication by the authentication module of the application system, a security module of the central server sends the application system a change of status data. a token. In the latter case, an authentication module of the application system requests back to the security module of the central server the data corresponding to the change of status.

[0024] Advantageously, the security module of the central server sends to the application system the details of the authentication. This approach makes it possible to further secure the process, so that a third party can not intervene before the end of the process.

According to another advantageous embodiment, before the token generation step, a verification module of the available authentication modes of the central server performs a verification of the available authentication modes.

This step optimizes the process by avoiding the use of authentication modes that would not be available at a given time.

The invention also provides a system for authenticating a user of an application system having a plurality of authentication modes by a central server that has data from the users of the application system and data from the user modes. authentication of each of the users, said system consisting of:

a central server, comprising:

an authentication mode selection module, for setting up a plurality of authentication modes for each of the users;

a module for generating tokens, making it possible to generate a time-limited token for each of the authentication modes set up that will actually be used to perform authentication;

a module for substantially simultaneous sending of tokens for at least part of the authentication modes previously put in place, making it possible to send the tokens generated by the token generation module to each of the authentication modes selected;

an authentication module, making it possible to monitor a possible response from a user device, according to one of the authentication modes used and to disable the tokens sent in parallel which are still active;

a plurality of memory modules for storing user data, authentication modes, tokens, and authentication modes;

a plurality of application systems, each of them comprising:

a module for selecting authentication modes, making it possible to set up a plurality of authentication modes for each of the users; an authentication request module, making it possible to request the server central to authenticate a user of the application system:

an authentication module, enabling the application system to validate the authentication of the user;

at least one memory module for storing the authentication mode data of the users of the system and the authenticated user data;

at least two user devices each comprising a module for receiving and sending a token response. Advantageously, the central server further comprises a security module, allowing the application system to communicate with the central server to generate in stages the validation of the authentication of the user at the application system level. This module makes it possible to strengthen the security of the system, for example to prevent a third party from receiving the authentication data.

According to an advantageous embodiment, the central server comprises a verification module of the available authentication modes, making it possible to check the availability of the authentication modes associated with a user before transmitting a token through this method. fashion.

This module makes it possible to send only by the modes available at the time when authentication must be implemented.

DESCRIPTION OF THE FIGURES

All the details of embodiment are given in the description which follows, supplemented by FIGS. 1 and 2, presented solely for purposes of non-limiting examples, and in which:

FIG. 1 presents a functional flowchart presenting the main steps of the method of securing data exchanges in accordance with the invention;

FIG. 2 schematically shows an example of an authentication system according to the invention. DETAILED DESCRIPTION OF THE INVENTION

Authentication system [0033] FIG. 2 is a schematic representation of an exemplary authentication system 1 of a user of an application system 10 via a central server 20.

The system is distributed among the various elements of equipment required to perform its implementation. An example of a distribution is shown in Figure 2 and will be described in the following. Other modes of distribution of the modules are also possible without departing from the scope of the invention.

The system further comprises three main elements, namely a central server 20, dedicated mainly to the implementation of authentication, at least one and preferably a plurality of application systems 10, such as bank servers, purchases or various services, etc., to which a large number of users, associated and therefore known by the application systems, can connect. The system finally comprises a plurality of user devices 30, which the users use to perform various operations using the application systems 10, after an authentication has been operated successfully. Each user device can have a plurality of potential authentication modes that can help to authenticate a user at a time t. As an example here are some authentication modes that can be used simultaneously on several devices:

- Email receiving module that receives tokens in the form of a clickable link.

- SMS receiving module which receives its tokens in the form of a clickable link or simple codes in text format;

an application receiving module dedicated to the central server that makes it possible to simply accept or refuse authentication requests or even to add added value such as biometric verification according to the characteristics of the user device;

receiving modules from popular messaging systems such as social networks. To take an example of an individual with a computer, a smartphone and a connected watch, at a time T and according to the preferences of the application system, he could authenticate with one of the following modes:

- on smartphone: by email, by SMS, by dedicated module with digital verification, by application type "Facebook Messenger";

on computer: by email, by dedicated module without digital verification, by application type "Skype";

on connected watch: by dedicated module.

In the above example, there are thus eight different authentication modes on three different devices.

Each of the application systems 10, in addition to the modules specifically dedicated to the types of operations and functionalities that are specific to each system, comprises a plurality of modules concerning the authentication, as follows.

Each application system 10 has a database 16 of user data, with unique identifiers for each of them. To perform the authentication, a plurality of authentication means must be associated with each of the users. These data are advantageously included in an authentication mode base (28b) provided at the central server. As a variant, a base 15 (in dashed lines) may be provided at the level of the application system. In practice, some application systems may include one base while others do not. The centralized base 28b allows on the one hand to benefit from the authentication data of the users who use several application systems and on the other hand allows the application systems to delegate all or part of their authentication to the central server. This data is obtained once when a user registers or opens an account with an application system. A module 1 1 (in dashed lines) for selecting authentication modes makes it possible to set up these data. As in the case of the base 15, a module 21 for selecting the authentication modes can also be located at the server. Datas corresponding to the preferred modes of authentication of each of the users are advantageously provided in the authentication base. These data are obtained at the time of registration or opening of the account, and may be preferentially updated later.

When an authentication must be started, an authentication request module 12 makes it possible to ask the central server 20 to authenticate a user of the application system concerned by the request. An authentication module 13 allows the application system to validate the authentication of the user.

In the embodiment of FIG. 2, the central server 20 comprises memory modules making it possible to store the data of the users 28a, those concerning the authentication modes 28b of these users, and the token data 28c. which will allow the implementation of the method, as described below.

As previously described, the server also includes a module 21 for selecting authentication modes, to set up a plurality of authentication modes for each of the users. Preferential modes of the user may be indicated. Note that in the architecture proposed in Figure 2, the central server and the application system each comprise a module for selecting the authentication modes. Various configurations are possible, for example by providing a single module at one of two locations. The location of the server makes it possible to centralize the functions and thus confers a simpler implementation.

A module 22 for generating tokens is requested when authentication must be performed: this module then generates a token for each of the authentication modes in place that will actually be used to perform authentication. One of the peculiarities of the system consists in providing a simultaneous or almost simultaneous sending of a plurality of authentication tokens for distinct authentication modes. For this implementation, a module 23 for substantially simultaneous sending of tokens for at least a portion of the authentication modes previously implemented is provided. This module makes it possible to send the tokens generated by the chip generation module 22 to each of the selected authentication modes.

In order to monitor the return of one of the sent tokens, an authentication module 24, to monitor a possible response of a user device, according to one of the authentication modes used. This same module allows to disable the tokens that are not used. Since the chips are of limited duration, this module deactivates the chips once the expected duration has elapsed. This duration is advantageously very short, for security purposes, such as for example a few seconds or minutes. For example, the duration can be between 10s and 30s or between 30s and 90s, or more.

The central server 20 further comprises a security module 26. This module is provided so that the application system 10 can exchange intermediate data with the central server 20 in order to generate in stages validation of the authentication of the user at the level of the application system.

Finally, in the example illustrated, the central server 20 includes a module 25 for checking the available authentication modes, to check the availability of the authentication modes associated with a user before transmitting a token for this mode. .

Each user preferably has at least two user devices 30 each comprising a module 31 for receiving and sending a token response 31. This module is designed to receive the authentication request tokens 31 generated by the central server chips generation module 22, and to return this transformed token to the central server, in confirmation of acceptance of the authentication. The exchanges between the elements of the authentication system are performed in a manner known in itself, for example by wired network or not. Figure 2 illustrates an example where a network 40 such as the Internet or a telephone network is used. Each of the elements of the authentication system has a computing unit such as a microprocessor 14, 27 and 32 with instructions, a working memory and a communication module (not shown) for data exchange. between the modules. According to the intended embodiment, the chips can take various forms and / or formats. In a preferred embodiment, the tokens are random numbers.

The implementation of the various previously described modules of the three components of the authentication system (for example the modules 1 1, 12 and 13 of the application system, the modules 21 to 27 of the central server and the module 31 of the user devices ) is advantageously performed by means of implementation instructions, allowing the modules to perform the operation or operations specifically provided for the module concerned. The instructions may be in the form of one or more software or software modules implemented by one or more microprocessors. The module (s) and / or the software (s) are advantageously provided in a computer program product comprising a recording medium or recording medium that can be used by a computer and comprising a programmed code readable by a computer integrated in said medium or medium, allowing application software execution on a computer or other device comprising a microprocessor such as a computer, a tablet, a smartphone-type phone, or other.

Authentication method

FIG. 1 is a functional flowchart illustrating the main steps of the authentication method. This method makes it possible to authenticate a user of an application system 10 by a central server 20. The first step 50, relates to a user authentication request made by an application system 10 to a central server 20.

In step 51, the central server receives the authentication request from the application system 10. In step 52, the central server 20 takes into account the data required from the application system 10, and the data 28a from the User ID (for which application system does the server have to authenticate and which user is it?). In step 53, the central server takes into account the data of the authentication modes set up for this user. Then, in step 55, the central server generates a time-limited token for each authentication mode.

In step 56, the central server sends substantially simultaneously to a plurality of user devices 10 of the user to authenticate the generated tokens. There is therefore a token for each of the authentication modes used.

At the user device 30, a reception / response module 31 receives the token that is intended for it, in step 57. The user interacts with his device to enter an authentication validation command . Upon receipt of this user command, the receiving / response module 31 having received said token modifies the token and sends it back to the central server (step 58).

In step 59, the central server receives the modified token. The authentication module 24 of the central server 20 validates the authentication and transmits this validation to the application system 10 which sent the request (step 61).

To prevent useless chips from remaining after the use of a first token, step 60 provides that after receiving a token modified by a user device, the authentication module 24 of the central server deactivates the tokens sent in parallel that are still active.

In order to increase the security of the process, before the validation step 61 of the authentication by the authentication module 13 of the application system 10, a security module 26 of the central server 20 sends the application system 10 status change data of a token (step 63). Following this, the authentication module 13 of the application system returns (step 64) to the security module 26 of the central server the data corresponding to the change of status. In response to this request, the security module 26 of the central server sends the application system the details of the authentication (step 65).

Prior to step 55 of token generation, a verification module 25 of the available authentication modes of the central server performs a verification of the authentication modes 28b available. This step 54 is optional.

The figures and their descriptions made above illustrate the invention rather than limiting it. In particular, the invention and its various variants have just been described in connection with a particular example comprising an architecture in which the key elements are provided at the central server.

Nevertheless, it is obvious to one skilled in the art that the invention can be extended to other embodiments in which variants are provided that certain modules are arranged at another location. For example, the module 21 for selecting the authentication modes can be arranged at an application system.

According to another variant, some modules are integrated or joined, although the mode of operation of the method remains similar to that previously described.

Claims

1. A method of authenticating a user of an application system (10) having a plurality of authentication modes by a central server (20) having data of the users (28a) of the application system and data of the user modes authentication of each of the users, including the steps in which:

the application system (10) performs (50) a user authentication request to the central server (20);

the central server (20) receives (51) the authentication request from the application system (10);

the central server (20) takes into account (52) the required data of the application system (10) and the user identifier data (28a);

based on the user identifier data (28a), the central server (20) takes into account (53) the data (15) of the authentication modes set up for this user;

the central server (20) generates (55) a time-limited token for each of the authentication modes identified for that user;

the central server (20) sends (56) within a very short time interval, for each of the authentication modes of the user to authenticate the generated tokens, a token for each of the authentication modes ;

a module (31) for receiving / responding from at least one of the user devices (30) receives (57) the token intended for it;

upon receipt of a user command, the receiving / response module (31) having received said token modifies (58) the token and sends it back to the central server (20);

the central server (20) receives (59) the modified token;

the authentication module (24) of the central server (20) validates (61) the authentication and transmits this validation to the requesting application system (10), which in turn can accept the authentication request and launch the application corresponding;

the authentication module (24) of the central server (20) deactivates (60) the tokens sent in parallel which are still active.

2. A method of authenticating a user of an application system (10) by a central server (20) according to claim 1, wherein before the validation step (61) of the authentication by the module of authentication (13) of the application system (10), a security module (26) of the central server (20) sends (63) to the application system (10) a change of status of a token.

3. A method of authenticating a user of an application system (10) with a central server (20) according to claim 2, wherein an authentication module (13) of the application system (10) requests back ( 64) to the security module (26) of the central server (20) the data corresponding to the change of status.

A method of authenticating a user of an application system (10) with a central server (20) according to claim 3, wherein the security module (26) of the central server (20) sends (65) the application system (10) the details of the authentication.

5. A method of authenticating a user of an application system (10) with a central server (20) according to one of claims 1 to 4, wherein, before the step (55) of generation of token, a check module (25) of the available authentication modes of the central server (20) performs (54) a check of the available authentication modes (28b).

An authentication system (1) of a user of an application system (10) having a plurality of authentication modes by a central server (20) having user data (28a) of the application system and of the authentication modes of each of the users, said system consisting of:

a central server (20), comprising:

a module (21) for selecting authentication modes, for setting up a plurality of authentication modes for each of the users;

a module (22) for generating tokens, making it possible to generate a time-limited token for each of the authentication modes put in place that will actually be used to perform authentication; a module (23) for sending within a very short time interval of tokens for at least part of the authentication modes previously set up, making it possible to send the chips generated by the module (22); ) generating tokens to each of the selected authentication modes;

an authentication module (24), making it possible to monitor a possible response from a user device, according to one of the authentication modes used and to deactivate (60) the sent in-chips that are still active;

a plurality of memory modules (28a, 28b, 28c) for storing user data (28a), authentication modes (28b), tokens (28c);

a plurality of application systems (10), each of them comprising:

a module (1 1) for selecting authentication modes, making it possible to set up a plurality of authentication modes for each of the users; an authentication request module (12), making it possible to request the central server to authenticate a user of the application system:

an authentication module (13), enabling the application system to validate the authentication of the user;

at least one memory module, for storing the authentication user data (15) of the system users and the authenticated user data (16).

at least two user devices (30) each comprising a module for receiving and sending token response (31).

The authentication system (1) of a user of an application system (10) according to claim 6, wherein the central server (20) further comprises a security module (26), allowing the application system ( 10) to dialogue with the central server (20) to generate in stages validation of the authentication of the user at the application system level.

8. Authentication system (1) of a user of an application system (10) according to one of claims 6 or 7, wherein the central server (20) comprises a module (25) for checking modes of application. available to check the availability of authentication modes associated with a user before transmitting a token through this mode.