AUTHENTICATION METHOD AND SYSTEM OF A CUSTOMER DEVICE BY A TARGET SERVER USING TRIANGULATION VIA AN AUTHENTICATION SERVER

Description

1. TECHNICAL FIELD

[0001] The field of the invention is that of password management within the framework of authentication processes.

[0002] More specifically, the invention relates to a process (method and system) for authenticating a client terminal (also called a "client") by a target server (also called a "resource server," "application server," or "service server"), so that a secure connection can be established between these two entities. Thus, after being authenticated by the target server, the client terminal will be able to access, via the secure connection, a resource hosted by the target server.

[0003] The term "client terminal" refers to any type of device (computer, tablet, smartphone, etc.) that a user can use to access resources (websites, content, services, features, software, applications, etc.) via a secure connection (for example, using HTTPS (HyperText Transfer Protocol Secure), SSL / TLS (Secure Sockets Layer / Transport Layer Security), etc.). To do this, the client terminal typically runs a web browser or a download client.

[0004] By "target server" we mean any type of equipment (server, computer, connected object, etc.) capable of hosting resources and providing them to another entity (client terminal) after authentication of the latter. 2. TECHNOLOGICAL BACKGROUND

[0005] In an increasingly connected world, there are more and more websites, services, software, and applications, each requiring user authentication (usually through the provision of a username / password pair) to access content or features. However, having to remember dozens of username / password pairs has become a real burden for users.

[0006] Already very complex for both users and designers of target servers in the aforementioned sense (particularly industrial suppliers of connected objects and website publishers), password management is becoming more complex every day with the explosion in the number of connected objects.

[0007] This presents a problem for users, who struggle to securely manage a large number of passwords.

[0008] Single sign-on (SSO) is a well-known solution to this problem. It's a method that allows a user to access multiple target servers (for example, computer application servers or secure websites) by authenticating only once. This eliminates the need for repeated authentication. Regardless of the standard used for single sign-on (OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc.), the secure infrastructure involves an authentication server between the client and the target server.

[0009] As detailed on the URL page "https: / / auth0.com / blog / what-is-and-how-does-single-sign-on-workSingle sign-on (SSO) relies on a session shared across multiple domains and signed authentication tokens (often in the form of cookies) that contain the information necessary for login. Specifically, the user enters their username and password to obtain a token that allows them to access specific resources without reusing their username and password. Once the user has obtained their token, it grants access to specific resources for a defined period of time across one or more remote sites. In other words, the token adds an indirect layer of authentication instead of requiring users to log in with their username and password for each protected resource.In this way, the user only authenticates once (in a session of limited duration), receives in return a token for a limited time, and uses this token for additional authentication during their session.

[0010] Unfortunately, not all manufacturers of connected devices and website publishers can afford the cost of joining a single sign-on (SSO) system. Indeed, the digital signature of authentication tokens has a significant expense.

[0011] Besides single sign-on (SSO), hardware solutions, often biometric, are beginning to emerge. However, they have the drawback of being dependent on a specific type of terminal, even when external (for example, via a USB port). US patent publication US2018 / 150631A1 discloses a method for authenticating a client terminal using an authentication server to manage its passwords. 3. SUMMARY

[0012] In a particular embodiment of the invention, a method for authenticating a client terminal by a target server is proposed, comprising the following steps: The client terminal authenticates itself with an authentication server; the target server authenticates itself with the authentication server; the authentication server and the target server share a password for the client terminal; the authentication server transmits the password to the client terminal; the client terminal transmits the password to the target server; and the target server determines whether there is a match between the password shared with the authentication server and the password transmitted by the client terminal, and if said password match exists, the client terminal is authenticated by the target server.

[0013] Thus, the proposed solution offers a completely new and inventive approach: defining a form of authentication by service delegation, based on the authentication of a client terminal with a target server through triangulation. Consider a triangle whose vertices C, A, and B are respectively the client terminal, the target server, and an authentication server. The principle is as follows: if branches AB and CB are secure connections (HTTPS, SSL, etc.) (that is, if A and C have each authenticated with B), and if an exchange of unique identifiers guarantees to A that C is fully authenticated with B (just as A is itself), then C is considered authenticated with A (and A can therefore accept a secure connection from C) if the authentication of C is provided by B. In other words, A delegates its authentication of C to B.

