Brevet FR3090259A1 — publié le 20200619

Description Titre de l'invention : Procédé et système d'authentification d'un terminal client par un serveur cible, par triangulation via un serveur d'authentification. 1. DOMAINE TECHNIQUE 100011 Le domaine de l'invention est celui de la gestion des mots de passe dans le cadre des processus d'authentification. 100021 Plus précisément, l'invention concerne un processus (procédé et système) d'authentification d'un terminal client (aussi appelé « client ») par un serveur cible (aussi appelé « serveur de ressource », « serveur d'applications » ou encore « serveur de service »), afin qu'une connexion sécurisée puisse être établie entre ces deux entités. Ainsi, après qu'il a été authentifié par le serveur cible, le terminal client va pouvoir accéder, via la connexion sécurisée, à une ressource hébergée par le serveur cible. [0003] Par « terminal client », on entend tout type d'équipement (ordinateur, tablette, smartphonc, etc.) pouvant être utilisé par un utilisateur pour accéder à des ressources (sites wcb, contenus, services, fonctionnalités, logiciels, applications, etc.) via une connexion sécurisée (par exemple selon le protocole HTTPS (HyperText Transfer Protocol Secure), le protocole SSL/TLS (Securc Sockcts Layer / Transport Layer Security), etc.). Pour cela, le terminal client exécute par exemple un navigateur Internet ou un logiciel de type « client de téléchargement ». [0004] Par « serveur cible », on entend tout type d'équipement (serveur, ordinateur, objet connecté, etc.) capable d'héberger des ressources et de les fournir à une autre entité (terminal client) après authentification de cette dernière. 2. ARRIÈRE-PLAN TECHNOLOGIQUE [0005] Dans un monde toujours plus connecté, il existe de plus en plus de sites web, de services, de logiciels et d'applications nécessitant chacun une authentification de l'utilisateur (en général par la fourniture d'un couple « identifiant (login) / mot de passe » par l'utilisateur) pour accéder à du contenu ou à des fonctionnalités. Or. le fait de devoir mémoriser des dizaines de couples « identifiant (login) / mot de passe » est devenu une réelle contrainte pour les utilisateurs. [0006] Déjà très complexe tant pour les utilisateurs que pour les concepteurs de serveurs cibles au sens précité (notamment les industriels fournisseurs d'objets connectés et les éditeurs de sites Web), la gestion des mots de passe se complexifie de jour en jour avec l'explosion du nombre d'objets connectés. [0007] Il existe donc un problème pour les utilisateurs, qui ont du mal à gérer de façon 2 sécurisée un grand nombre de mots de passe. [0008] L'authentification unique (ou SSO, pour « Single Sign On ») constitue une solution connue à ce problème. C'est une méthode permettant à un utilisateur d'accéder à plusieurs serveurs cibles (par exemple des serveurs d'applications informatiques ou des sites web sécurisés) en ne procédant qu'à une seule authentification. Toute contrainte d'authentifications à répétition est ainsi éliminée. Quelle que soit la norme utilisée pour l'authentification unique (OpeniD Connect, Facebook Connect, SÀML, Compte Microsoft (anciennement appelé Passport), etc.), l'infrastructure sécurisée fait intervenir, entre le client et le serveur cible, un serveur d'authentification. [0009] Comme détaillé sur la page URL « haps://authacorniblog/what-is-and-how-does-single-sign-on-tvork/ », l'authentification unique (SSO) repose sur une session partagée par plusieurs domaines et des jetons d'authentification signés (souvent sous forme de cookics) qui contiennent les informations nécessaires à la connexion. Plus précisément, l'utilisateur entre son identifiant (login) et son mot de passe afin d'obtenir un jeton qui lui permet d'accéder ensuite à des ressources spécifiques sans réutiliser son nom d'utilisateur et son mot de passe. Une fois que l'utilisateur a obtenu son jeton, celui-ci offre un accès à des ressources spécifiques pour une période de temps précise sur un ou plusieurs sites distants. En d'autres termes, le jeton permet d'ajouter un niveau d'authentification indirect au lieu d'avoir à se connecter avec l'identifiant (login) et le mot de passe pour chaque ressource protégée. De cette façon, l'utilisateur ne s'authentifie qu'une seule fois (dans une session d'une durée limitée) obtient en retour un jeton pour une durée limitée, et utilise ce jeton pour une authentification supplémentaire au cours de sa session. [0010] Malheureusement, les industriels fournisseurs d'objets connectés et les éditeurs de sites Web ne peuvent pas tous se payer le prix d'une affiliation à un système d'authentification unique (SSO). En effet, la signature numérique des jetons d'authentification a un coût non négligeable. [0011] Outre la solution de l'authentification unique (SSO), des solutions matérielles, souvent biométriques, commencent à voir le jour. Mais elles présentent l'inconvénient d'être dépendantes d'un type de terminal, même quand elles sont externes (par exemple via un port USB). 3. RÉSUMÉ [0012] Dans un mode de réalisation particulier de l'invention, il est proposé un procédé d'authentification d'un terminal client par un serveur cible, comprenant les étapes suivantes : [0013] - le terminal client s'authentifie auprès d'un serveur d'authentification ; [0014] - le serveur cible s'authentifie auprès du serveur d'authentification ; 3 [0015] - le serveur d'authentification et le serveur cible partagent un mot de passe pour le terminal client ; [0016] - le serveur d'authentification transmet le mot de passe au terminal client ; [0017] - le terminal client transmet le mot de passe au serveur cible ; et [0018] - le serveur cible détermine s'il y a une correspondance ou non entre le mot de passe partagé avec le serveur d'authentification et le mot de passe transmis par le terminal client, et si ladite correspondance entre mots de passe existe, le terminal client est authentifié par le serveur cible. [0019] Ainsi, la solution proposée propose une approche tout à fait nouvelle et inventive consistant à définir une forme d'authentification par délégation de service, reposant sur l'authentification d'un terminal client auprès d'un serveur cible par triangulation. On considère un triangle dont les sommets C, À et B sont respectivement le terminal client, le serveur cible et un serveur d'authentification. Le principe est le suivant : si les branches A-B et C-B sont des liens sécurisés (HTTPS. SSL, etc.) (c'est-à-dire si A et C se sont chacun authentifiés auprès de B), et si un échange d'informations d'identification uniques garantit à À que C est parfaitement identifié auprès de B (comme A l'est lui-même), alors C est considéré comme authentifié auprès de A (et A peut donc accepter une connexion sécurisée de C) si l'authentification de C est fournie par B. En d'autres termes, A délègue à B son authentification de C. [0020] L'invention a la même finalité qu'un système d'authentification unique (SSO), à savoir permettre à l'utilisateur de ne s'authentifier qu'une seule fois pour se connecter à différents domaines. En effet, dans la solution proposée, pour s'authentifier auprès de plusieurs serveurs cibles, le terminal client s'authentifie une seule fois auprès du serveur d'authentification et chacun des serveurs cibles s'authentifie auprès du serveur d'authentification. Ainsi, chacun des serveurs cibles délègue au serveur d'authentification son authentification du terminal client. [0021] Cependant, la comparaison s'arrête là : l'invention utilise des sessions distinctes (pas de session commune à plusieurs domaines) et il n'y a pas de jeton d'authentification signé. Le mécanisme d'authentification sur chaque domaine (c'est-à-dire auprès de chaque serveur cible) reste standard. Seule la gestion des mots de passe est déléguée au serveur d'authentification. Les mots de passe sont transmis sur des liens sécurisés (cryptés). [0022] Un avantage de la solution proposée est que son coût de mise en oeuvre est moindre car il n'y a pas de coût d'affiliation à un système d'authentification unique (SSO). Elle est donc particulièrement adaptée pour des sites web de faible taille, pour du résidentiel ou encore pour de l'intra-entreprise. [0023] Un autre avantage est que seule la gestion des mots de passe étant déléguée à un serveur d'authentification, ce dernier n'a pas besoin de connaître l'identifiant (login) utilisé par l'utilisateur pour s'identifier auprès du serveur cible. [0024] Encore un autre avantage est que l'architecture de la solution proposée étant simple, elle est adaptée à toute utilisation dans laquelle le serveur d'authentification est embarqué (par exemple, comme détaillé plus bas, sur une passerelle domestique aussi appelée « box Internet »). [0025] Dans une implémentation particulière détaillée plus bas, les informations d'identification uniques échangées entre le terminal client, le serveur cible et le serveur d'authentification peuvent être une combinaison de données d'identification de personne (nom, prénom, adresse mail, téléphone, etc.), d'identification du matériel communicant utilisé pour la connexion (adresse IP, adresse MAC, numéro de série, etc.) et de codes à usage unique (UUID) générés pour la session. Chaque entité (sommet du triangle) met en corrélation les informations transmises par les deux autres entités (autres sommets du triangle) avec lesquelles elle est en relation. [0026] En d'autres termes, la corrélation des données du client auprès du serveur cible et auprès du serveur d'authentification est permise par l'échange de données pérennes le concernant (aussi appelées plus haut « données d'identification de personne ») et son identification est garantie par un échange de données volatiles (aussi appelées plus haut « données d'identification du matériel communicant » et « codes à usage unique ») entre les trois composantes de la triangulation que sont le client, le serveur cible et le serveur d'authentification. [0027] Dans une première implémentation, le procédé comprend en outre les étapes suivantes : [0028] - le serveur cible demande ledit mot de passe au serveur d'authentification (B), pour le terminal client ; et [0029] - le serveur d'authentification génère ledit mot de passe. [0030] Dans cette première implémentation, le serveur cible est d'implémentation plus simple puisqu'il n'a pas à gérer la génération du mot de passe (celle-ci est effectuée par le serveur d'authentification). [0031] Selon une caractéristique particulière de la première implémentation, l'étape dans laquelle le serveur cible demande ledit mot de passe au serveur d'authentification, fait suite à l'étape suivante : le terminal client s'identifie auprès du serveur cible, sans s'authentifier. [0032] Ainsi, la solution est compatible avec un fonctionnement de type client/serveur, dans lequel rien n'est à l'initiative du serveur qui ne fait que répondre à des requêtes du client. En effet, c'est le terminal client qui déclenche les échanges entre le serveur cible et le serveur d'authentification, et ces échanges peuvent donc être automatisés. [0033] Dans une deuxième implémentation, le procédé comprend les étapes suivantes : [0034] - le serveur cible génère ledit mot de passe, pour le terminal client ; et [0035] - le serveur cible transmet ledit mot de passe au serveur d'authentification. [0036] Dans cette deuxième implémentation, le serveur d'authentification est d'implémentation plus simple puisqu'il n'a pas à gérer la génération du mot de passe (celle-ci est effectuée par le serveur cible). [0037] Selon une caractéristique particulière, l'étape dans laquelle le serveur d'authentification transmet le mot de passe au terminal client, fait suite à l'étape suivante : le terminal client demande ledit mot de passe au serveur d'authentification. [0038] Ainsi, la solution est compatible avec un fonctionnement de type client/serveur puisque le serveur d'authentification n'agit que sur demande du terminal client. [0039] Selon une caractéristique particulière, le procédé comprend les étapes suivantes : [0040] - le serveur cible génère un identifiant universel unique pour le terminal client et le transmet au serveur d'authentification; [0041] - le serveur d'authentification transmet ledit identifiant universel unique au terminal client ; [0042] - le terminal client envoie une requête au serveur d'authentification pour obtenir ledit mot de passe, ladite requête contenant ledit identifiant universel unique ; [0043] - le serveur d'authentification vérifie s'il y a une correspondance ou non entre l'identifiant universel unique transmis par le terminal client et l'identifiant universel unique transmis par le serveur cible ; [0044] et l'étape de transmission du mot de passe depuis le serveur d'authentification vers le terminal client n'est pas exécutée si ladite correspondance entre identifiants universels uniques n'existe pas. [0045] De cette façon, on évite une attaque par une quatrième entité non autorisée, autre que le terminal client (C), le serveur cible (A) et le serveur d'authentification (B) (attaque de type «mail in the middle »). [0046] Selon une caractéristique particulière, le procédé comprend les étapes suivantes : [0047] - le serveur d'authentification récupère et enregistre l'adresse IP du terminal client ; [0048] - le serveur cible récupère et enregistre l'adresse IP du terminal client ; [0049] - le serveur cible envoie l'adresse IP du terminal client au serveur d'authentification ; [0050] - le serveur d'authentification compare l'adresse IP du terminal client provenant du serveur cible et l'adresse IP du terminal client préalablement enregistrée, et vérifie s'il y a une correspondance ou non ; [0051] et une étape de transmission du mot de passe depuis le serveur d'authentification vers le serveur cible n'est pas exécutée si ladite correspondance entre adresses IP du terminal client n'existe pas. [0052] De cette façon, le serveur d'authentification garantit au serveur cible que le terminal client qui souhaite s'authentifier auprès de lui est bien enregistré auprès du serveur d'authentification. 6 [0053] Selon une caractéristique particulière, le procédé comprend les étapes suivantes : [0054] - le serveur d'authentification récupère et enregistre au moins une information d'identification du serveur cible ; [0055] - le terminal client récupère et enregistre ladite au moins une information d'identification du serveur cible; [0056] - le terminal client envoie une requête au serveur d'authentification pour obtenir ledit mot de passe, ladite requête contenant ladite au moins une information d'identification du serveur cible ; [0057] - le serveur d'authentification vérifie s'il y a une correspondance ou non entre ladite au moins une information d'identification du serveur cible transmise par le terminal client et ladite au moins une information d'identification du serveur cible préalablement enregistrée ; [0058] et l'étape de transmission du mot de passe depuis le serveur d'authentification vers le terminal client n'est pas exécutée si ladite correspondance entre informations d'identification du serveur cible n'existe pas. [0059] De cette façon, le serveur d'authentification garantit au terminal client que serveur cible auprès de qui il souhaite s'authentifier est bien enregistré auprès du serveur d'authentification. [0060] Selon une caractéristique particulière, ladite au moins une information d'identification du serveur cible appartient au groupe comprenant une adresse IF du serveur cible et une adresse URL du serveur cible. [0061] Selon une caractéristique particulière, le procédé comprend les étapes suivantes : [0062] - le serveur cible obtient au moins une information d'identification d'au moins un utilisateur dudit terminal client ; [0063] - le serveur cible envoie une requête au serveur d'authentification pour obtenir ledit mot de passe, ladite requête contenant ladite au moins une information d'identification ; [0064] - le serveur d'authentification vérifie, en fonction de ladite au moins une information d'identification transmise par le serveur cible, si le terminal client est enregistré ou non auprès du serveur d'authentification ; [0065] et une étape de transmission du mot de passe depuis le serveur d'authentification vers le serveur cible n'est pas exécutée si le terminal client n'est pas enregistré auprès du serveur d'authentification. [0066] De cette façon, le serveur d'authentification garantit au serveur cible que l'utilisateur du terminal client qui souhaite s'authentifier auprès de lui est bien enregistré auprès du serveur d'authentification. [0067] Selon une caractéristique particulière, ledit mot de passe est un mot de passe à usage unique et à durée de validité prédéterminée. 7 100681 L'utilisation d'un mot de passe à usage unique et à durée de validité prédéterminée (OTP, pour « One-Time Password ») permet (l'éviter qu'une entité non autorisée réutilise ultérieurement le mot de passe pour s'authentifier auprès du même serveur cible. [0069] Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. [0070] Dans un autre mode de réalisation de l'invention, il est proposé un médium de stockage lisible par ordinateur et non transitoire, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). [0071] Dans un autre mode de réalisation de l'invention, il est proposé un système d'authentification d'un terminal client par un serveur cible, caractérisé en ce que : [0072] - le terminal client comprend des moyens pour s'authentifier auprès d'un serveur d'authentification ; [0073] - le serveur cible comprend des moyens pour s'authentifier auprès du serveur d'authentification ; [0074] - le serveur d'authentification et le serveur cible comprennent des moyens pour partager un mot de passe pour le terminal client ; [0075] - le serveur (l'authentification comprend des moyens pour transmettre le mot de passe au terminal client ; [0076] - le terminal client comprend des moyens pour transmettre le mot de passe au serveur cible ; et [0077] - le serveur cible comprend des moyens pour déterminer s'il y a une correspondance ou non entre le mot de passe partagé avec le serveur d'authentification et le mot de passe transmis par le terminal client, le terminal client étant authentifié par le serveur cible si ladite correspondance entre mots de passe existe. [0078] Avantageusement, les trois entités principales du système d'authentification (terminal client, serveur cible et serveur d'authentification) comprennent des moyens de mise en oeuvre des étapes du procédé d'authentification tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 4. LISTE DES FIGURES [0079] D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : [0080] [fig.1] illustre une première étape d'un procédé d'authentification selon un mode de réa- 8 lisation de l'invention ; [0081] [fig.2] illustre une deuxième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0082] [fig.3] illustre une troisième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0083] [fig.4] illustre une quatrième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0084] [fig.5] illustre une cinquième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0085] [fig.6] illustre une sixième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0086] [fig.7] illustre une septième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0087] [fig.8] illustre une huitième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0088] [fig.9] illustre une neuvième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0089] [fig.10] illustre une dixième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0090] [fig.11] illustre une onzième étape d'un procédé d'authentification selon un mode de réa- lisation de l'invention ; [0091] [fig.12] illustre des douzième, treizième, quatorzième et quinzième étapes d'un procédé d'authentification selon un mode de réalisation de l'invention ; et [0092] [fig.13] présente un exemple de structure pour implémenter chacune des trois entités (terminal client, serveur cible et serveur cl' authentification) impliquées dans le procédé d'authentification des figures 1 à 12. 9 5. DESCRIPTION DÉTAILLÉE 100931 Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 100941 On présente maintenant, en relation avec les figures 1 à 12 les différentes étapes d'un procédé d'authentification selon un mode de réalisation de l'invention. [0095] Comme déjà mentionné plus haut, il s'agit d'un procédé d'authentification d'un terminal client (référencé C) par un serveur cible (référencé A), par triangulation via un serveur d'authentification (référencé B). Ces différentes entités ont déjà été définies plus haut. [0096] Sur chacune des figures 1 à 12, chacune des trois entités impliquées (terminal client C. serveur cible A et serveur d'authentification B) est associée à un logo de base de données dans lequel sont indiquées les diverses informations enregistrées par cette entité, au fur et à mesure de l'avancement du procédé. Dans la suite de la description, les informations suivantes sont détaillées : « Client IP », « Partner URL », « Partner IP », « Client UUID » et « OTP », [0097] Dans une première étape (symbolisée par la flèche référencée 1 sur la figure 1). le terminal client C s'authentifie auprès du serveur d'authentification B en vue de l'établissement entre eux d'une connexion sécurisée (lien sécurisé HTTPS, SSL, etc.). Plus précisément, un utilisateur du terminal client C fournit un identifiant (noté « login 1 ») et un mot de passe afin d'accéder à un service d'authentification fourni par le serveur d'authentification B. Si nécessaire, afin d'augmenter le niveau de cette authentification, le terminal client C peut fournir un ou plusieurs éléments d'authentification complémentaires, comme par exemple une clé RSA. Avec la solution proposée, cette authentification du terminal client C auprès du serveur d'authentification B est la seule fois où l'utilisateur a besoin de s'authentifier. [0098] Dans une deuxième étape (symbolisée par la flèche référencée 2 sur la fiOEure 2) le serveur d'authentification B vérifie si l'utilisateur est enregistré ou non pour le service d'authentification, c'est-à-dire si le couple login/mot de passe fourni correspond ou non à un couple identique préalablement enregistré (par exemple lors d'une phase d'inscription de l'utilisateur à ce service d'authentification). En cas de vérification positive, le serveur d'authentification B renvoie un statut de connexion au terminal client C et enregistre l'adresse IP du terminal client C (notée « Client IP ») (donnée par le protocole IP dans le cadre de la connexion entre le serveur d'authentification B et le terminal client C). En cas de vérification négative, le présent procédé d'authentification par triangulation s'arrête. [0099] Dans une troisième étape (symbolisée par la flèche référencée 3 sur la1._gfi -e 3 ), le terminal client C se connecte au serveur cible A, avec un identifiant (noté « login 2 », différent de l'identifiant « login 1 » utilisé pour s'authentifier auprès du serveur d'authentification B), mais sans mot de passe (c'est-à-dire sans élément d'authentification). Pour cela, le terminal client C connaît et utilise l'adresse URL (notée « Partncr URL ») de la page de connexion dédiée du serveur cible A. Le terminal client C enregistre l'adresse IP du serveur cible A (notée « Partner IP »), donnée par le protocole IP dans le cadre de la connexion entre le terminal client C et le serveur cible A. [0100] Dans une quatrième étape (symbolisée par la flèche référencée 4 sur la finure 4). le serveur cible A vérifie si le terminal client C est enregistré ou non dans sa base de données clients. En cas de vérification positive (c'est-à-dire si le terminal client est bien enregistré), le serveur cible A effectue les étapes suivantes (avant le passage à la cinquième étape du procédé) : il enregistre l'adresse IP du terminal client C (« Client IP »), donnée par le protocole IP dans le cadre de la connexion entre le terminal client C et le serveur cible A ; il génère et enregistre un identifiant universel unique pour le terminal client C (noté « Client UUID ») ; et il s'authentifie auprès du serveur d'authentification B en vue de l'établissement entre eux d'une connexion sécurisée (lien sécurisé HTTPS, SSL, etc.). Pour cela, le serveur cible A peut fournir tout type d'élément d'authentification entre machines, comme par exemple une clé RSA. [0101] En cas de vérification négative, le présent procédé d'authentification par trian- gulation s'arrête. Le serveur cible A renvoie au terminal client C soit une page d'invitation à créer un compte (en vue de passer à un procédé d'authentification classique avec saisie (l'un login et d'un mot de passe), soit une page d'erreur, en fonction de l'implémentation choisie par l'éditeur du serveur cible A. [0102] Dans une cinquième étape (symbolisée par la flèche référencée 5 sur la fi2ure 5 ). le serveur d'authentification B vérifie que le serveur cible A est enregistré pour le service d'authentification. Le serveur d'authentification B renvoie un statut de connexion au serveur cible A. Si l'authentification et la connexion sont réussies, le serveur d'authentification B ern-egistre l'adresse IP du serveur cible A k Partner IP »), donnée par le protocole IP dans le cadre de la connexion entre le serveur cible A et le serveur d'authentification B. Sinon, le présent procédé d'authentification par triangulation s'arrête. [0103] Dans une sixième étape (symbolisée par la flèche référencée 6 sur lata6fi ). le serveur cible A transmet au serveur d'authentification B l'identifiant universel unique pour le terminal client C (« Client UUID »), ainsi que des informations d'identification de l'utilisateur du terminal client C (par exemple, nom, prénom, adresse email, adresse IP (« Client IP »), etc.). Cette transmission est comprise par le serveur 11 d'authentification B comme une demande de mot de passe pour le terminal client C. [0104] Dans une septième étape (symbolisée par la flèche référencée 7 sur la fitTure 7). le serveur d'authentification B effectue plusieurs vérifications : - il vérifie si le serveur cible A est enregistré ou non pour le service d'authentification ; il vérifie si le terminal client C est enregistré ou non pour le service d'authentification (il utilise pour cela les informations d'identification de l'utilisateur du terminal client C, fournies le serveur cible A, et les compare aux informations d'identification dont il dispose pour les utilisateurs enregistrés pour le service d'authentification) ; il vérifie si le terminal client C est connecté ou non au service d'authentification (il utilise pour cela l'adresse IP du terminal client C fournie par le serveur cible A, et la compare aux adresses IP des terminaux clients connectés au service d'authentification). [0105] Si ces vérifications sont positives, le serveur d'authentification B effectue les étapes suivantes (avant le passage à la huitième étape du procédé) : génère un mot de passe OTP (mot de passe à usage unique, ayant une durée de validité prédéterminée courte) ; envoie au serveur cible A un statut de vérification ainsi que le mot de passe OTP généré ; et enregistre l'identifiant universel unique du terminal client C (« Client UUID »). [0106] Si au moins une de ces vérifications est négative, le présent procédé d'authentification par triangulation s'arrête. Le serveur d'authentification B envoie au serveur cible A soit un message invitant le serveur cible A à proposer au terminal client C de passer à un procédé d'authentification classique du terminal client C (avec saisie d'un login et d'un mot de passe), soit une page d'erreur, en fonction de l'implémentation choisie par l'éditeur du serveur d'authentification B. [0107] Dans une huitième étape (symbolisée par la flèche référencée 8 sur la fiai!' ). le serveur cible A enregistre le mot de passe OTP pour une durée limitée et retransmet au terminal client C l'identifiant universel unique de celui-ci (« Client UUID »). Puis on passe à la neuvième étape du procédé. [0108] En cas d'au moins une vérification négative à la septième étape, la huitième étape est remplacée par une étape dans laquelle le serveur cible A renvoie au terminal client C soit une page d'invitation à créer un compte (en vue de passer à un procédé d'authentification classique avec saisie d'un login et d'un mot de passe), soit une page d'erreur, en fonction de l'implémentation choisie par l'éditeur du serveur cible A. [0109] Dans une neuvième étape (symbolisée par la flèche référencée 9 sur la fivure 9) le 12 terminal client C enregistre l'identifiant universel (« Client UUTD ») transmis par le serveur cible A et transmet au serveur d'authentification B une requête pour obtenir un mot de passe. La requête contient les informations « Partner URL », « Partner IF» et « Client UUTD » définies plus haut. [0110] Dans une dixième étape (symbolisée par la flèche référencée 10 sur la fitture 1 O) le serveur d'authentification B effectue plusieurs vérifications : il vérifie si le terminal client C a envoyé ou non une requête en vue d'obtenir un mot de passe, pendant un laps de temps spécifié au cours de la même session HTTPS ; il vérifie si l'identifiant universel unique (« Client UUTD ») fourni par le terminal client C correspond à celui fourni par le serveur cible A ; et il vérifie si le domaine du serveur cible À correspond au domaine contenu dans la requête transmise par le terminal client C (grâce à « Partner URL » et « Partner IP »). [0111] Si ces vérifications sont positives, le serveur d'authentification B transmet le mot de passe OTP au terminal client C. Puis on passe à la onzième étape du procédé. [0112] Si au moins une de ces vérifications est négative, le présent procédé d'authentification par triangulation s'arrête. Le serveur d'authentification B envoie au terminal client C soit un message l'invitant à passer à un procédé d'authentification classique auprès du serveur cible A (avec saisie d'un login et d'un mot de passe), soit une page d'erreur, en fonction de l'implémentation choisie par l'éditeur du serveur d'authentification B. [0113] Dans une onzième étape (symbolisée par la flèche référencée 11 sur la fiOEure 1 1 ) le terminal client C se connecte au serveur cible A avec son identifiant (« login 2 ») et le mot de passe OTP fourni par le serveur d'authentification B. en vue de l'établissement entre eux d'une connexion sécurisée (lien sécurisé HTTPS, SSL, etc.). [0114] Dans une douzième étape (symbolisée par la flèche référencée 12 sur laui_g 2fi ) le serveur cible A effectue plusieurs vérifications : il vérifie si le terminal client C s'est connecté ou non pendant ledit laps de temps spécifié au cours de la même session HTTPS ; il vérifie si le mot de passe OTP fourni par le terminal client C correspond ou non à celui fourni parie serveur d'authentification B à l'étape de la figure 7 et stocké à l'étape de la figure 8. [0115] Si ces vérifications sont positives, le serveur cible A envoie un statut de connexion au terminal client C. Le terminal client C est considéré comme authentifié auprès du serveur cible A (et le serveur cible A peut donc accepter une connexion sécurisée du terminal client C). Le serveur cible A a délégué au serveur d'authentification B son authentification du terminal client C. 13 [0116] Si au moins une de ces vérifications est négative, le présent procédé d'authentification par triangulation s'arrête. Le serveur cible A envoie au terminal client C soit un message l'invitant à passer à un procédé d'authentification classique (avec saisie d'un login et d'un mot de passe), soit une page d'erreur, en fonction de l'implémentation choisie par l'éditeur du serveur cible A. [0117] Dans une treizième étape (symbolisée par la flèche référencée 13 sur la figure 1 2) le terminal client C demande au serveur cible A un contenu (ressource) protégé. [0118] Dans une quatorzième étape (symbolisée par la flèche référencée 14 sur la figure 1 2 ), le serveur cible A transmet le contenu protégé au terminal client C. [0119] Dans une quinzième étape (symbolisée par la flèche référencée 15 sur la figure 1 2) le terminal client C se déconnecte (log out) du serveur cible A. Si le terminal client C ne transmet pas d'autre demande de contenu au serveur cible A, ou bien si ledit laps de temps spécifié (au cours de la même session HTTPS) est écoulé, la connexion au serveur d'authentification B est perdue. [0120] La solution proposée, notamment dans l'exemple décrit ci-dessus, permet en par- ticulier d'appliquer le principe d'une authentification unique, par exemple à partir d'un ordinateur, d'une tablette ou d'un smartphone, à des serveurs cibles inadaptés aux systèmes connus de type SSO (nécessitant une affiliation et l'utilisation de jetons d'authentification signés). [0121] Exemples d'application avec des serveurs cibles inadaptées aux systèmes connus de type SSO : la récupération de données protégées sur des serveurs cibles distincts, comme par exemple des relevés de compte répartis sur les serveurs de différentes banques. avec un serveur d'authentification embarqué sur une passerelle (box), l'accès à un ensemble de capteurs connectés (intégrant chacun un serveur cible) d'un site (résidentiel ou professionnel, voire industriel) si la passerelle est de type serveur ; à l'intérieur d'un espace résidentiel ou d'une entreprise, l'accès par un utilisateur à tous les serveurs cibles internes. [0122] Lau_g présente un exemple de structure 130 pour implémenter chacune des trois entités (terminal client C, serveur cible A et serveur (l'authentification B) impliquées dans le procédé d'authentification des figures 1 à 12. [0123] Cette structure comprend une mémoire vive 132 (par exemple une mémoire RAM), une mémoire morte 133 (par exemple une mémoire ROM ou un disque dur) et une unité de traitement 131 (équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur 1330 stocké dans la mémoire morte 133). A l'initialisation, les instructions de code du programme d'ordinateur 1330 sont par exemple chargées dans 14 la mémoire vive 132 avant d'être exécutées par le processeur de l'unité de traitement 131. [0124] Cette figure 13 illustre seulement une manière particulière, parmi plusieurs possibles, d'implémenter le terminal client C, le serveur cible A et le serveur d'authentification B. En effet, chacune de ces trois entités s'implémente indifféremment sur une machine de calcul reprogrammablc (un ordinateur PC, un processeur DSP ou un micro-contrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). [0125] Dans le cas d'une implémentation sur une machine de calcul reprogrammablc, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. [0126] Plusieurs variantes de l'exemple décrit ci-dessus en relation avec les figures 1 à 12 peuvent être envisagés. On peut notamment prévoir des chronologies différentes pour les étapes. [0127] Par exemple, dans une variante, c'est le serveur cible A qui génère le mot de passe (pour le terminal client C) et le transmet au serveur d'authentification B (qui lui-même le transmet au terminal client C). [0128] Plus précisément, dans cette variante, les quatrième, sixième et septième étapes présentées plus haut (symbolisées par les flèches référencées 4, 6 et 7 sur les figures 4, 6 et 7), sont remplacées par des quatrième, sixième et septième étapes modifiées (symbolisées par les flèches référencées 4', 6' et 7' sur les figures 4, 6 et 7). [0129] La quatrième étape modifiée (4') se distingue de la quatrième étape présentée plus haut (4) en ce que, en cas de vérification positive (c'est-à-dire si le terminal client est bien enregistré), le serveur cible A effectue en outre l'étape suivante (avant le passage à la cinquième étape du procédé) : il génère un mot de passe OTP. [0130] La sixième étape modifiée (6') se distingue de la sixième étape présentée plus haut (6) en ce que le serveur cible A effectue en outre l'étape suivante : il transmet le mot de passe OTP au serveur d'authentification B. [0131] La septième étape modifiée (7') se distingue de la septième étape présentée plus haut (7) en ce que, si les vérifications sont positives, le serveur d'authentification B n'effectue pas l'étape de génération d'un mot de passe OTP. [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]