[0014] The invention has the same purpose as a single sign-on (SSO) system, namely to allow the user to authenticate only once to connect to different domains. Indeed, in the proposed solution, to authenticate with multiple target servers, the client terminal authenticates once with the authentication server, and each of the target servers authenticates with the authentication server. Thus, each target server delegates its authentication of the client terminal to the authentication server.

[0015] However, the comparison ends there: the invention uses separate sessions (no session common to multiple domains) and there is no signed authentication token. The authentication mechanism on each domain (i.e., with each target server) remains standard. Only password management is delegated to the authentication server. Passwords are transmitted over secure (encrypted) links.

[0016] One advantage of the proposed solution is its lower implementation cost, as there is no cost associated with joining a single sign-on (SSO) system. It is therefore particularly well-suited for small websites, residential use, or internal corporate environments.

[0017] Another advantage is that since only password management is delegated to an authentication server, the latter does not need to know the user ID (login) used to authenticate with the target server.

[0018] Yet another advantage is that the architecture of the proposed solution being simple, it is suitable for any use in which the authentication server is embedded (for example, as detailed below, on a home gateway also called an "Internet box").

[0019] In a specific implementation detailed below, the unique identifiers exchanged between the client terminal, the target server, and the authentication server can be a combination of personal identification data (name, surname, email address, phone number, etc.), identifiers of the communicating hardware used for the connection (IP address, MAC address, serial number, etc.), and one-time-use codes (UUIDs) generated for the session. Each entity (vertex of the triangle) correlates the information transmitted by the two other entities (other vertices of the triangle) with which it is connected.

[0020] In other words, the correlation of the client's data with the target server and with the authentication server is enabled by the exchange of persistent data about him (also referred to above as "personal identification data") and his identification is guaranteed by an exchange of volatile data (also referred to above as "communicating equipment identification data" and "one-time codes") between the three components of the triangulation, which are the client, the target server and the authentication server.

[0021] In an initial implementation, the process also includes the following steps: the target server requests said password from the authentication server (B), for the client terminal; and the authentication server generates said password.

[0022] In this first implementation, the target server is simpler to implement since it does not have to manage password generation (this is done by the authentication server).

[0023] According to a particular feature of the first implementation, the step in which the target server requests said password from the authentication server follows the next step: the client terminal identifies itself to the target server, without authenticating.

[0024] Thus, the solution is compatible with a client / server architecture, in which the server does not initiate any actions but simply responds to client requests. Indeed, it is the client terminal that triggers the exchanges between the target server and the authentication server, and these exchanges can therefore be automated.

[0025] In a second implementation, the process includes the following steps: The target server generates said password for the client terminal; and the target server transmits said password to the authentication server.

[0026] In this second implementation, the authentication server is simpler to implement since it does not have to manage password generation (this is done by the target server).

[0027] According to a particular characteristic, the step in which the authentication server transmits the password to the client terminal follows the next step: the client terminal requests said password from the authentication server.

[0028] Thus, the solution is compatible with a client / server type operation since the authentication server only acts on request from the client terminal.

[0029] Depending on a particular characteristic, the process includes the following steps: The target server generates a unique universal identifier for the client terminal and transmits it to the authentication server; the authentication server transmits said unique universal identifier to the client terminal; the client terminal sends a request to the authentication server to obtain said password, said request containing said unique universal identifier; the authentication server checks whether or not there is a match between the unique universal identifier transmitted by the client terminal and the unique universal identifier transmitted by the target server; and the step of transmitting the password from the authentication server to the client terminal is not executed if said matching between universally unique identifiers does not exist.

[0030] In this way, an attack by a fourth unauthorized entity, other than the client terminal (C), the target server (A) and the authentication server (B) is avoided (a "man in the middle" type attack).

[0031] Depending on a particular characteristic, the process includes the following steps: The authentication server retrieves and records the client terminal's IP address; the target server retrieves and records the client terminal's IP address; the target server sends the client terminal's IP address to the authentication server; the authentication server compares the client terminal's IP address from the target server with the previously recorded client terminal's IP address and checks for a match. and a step of transmitting the password from the authentication server to the target server is not executed if said correspondence between client terminal IP addresses does not exist.

[0032] In this way, the authentication server guarantees to the target server that the client terminal wishing to authenticate with it is indeed registered with the authentication server.

[0033] Depending on a particular characteristic, the process includes the following steps: The authentication server retrieves and stores at least one identifier from the target server; the client terminal retrieves and stores said at least one identifier from the target server; the client terminal sends a request to the authentication server to obtain said password, said request containing said at least one identifier from the target server; the authentication server checks whether or not there is a match between said at least one identifier from the target server transmitted by the client terminal and said at least one identifier from the target server previously stored; and the step of transmitting the password from the authentication server to the client terminal is not executed if said matching of credentials of the target server does not exist.

[0034] In this way, the authentication server guarantees to the client terminal that the target server with which it wishes to authenticate is indeed registered with the authentication server.

[0035] According to a particular characteristic, said at least one identifying information of the target server belongs to the group comprising an IP address of the target server and a URL of the target server.

[0036] Depending on a particular characteristic, the process includes the following steps: the target server obtains at least one identification piece of information from at least one user of said client terminal; the target server sends a request to the authentication server to obtain said password, said request containing said at least one identification piece of information; the authentication server checks, based on said at least one identification piece of information transmitted by the target server, whether the client terminal is registered with the authentication server or not; and a step of transmitting the password from the authentication server to the target server is not executed if the client terminal is not registered with the authentication server.

[0037] In this way, the authentication server guarantees to the target server that the user of the client terminal who wishes to authenticate with it is indeed registered with the authentication server.

[0038] According to a particular characteristic, the said password is a one-time password with a predetermined validity period.

[0039] Using a one-time password with a predetermined validity period (OTP, for "One-Time Password") prevents an unauthorized entity from later reusing the password to authenticate with the same target server.

[0040] In another embodiment of the invention, a computer program product is proposed which includes program code instructions for implementing the aforementioned method (in any of its various embodiments), when said program is executed on a computer.

[0041] In another embodiment of the invention, a computer-readable and non-transient storage medium is proposed, storing a computer program comprising a set of instructions executable by a computer to implement the aforementioned process (in any one of its various embodiments).

[0042] In another embodiment of the invention, a system for authenticating a client terminal by a target server is proposed, characterized in that: The client terminal includes means for authenticating itself to an authentication server; the target server includes means for authenticating itself to the authentication server; the authentication server and the target server include means for sharing a password for the client terminal; the authentication server includes means for transmitting the password to the client terminal; the client terminal includes means for transmitting the password to the target server; and the target server includes means for determining whether or not there is a match between the password shared with the authentication server and the password transmitted by the client terminal, the client terminal being authenticated by the target server if said password match exists.

[0043] Advantageously, the three main entities of the authentication system (client terminal, target server and authentication server) include means for implementing the steps of the authentication process as described above, in any of its various embodiments. 4. LIST OF FIGURES

[0044] Other features and advantages of the invention will become apparent from the following description, given by way of illustrative and non-limiting example, and the accompanying drawings, in which: [ Fig. 1 ] illustrates a first step in an authentication process according to one embodiment of the invention; [ Fig. 2 ] illustrates a second step of an authentication process according to an embodiment of the invention; [ Fig. 3 ]illustrates a third step of an authentication process according to an embodiment of the invention; [ Fig. 4 ] illustrates a fourth step of an authentication process according to an embodiment of the invention; [ Fig. 5 ] illustrates a fifth step of an authentication process according to an embodiment of the invention; [ Fig. 6 ] illustrates a sixth step of an authentication process according to an embodiment of the invention; [ Fig. 7 ] illustrates a seventh step of an authentication process according to an embodiment of the invention; [ Fig. 8 ] illustrates an eighth step of an authentication process according to one embodiment of the invention; [ Fig. 9 ] illustrates a ninth step of an authentication process according to an embodiment of the invention;[ Fig. 10 ] illustrates a tenth step of an authentication process according to an embodiment of the invention; [ Fig. 11 ] illustrates an eleventh step of an authentication process according to one embodiment of the invention; [ Fig. 12 ] illustrates the twelfth, thirteenth, fourteenth, and fifteenth steps of an authentication process according to one embodiment of the invention; and [ Fig. 13 ] presents an example structure for implementing each of the three entities (client terminal, target server, and authentication server) involved in the authentication process. figures 1 to 12 . 5. DETAILED DESCRIPTION

[0045] In all figures in this document, identical elements and steps are designated by the same numerical reference.

[0046] We now present, in relation to the figures 1 to 12 , the different stages of an authentication process according to an embodiment of the invention.

[0047] As mentioned above, this is a process for authenticating a client terminal (referenced C) by a target server (referenced A), through triangulation via an authentication server (referenced B). These different entities have already been defined above.

[0048] On each of the figures 1 to 12 Each of the three entities involved (client terminal C, target server A, and authentication server B) is associated with a database logo that displays the various pieces of information recorded by that entity as the process progresses. The following information is detailed below: "Client IP," "Partner URL," "Partner IP," "Client UUID," and "OTP."

[0049] In a first step (symbolized by the arrow referenced 1 on the figure 1 ), Client terminal C authenticates itself with authentication server B to establish a secure connection (HTTPS, SSL, etc.). Specifically, a user of client terminal C provides a username (referred to as "login 1") and a password to access an authentication service provided by authentication server B. If necessary, to increase the level of authentication, client terminal C can provide one or more additional authentication elements, such as an RSA key. With the proposed solution, this authentication of client terminal C with authentication server B is the only time the user needs to authenticate.

[0050] In a second step (symbolized by the arrow referenced 2 on the figure 2 ), Authentication server B checks whether the user is registered for the authentication service, that is, whether the provided login / password pair matches a previously registered pair (for example, during the user's registration for this authentication service). If the check is successful, authentication server B sends a connection status to client terminal C and records the IP address of client terminal C (denoted as "Client IP") (assigned by the IP protocol during the connection between authentication server B and client terminal C). If the check is unsuccessful, this triangulation authentication process stops.

[0051] In a third step (symbolized by the arrow referenced 3 on the figure 3 )The client terminal C connects to the target server A with a username (denoted "login 2", different from the username "login 1" used to authenticate with the authentication server B), but without a password (i.e., without any authentication element). To do this, the client terminal C knows and uses the URL (denoted "Partner URL") of the dedicated login page of the target server A. The client terminal C records the IP address of the target server A (denoted "Partner IP"), which is provided by the IP protocol as part of the connection between the client terminal C and the target server A.

[0052] In a fourth step (symbolized by the arrow referenced 4 on the figure 4 ) ,Target server A checks whether client terminal C is registered in its customer database. If the check is positive (i.e., if the client terminal is indeed registered), target server A performs the following steps (before proceeding to the fifth step of the process): It records the IP address of client terminal C ("Client IP"), assigned by the IP protocol as part of the connection between client terminal C and target server A; it generates and stores a unique universal identifier for client terminal C (denoted "Client UUID"); and it authenticates itself with the authentication server B to establish a secure connection between them (secure HTTPS, SSL, etc.). For this purpose, target server A can provide any type of machine-to-machine authentication element, such as an RSA key.

[0053] In the event of a negative verification, the current triangulation authentication process stops. The target server A sends to the client terminal C either a page inviting the client to create an account (in order to switch to a classic authentication process with entry of a login and password), or an error page, depending on the implementation chosen by the publisher of the target server A.

[0054] In a fifth step (symbolized by the arrow referenced 5 on the figure 5Authentication server B verifies that target server A is registered for the authentication service. Authentication server B returns a connection status to target server A. If authentication and connection are successful, authentication server B records the IP address of target server A ("Partner IP"), given by the IP protocol as part of the connection between target server A and authentication server B. Otherwise, this triangulation authentication process stops.

[0055] In a sixth step (symbolized by the arrow referenced 6 on the figure 6The target server A transmits to the authentication server B the unique universal identifier for the client terminal C ("Client UUID"), as well as user identification information for the client terminal C (e.g., name, surname, email address, IP address ("Client IP"), etc.). This transmission is interpreted by the authentication server B as a password request for the client terminal C.

[0056] In a seventh step (symbolized by the arrow referenced 7 on the figure 7 ), authentication server B performs several checks: It checks whether the target server A is registered for the authentication service; it checks whether the client terminal C is registered for the authentication service (it uses the user credentials of client terminal C, provided by the target server A, and compares them to the credentials it has for users registered for the authentication service); it checks whether client terminal C is connected to the authentication service (it uses the IP address of client terminal C provided by the target server A, and compares it to the IP addresses of client terminals connected to the authentication service).

[0057] If these checks are successful, authentication server B performs the following steps (before proceeding to the eighth step of the process): generates an OTP password (one-time password, having a short predetermined validity period); sends a verification status to the target server A, along with the generated OTP password; and records the unique universal identifier of the client terminal C ("Client UUID").

[0058] If at least one of these checks is negative, the current triangulation authentication process stops. Authentication server B sends target server A either a message prompting target server A to offer client terminal C the option to proceed to a standard authentication process (with login and password entry), or an error page, depending on the implementation chosen by the vendor of authentication server B.

[0059] In an eighth step (symbolized by the arrow referenced 8 on the figure 8), the target server A stores the OTP password for a limited time and retransmits its unique universal identifier ("Client UUID") to the client terminal C. Then we proceed to the ninth step of the process.

[0060] In the event of at least one negative check in the seventh step, the eighth step is replaced by a step in which the target server A sends to the client terminal C either an invitation page to create an account (in order to proceed to a classic authentication process with entry of a login and password), or an error page, depending on the implementation chosen by the publisher of the target server A.

[0061] In a ninth step (symbolized by the arrow referenced 9 on the figure 9The client terminal C records the universal identifier ("Client UUID") transmitted by the target server A and sends a request to the authentication server B to obtain a password. The request contains the "Partner URL", "Partner IP", and "Client UUID" information defined above.

[0062] In a tenth step (symbolized by the arrow referenced 10 on the Figure 10 ) , Authentication server B performs several checks: It checks whether the client terminal C has sent a request to obtain a password, during a specified period of time during the same HTTPS session; it checks if the universally unique identifier ("Client UUID") provided by the client terminal C matches the one provided by the target server A; and it checks if the domain of the target server A matches the domain contained in the request transmitted by the client terminal C (using "Partner URL" and "Partner IP").

[0063] If these checks are positive, the authentication server B transmits the OTP password to the client terminal C. Then we proceed to the eleventh step of the process.

[0064] If at least one of these checks is negative, the current triangulation authentication process stops. Authentication server B sends the client terminal C either a message prompting it to proceed to a standard authentication process with the target server A (requiring a login and password), or an error page, depending on the implementation chosen by the vendor of authentication server B.

[0065] In an eleventh step (symbolized by the arrow referenced 11 on the figure 11), the client terminal C connects to the target server A with its identifier (“login 2”) and the OTP password provided by the authentication server B, in order to establish a secure connection between them (secure HTTPS link, SSL, etc.).

[0066] In a twelfth step (symbolized by the arrow referenced 12 on the figure 12 ), the target server A performs several checks: It checks whether client terminal C has connected or not during the specified time period during the same HTTPS session; it checks whether the OTP password provided by client terminal C matches the one provided by authentication server B in the step of the figure 7 and stored at the stage of the figure 8 .

[0067] If these checks are successful, target server A sends a connection status to client terminal C. Client terminal C is then considered authenticated with target server A (and target server A can therefore accept a secure connection from client terminal C). Target server A has delegated the authentication of client terminal C to authentication server B.

[0068] If at least one of these checks is negative, the current triangulation authentication process stops. The target server A sends the client terminal C either a message prompting it to proceed to a classic authentication process (with entry of a login and password), or an error page, depending on the implementation chosen by the target server A's vendor.

[0069] In a thirteenth step (symbolized by the arrow referenced 13 on the figure 12 ), the client terminal C requests protected content (resource) from the target server A.

[0070] In a fourteenth step (symbolized by the arrow referenced 14 on the figure 12 ), the target server A transmits the protected content to the client terminal C.

[0071] In a fifteenth step (symbolized by the arrow referenced 15 on the figure 12 ), the client terminal C disconnects (logs out) from the target server A. If the client terminal C does not transmit another content request to the target server A, or if the specified time period (during the same HTTPS session) has elapsed, the connection to the authentication server B is lost.

[0072] The proposed solution, particularly in the example described above, makes it possible to apply the principle of single sign-on, for example from a computer, tablet or smartphone, to target servers unsuitable for known SSO-type systems (requiring affiliation and the use of signed authentication tokens).

[0073] Examples of applications with target servers unsuitable for known SSO-type systems: The retrieval of protected data on separate target servers, such as account statements distributed across the servers of different banks; with an authentication server embedded on a gateway (box), access to a set of connected sensors (each integrating a target server) of a site (residential, professional, or even industrial) if the gateway is of the server type; within a residential or business space, access by a user to all internal target servers.

[0074] There figure 13 presents an example of structure 130 to implement each of the three entities (client terminal C, target server A and authentication server B) involved in the authentication process of figures 1 to 12 .

[0075] This structure comprises a random access memory 132 (for example, RAM), a read-only memory 133 (for example, ROM or a hard drive), and a processing unit 131 (equipped, for example, with a processor and controlled by a computer program 1330 stored in the read-only memory 133). At initialization, the code instructions of the computer program 1330 are, for example, loaded into the random access memory 132 before being executed by the processor of the processing unit 131.

[0076] This figure 13illustrates only one particular way, among several possible ways, of implementing the client terminal C, the target server A and the authentication server B. Indeed, each of these three entities can be implemented interchangeably on a reprogrammable computing machine (a PC, a DSP processor or a microcontroller) running a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).

[0077] In the case of an implementation on a reprogrammable computing machine, the corresponding program (i.e., the sequence of instructions) may be stored in a removable storage medium (such as, for example, a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being readable partially or totally by a computer or a processor.

[0078] Several variations of the example described above in relation to the figures 1 to 12 can be considered. In particular, different timelines for the stages can be planned.

[0079] For example, in one variant, it is the target server A that generates the password (for the client terminal C) and transmits it to the authentication server B (which in turn transmits it to the client terminal C).

[0080] More specifically, in this variant, the fourth, sixth and seventh steps presented above (symbolized by the arrows referenced 4, 6 and 7 on the figures 4 , 6 And 7 ), are replaced by modified fourth, sixth and seventh steps (symbolized by arrows referenced 4', 6' and 7' on the figures 4 , 6 And 7 ).

[0081] The modified fourth step (4') differs from the fourth step presented above (4) in that, in the event of a positive check (i.e. if the client terminal is properly registered), the target server A also performs the following step (before proceeding to the fifth step of the process): it generates an OTP password.

[0082] The modified sixth step (6') differs from the sixth step presented above (6) in that the target server A further performs the following step: it transmits the OTP password to the authentication server B.

[0083] The modified seventh step (7') differs from the seventh step presented above (7) in that, if the checks are positive, the authentication server B does not perform the step of generating an OTP password.

Claims

1. Method of authentication of a client terminal (C) by a target server (A), comprising the following steps: - the client terminal (C) authenticates (1, 2) itself to an authentication server (B); - the target server (A) authenticates (4, 5) itself to the authentication server (B); - the authentication server (B) and the target server (A) share (7) a password for the client terminal (C); - on request by the client terminal (C), the authentication server (B) transmits (10) the shared password to the client terminal (C); - the client terminal (C) transmits (11) the password transmitted by the authentication server to the target server (A); and - on receipt of a password from the client terminal (C), the target server (A) determines whether or not there is a match between the password shared with the authentication server (B) and the password received from the client terminal (C), and if said match between the shared password and the received password exists, the client terminal (C) is authenticated (12) by the target server (A).

2. Method according to Claim 1, further comprising the following steps: - the target server (A) requests (6) said password from the authentication server (B), for the client terminal (C); and - the authentication server (B) generates said password.

3. Method according to Claim 2, wherein the step (6) in which the target server (A) requests said password from the authentication server (B) follows the following step: - the client terminal (C) identifies itself (3) to the target server (A), without authenticating itself.

4. Method according to Claim 1, comprising the following steps: - the target server (A) generates (4') said password, for the client terminal (C); and - the target server (A) transmits (6') said password to the authentication server (B).

5. Method according to any of Claims 1 to 4, comprising the following: - the target server (A) generates (4) a universally unique identifier (Client UUID) for the client terminal (C) and transmits (6) it to the authentication server (B); - the authentication server (B) transmits (8) said universally unique identifier (Client UUID) to the client terminal (C); - the client terminal (C) sends (9) a request to the authentication server (B) to obtain said password, said request containing said universally unique identifier (Client UUID); - the authentication server (B) verifies (10) whether or not there is a match between the universally unique identifier (Client UUID) transmitted by the client terminal (C) and the universally unique identifier (Client UUID) transmitted by the target server (A); and wherein the step (10) of transmitting the password from the authentication server (B) to the client terminal (C) is not executed if said match between universally unique identifiers does not exist.

6. Method according to any of Claims 1 and 5, comprising the following steps: - the authentication server (B) retrieves and records (2) the IP address (Client IP) of the client terminal (C); - the target server (A) retrieves and records (4) the IP address of the client terminal (C); - the target server (A) sends (6) the IP address of the client terminal (C) to the authentication server (B); - the authentication server (B) compares (7) the IP address of the client terminal (C) coming from the target server (A) and the IP address of the client terminal (C) recorded beforehand, and verifies whether or not there is a match; and wherein the step of transmitting the password from the authentication server (B) to the target server (A) is not executed if said match between IP addresses of the client terminal does not exist.

7. Method according to any of Claims 1 and 6, comprising the following steps: - the authentication server (B) retrieves and records at least one piece of identification information of the target server (A); - the client terminal (C) retrieves and records (3) said at least one piece of identification information of the target server (A); - the client terminal (C) sends (9) a request to the authentication server (B) to obtain said password, said request containing said at least one piece of identification information of the target server (A); - the authentication server (B) verifies (10) whether or not there is a match between said at least one piece of identification information of the target server (A) transmitted by the client terminal (C) and said at least one piece of identification information of the target server (A) recorded beforehand; and wherein the step (10) of transmitting the password from the authentication server (B) to the client terminal (C) is not executed if said match between pieces of identification information of the target server (A) does not exist.

8. Method according to Claim 7, wherein said at least one piece of identification information of the target server (A) belongs to the group containing an IP address (Partner IP) of the target server (A) and a URL address (Partner URL) of the target server (A).

9. Method according to any of Claims 1 and 8, comprising the following steps: - the target server (A) obtains at least one piece of identification information of at least one user of said client terminal (C); - the target server (A) sends a request to the authentication server (B) to obtain said password, said request containing said at least one piece of identification information; - the authentication server (B) verifies, depending on said at least one piece of identification information transmitted by the target server (A), whether or not the client terminal (C) has registered with the authentication server (B); and wherein a step (10) of transmitting the password from the authentication server (B) to the target server (A) is not executed if the client terminal (C) has not registered with the authentication server (B).

10. Method according to any of Claims 1 to 9, wherein said password is a one-time password of predetermined length of validity.

11. Computer program product, comprising program code instructions for implementing the method according to at least one of Claims 1 to 10, when said program is executed on a computer.

12. Non-transient and computer-readable storage medium, storing a computer program product according to Claim 11.

13. System for performing authentication of a client terminal (C) by a target server (A), comprising the client terminal (C), the target server (A) and an authentication server (B), wherein: - the client terminal (C) comprises means for authenticating itself to the authentication server (B); - the target server (A) comprises means for authenticating itself to the authentication server (B); - the authentication server (B) and the target server (A) comprise means for sharing a password for the client terminal (C); - the authentication server (B) comprises means for transmitting the shared password to the client terminal (C) on request by the client terminal (C); - the client terminal (C) comprises means for transmitting the password transmitted by the authentication server to the target server (A); and - the target server (A) comprises means for determining, on receipt of a password from the client terminal (C), whether or not there is a match between the password shared with the authentication server (B) and the password received from the client terminal (C), the client terminal (C) being authenticated by the target server (A) if said match between the shared password and the received password exists.