Brevet FR3055053A1 — publié le 20180216

SYSTEME ET PROCEDE D'AUTHENTIFICATION SANS MOT DE PASSE D'UN UTILISATEUR D'UN SYSTEME APPLICATIF PAR UN SERVEUR CENTRAL DOMAINE TECHNIQUE DE L'INVENTION [0001]La présente invention concerne un système d'authentification sans mot de passe d'un utilisateur d'un système applicatif par un serveur central. Elle concerne également un procédé d'authentification sans mot de passe d'un utilisateur d'un système applicatif par un serveur central. ETAT DE LA TECHNIQUE ANTERIEURE [0002] De façon classique, lorsqu'un utilisateur souhaite se connecter à un système applicatif, il doit avant tout procéder à une phase d'authentification. Cette phase permet de s'assurer que l'utilisateur qui demande l'identification est bien le véritable utilisateur. Cet aspect est d'autant plus important si le système applicatif comporte des données personnelles et/ou confidentielles concernant cet utilisateur. Très souvent, le processus d'authentification consiste à entrer des données d'identifiant unique et de mot de passe. Ce mode d'authentification est très largement répandu, pour des milliers de systèmes applicatifs de toutes sortes. De nombreux utilisateurs disposent de comptent ou d'accès à un grand nombre de systèmes applicatifs. La gestion des données d'identifiants et de mot de passe multiples est un problème récurent, qui n'a à ce jour pas trouvé de solution véritablement satisfaisante. [0003] On observe également qu'une grande proportion de ces systèmes applicatifs prévoient des outils simples pour permettre aux utilisateurs ayant oublié des données de mot de passe et/ou d'identifiant unique de récupérer ces données par simple envoi d'un courriel par le système applicatif. Par exemple, si un utilisateur oublie son mot de passe, il fournit les données de son adresse courriel, ou numéro de téléphone, ou autre. Le système applicatif envoie ensuite à l'utilisateur un courriel, sms, ou autre type de message, comportant les données demandées, comme par exemple le mot de passe. D'autres systèmes applicatifs envoient un courriel proposant un lien qui permet à son tour de créer un nouveau mot de passe. Dans tous ces cas, on part du principe que l'envoi des données permettant une Auverc-log-fr 3055053 2 authentification en utilisant une adresse préalablement connue de courriel, numéro de téléphone, adresse postale, adresse IP, ou autre, comporte un niveau de sécurisation satisfaisant pour l'utilisateur en regard du système applicatif concerné. 5 [0004]Certains systèmes prévoient l'utilisation de hardware, tel qu'une carte à puce, pour permettre une authentification à sécurisation renforcée. Ces systèmes ajoutent des niveaux de complexité qui ont pour effet de décourager certains utilisateurs. [0005]L'utilisation d'un mode d'authentification unique pour un utilisateur donné 10 peut susciter certains inconvénients pratiques. En outre, le mode de transmission concerné (courriel, sms, etc) peut être temporairement hors service ou inaccessible pour l'utilisateur, rendant l'authentification impossible. [0006] Il persiste donc un besoin de longue date permettant de simplifier, fiabiliser, 15 et pérenniser les outils d'authentification. [0007]On connaît par ailleurs certains outils conçus dans le but de tenter de répondre à cette problématique. 20 [0008]Par exemple, le document FR3015824 décrit un procédé de gestion de données de connexion à un équipement via un réseau, le procédé comprenant une étape de réception, par un serveur de référencement, en provenance dudit équipement, de données de connexion audit équipement et d'au moins un jeton d'authentification généré à partir d'au moins un identifiant affecté audit équipement 25 et à partir d'au moins une donnée d'authentification d'un utilisateur dudit équipement, une étape de référencement dudit équipement par le serveur de référencement par stockage des données de connexion reçues en association avec au moins d'une clé de référencement comprenant ledit au moins un jeton d'authentification, une étape de réception par le serveur, en provenance d'un 30 terminal, d'au moins une requête d'obtention de données de connexion comprenant une clé de référencement, une étape de transmission audit terminal des données de connexion stockées en association avec la clé de référencement reçue. Ce procédé permet en outre de faciliter la connexion entre deux équipements dont un pour lequel l'adresse IP est variable. Auverc-log-fr 3055053 3 [0009]Le document FR 2940727 décrit un procédé destiné à authentifier un utilisateur du réseau Internet sur une machine offrant un service basé sur le protocole HTTP ou HTTPS, sans contraindre l'utilisateur à se souvenir d'un mot de 5 passe, en vue d'ouvrir une session identifiée de manière unique sur le serveur. Dans un premier temps, lors de sa première demande d'enregistrement, l'utilisateur fournit son adresse de courrier électronique. Il est alors enregistré dans la base de comptes temporaires et reçoit un courriel contenant un lien hypertexte lui permettant de s'enregistrer définitivement dans la base de comptes. Ce courriel 10 contient également un lien permettant à l'utilisateur de se connecter ultérieurement, une fois enregistré. Dans un second temps, l'utilisateur clique sur le lien d'inscription et le serveur exécute alors la requête d'enregistrement définitive. Par la suite, l'utilisateur peut continuer à utiliser le lien de connexion pour se connecter, jusqu'à expiration de la validité de celui-ci ou jusqu'à sa déconnexion volontaire du site 15 internet. Au delà de cette période ou après sa déconnexion, l'utilisateur devra recevoir un nouveau courriel de connexion. Ces courriels constituent des "tickets de connexion" permettant d'envoyer une requête de contrôle de l'appartenance de l'utilisateur à la base de compte. Ce procédé d'authentification est destiné à tous les sites internet possédant une base de comptes utilisateurs. Ce procédé présente 20 cependant peu de souplesse du fait du l'utilisation obligatoire du courriel pour procéder à une connexion. [0010]W02015047555AI décrit un procédé et un système pour authentifier automatiquement un compte d'utilisateur en utilisant plusieurs services. Selon 25 certains modes de réalisation de l'objet divulgué, les méthodes d'authentification d'un utilisateur à l'aide de multiples services sont fournis, les méthodes comprenant: la réception, à partir d'un dispositif client, de premières informations d'identification pour un compte de service cible; authentifier le compte de service cible sur la base des premières informations d'identification; émission d'une requête de redirection 30 qui dirige le dispositif client à au moins un service de répondant, en réponse à l'authentification du compte de service cible; recevoir une réponse de répondant indiquant que le dispositif client a authentifié un compte de service de répondant avec au moins un service de répondant, dans lequel la réponse de répondant comprend un jeton de répondant; et fournir au dispositif client d'accéder au compte Auverc-log-fr 3055053 4 de service cible en réponse à la détermination que le compte de service de répondant est associé au compte de service cible. Ce procédé est complexe à mettre en oeuvre et présente peu de souplesse opérationnelle. 5 [0011] D'autres procédés impliquent l'usage de moyens techniques spécifiques. Par exemple, le document WO 2008/060725 prévoit l'utilisation d'un lecteur biométrique, prévu pour identifier un utilisateur. Ce type de système est peu pratique du fait qu'il requiert un matériel très spécifique, convenablement paramétré. Les systèmes applicatifs existants doivent donc être équipés avant de 10 pouvoir être considérés pour une mise en oeuvre du procédé. [0012]Pour pallier ces différents inconvénients, l'invention prévoit différents moyens techniques. 15 EXPOSE DE L'INVENTION [0013] Tout d'abord, un premier objet de l'invention consiste à prévoir un système 20 et un procédé d'authentification permettant à l'utilisateur de se connecter à un système applicatif sans devoir mémoriser ni même utiliser un mot de passe. [0014]Un autre objet de l'invention consiste à prévoir un système et un procédé d'authentification qui assure une mise en oeuvre rapide et fiable, peu importe le 25 contexte de disponibilité de l'utilisateur et/ou des réseaux de communication utilisés. [0015]Encore un autre objet de l'invention consiste à prévoir un système et un procédé d'authentification faciles et simples à mettre en place et à utiliser, sans 30 devoir installer d'équipement spécifiques chez les utilisateurs. [0016]Encore un autre objet de l'invention consiste à prévoir un système et un procédé d'authentification permettant d'atteindre un niveau de sécurité satisfaisant pour l'utilisateur et le service applicatif. Auverc-log-fr 3055053 5 [0017] Pour ce faire, l'invention prévoit un procédé d'authentification d'un utilisateur d'un système applicatif par un serveur central, comprenant les étapes dans lesquelles : un système applicatif effectue une demande d'authentification d'un utilisateur 5 auprès d'un serveur central ; le serveur central reçoit la demande d'authentification du système applicatif; le serveur central prend en compte les données requises du système applicatif et les données d'identifiant utilisateur ; le serveur central prend en compte les données d'une pluralité de modes 10 d'authentification mis en place pour cet utilisateur ; le serveur central génère un jeton à durée limitée pour chaque mode d'authentification ; le serveur central envoie sensiblement simultanément à une pluralité d'appareils utilisateur de l'utilisateur à authentifier les jetons générés, soit un jeton 15 pour chacun des modes d'authentification ; un module de réception/réponse d'au moins un des appareils utilisateur reçoit le jeton qui lui est destiné ; sur réception d'une commande utilisateur, le module de réception/réponse ayant reçu ledit jeton modifie le jeton et le renvoie au serveur central ; 20 le serveur central reçoit le jeton modifié ; le module d'authentification du serveur central valide l'authentification et transmet cette validation au système applicatif demandeur. [0018]Par « sensiblement simultané », on entend à l'intérieur d'un intervalle de 25 temps très court, comme par exemple inférieur ou égal à quelques dixièmes de secondes entre le premier et le dernier envoi, ou jusqu'à quelques secondes, par exemples 5 ou 10 secondes entre le premier et le dernier envoi. [0019]Le procédé permet à un utilisateur de se connecter à un système applicatif 30 sans la contrainte habituelle de devoir se souvenir d'un mot de passe en vue de fournir ce dernier pour permettre l'authentification. Le procédé permet également d'effectuer l'authentification automatiquement et très rapidement. En effet, si les modes d'authentification de l'utilisateur sont bien renseignés, le procédé permet à l'utilisateur d'avoir un maximum d'assurance qu'au moins un mode d'authentification Auverc-log-fr 3055053 6 sera disponible et saura lui convenir au moment de l'authentification. Le premier jeton utilisé permettra de valider l'authentification. Les autres jetons seront désactivés. En pratique, l'utilisateur renseigne au moins un mode d'authentification qu'il utilise fréquemment et pour lequel il reçoit les données facilement et 5 rapidement. En cas d'indisponibilité, il peut alors recourir à l'un ou l'autre des autres modes prévus. [0020]Selon un mode de réalisation avantageux, après réception d'un jeton modifié par un appareil utilisateur, le module d'authentification serveur central désactive les 10 jetons envoyés en parallèle qui sont encore actifs. [0021]L'envoi simultané permet à l'utilisateur d'avoir un choix. Le premier mode d'authentification qu'il choisi sera accepté, permettra l'authentification, et les autres modes, non utilisés, seront aussitôt désactivés. [0022]Selon un autre mode de réalisation avantageux, avant l'étape de validation de l'authentification par le module d'authentification du système applicatif, un module de sécurisation du serveur central envoie au système applicatif une donnée de changement de statut d'un jeton. [0023]Dans ce dernier cas, un module d'authentification du système applicatif demande en retour au module de sécurisation du serveur central les données correspondant au changement de statut. 25 [0024]De manière avantageuse, le module de sécurisation du serveur central envoie au système applicatif les détails de l'authentification. Cette approche permet de sécuriser d'avantage le procédé, pour éviter qu'un tiers ne puisse intervenir avant la fin du processus. [0025]Selon encore un mode de réalisation avantageux, avant l'étape de 30 génération de jeton, un module de vérification des modes d'authentification disponibles du serveur central effectue une vérification des modes d'authentification disponibles. [0026]Cette étape permet d'optimiser le processus en évitant l'utilisation de modes Auverc-log-fr 15 20 3055053 7 d'authentification qui ne seraient pas disponibles à un instant donné. [0027]L'invention prévoit également un système d'authentification d'un utilisateur d'un système applicatif par un serveur central, ledit système étant constitué par : 5 -un serveur central, comprenant : -un module de sélection de modes d'authentification, pour mettre en place une pluralité de modes d'authentification pour chacun des utilisateurs ; -un module de génération de jetons, permettant de générer un jeton pour chacun des modes d'authentification mis en place qui seront effectivement 10 utilisés pour effectuer une authentification ; -un module d'envoi sensiblement simultané de jetons pour au moins une partie des modes d'authentification préalablement mis en place, permettant d'envoyer les jetons générés par le module de génération de jetons vers chacun des modes d'authentification retenus; 15 -un module d'authentification, permettant de surveiller une réponse éventuelle d'un appareil utilisateur, selon un des modes d'authentification utilisés ; -une pluralité de modules mémoire, pour mémoriser les données des utilisateurs, des modes d'authentification, des jetons, et les modes d'authentification ; 20 -une pluralité de systèmes applicatifs, chacun d'entre eux comprenant : -un module de sélection de modes d'authentification, permettant de mettre en place une pluralité de modes d'authentification pour chacun des utilisateurs ; -un module de demande d'authentification, permettant de demander au serveur central d'authentifier un utilisateur du système applicatif : 25 -un module d'authentification, permettant au système applicatif de valider l'authentification de l'utilisateur ; -au moins un module mémoire pour mémoriser les données de modes d'authentification des utilisateurs du système et des données utilisateur authentifiés ; 30 -au moins deux appareils utilisateurs comportant chacun un module de réception et envoi de réponse jeton. [0028] De manière avantageuse, le serveur central comprend par ailleurs un module de sécurisation, permettant au système applicatif de dialoguer avec le serveur Auverc-log-fr 3055053 8 central afin de générer par étapes la validation de l'authentification de l'utilisateur au niveau du système applicatif. [0029]Ce module permet de renforcer la sécurisation du système, par exemple pour 5 éviter qu'un tiers puisse recevoir les données d'authentification. [0030]Selon un mode de réalisation avantageux, le serveur central comprend un module de vérification des modes d'authentification disponibles, permettant de vérifier la disponibilité des modes d'authentification associés à un utilisateur avant 10 de transmettre un jeton par l'entremise de ce mode. [0031]Ce module permet d'effectuer des envois uniquement par les modes disponibles au moment où une authentification doit être mise en oeuvre. 15 DESCRIPTION DES FIGURES [0032]Tous les détails de réalisation sont donnés dans la description qui suit, complétée par les figures 1 et 2, présentées uniquement à des fins d'exemples non 20 limitatifs, et dans lesquelles: -la figure 1 présente un organigramme fonctionnel présentant les principales étapes du procédé de sécurisation d'échanges de données conforme à l'invention; -la figure 2 montre de façon schématique un exemple de système d'authentification selon l'invention. 25 DESCRIPTION DETAILLEE DE L'INVENTION 30 Système d'authentification [0033]La figure 2 est une représentation schématique d'un exemple de système d'authentification 1 d'un utilisateur d'un système applicatif 10 par l'entremise d'un serveur central 20. Auverc-log-fr 3055053 9 [0034] Le système est réparti entre les différents éléments d'équipement requis pour effectuer sa mise en oeuvre. Une exemple de répartition est présenté à la figure 2 et sera décrit dans ce qui suit. D'autres modes de répartition des modules sont aussi 5 possibles sans sortir du cadre de l'invention. [0035]Le système comprend en outre trois éléments principaux, à savoir un serveur central 20, dédié principalement à la mise en oeuvre des authentifications, au moins un et de préférence une pluralité de systèmes applicatifs 10, tels que des serveurs 10 bancaires, d'achats ou de prestations diverses, etc, auxquels un grand nombres d'utilisateurs, associés et donc connus par les systèmes applicatifs, peuvent se connecter. Le système comprend enfin une pluralité d'appareil utilisateurs 30, que les utilisateurs utilisent pour effectuer diverses opérations à l'aide des systèmes applicatifs 10, après qu'une authentification a été opérée avec succès. 15 [0036]Chacun des systèmes applicatifs 10, en plus des modules spécifiquement dédiés aux types d'opérations et fonctionnalités qui sont spécifiques à chaque système, comprend une pluralité de modules concernant l'authentification, comme suit. 20 [0037]Chaque système applicatif 10 dispose d'une base 16 de données d'utilisateurs, comportant des identifiants uniques pour chacun d'entre eux. Pour procéder à l'authentification, une pluralité de moyens d'authentifications doivent être associés à chacun des utilisateurs. Ces données sont avantageusement comprises 25 dans une base de modes d'authentification (28b) prévue au niveau du serveur central. En variante, une base 15 (en traits pointillés) peut être prévue au niveau du système applicatif. En pratique, certains systèmes applicatifs peuvent comprendre une base 15 tandis que d'autres n'en possèdent pas. La base 28b centralisée permet de bénéficier des données d'authentification des utilisateurs qui utilisent 30 plusieurs systèmes applicatifs. [0038] Ces données sont obtenues une fois lorsqu'un utilisateur s'inscrit ou ouvre un compte auprès d'un système applicatif. Un module 11 (en traits pointillés) de sélection de modes d'authentification permet de mettre en place ces données. Auverc-log-fr 3055053 10 Comme dans le cas de la base 15, un module 21 de sélection des modes d'authentification peut lui aussi se trouver au niveau du serveur. Des données correspondant aux modes préférentiels d'authentification de chacun des utilisateurs sont avantageusement prévues dans la base d'authentification. Ces données sont 5 obtenues au moment de l'inscription ou de l'ouverture du compte, et peuvent préférentiellement être mises à jour par la suite. [0039]Lorsqu'une authentification doit être lancée, un module 12 de demande d'authentification permet de demander au serveur central 20 d'authentifier un 10 utilisateur du système applicatif concerné par la demande. [0040]Un module 13 d'authentification permet au système applicatif de valider l'authentification de l'utilisateur. 15 [0041]Dans l'exemple de réalisation de la figure 2, le serveur central 20 comprend des modules mémoire permettant de mémoriser les données des utilisateurs 28a, celles concernant les modes d'authentification 28b de ces utilisateurs, et les données de jetons 28c, qui permettront la mise en oeuvre du procédé, tel que décrit plus loin. 20 [0042]Comme préalablement décrit, le serveur comprend également un module 21 de sélection de modes d'authentification, pour mettre en place une pluralité de modes d'authentification pour chacun des utilisateurs. Les modes préférentiels de l'utilisateur peuvent être indiqués. A noter que dans l'architecture proposée à la 25 figure 2, le serveur central et le système applicatif comprennent chacun un module de sélection des modes d'authentification. Diverses configurations sont possibles, en prévoyant par exemple un seul module à l'un de deux emplacements. L'emplacement du serveur permet de centraliser les fonctions et confère de ce fait une mise en oeuvre plus simple. 30 [0043]Un module 22 de génération de jetons est sollicité lorsqu'une authentification doit être effectuée : ce module permet alors de générer un jeton pour chacun des modes d'authentification mis en place qui seront effectivement utilisés pour effectuer une authentification. Auverc-log-fr 3055053 11 [0044]Une des particularités du système consiste à prévoir un envoi simultané ou quasi-simultané d'une pluralité de jetons d'authentification pour des modes d'authentification distincts. Pour cette mise en oeuvre, un module 23 d'envoi 5 sensiblement simultané de jetons pour au moins une partie des modes d'authentification préalablement mis en place est prévu. Ce module permet d'envoyer les jetons générés par le module 22 de génération de jetons vers chacun des modes d'authentification retenus. 10 [0045]Afin de surveiller l'arrivée en retour d'un des jetons envoyés, un module 24 d'authentification, permet de surveiller une réponse éventuelle d'un appareil utilisateur, selon un des modes d'authentification utilisés. Ce même module permet de désactiver les jetons qui ne sont pas utilisés. Les jetons étant de durée limitée, ce module désactive les jetons une fois la durée prévue écoulée. Cette durée est 15 avantageusement très courte, à des fins de sécurité, comme par exemple quelques secondes ou minutes. A titre d'exemple, la durée peut se situer entre 10s et 30s ou entre 30s et 90s, ou plus. [0046]Le serveur central 20 comprend par ailleurs un module 26 de sécurisation. 20 Ce module est prévu afin que le système applicatif 10 puisse échanger des données intermédiaires avec le serveur central 20 afin de générer par étapes la validation de l'authentification de l'utilisateur au niveau du système applicatif. [0047]Enfin, dans l'exemple illustré, le serveur central 20 comprend un module 25 25 de vérification des modes d'authentification disponibles, permettant de vérifier la disponibilité des modes d'authentification associés à un utilisateur avant de transmettre un jeton pour ce mode. [0048]Chaque utilisateur dispose de préférence d'au moins deux appareils 30 utilisateurs 30 comportant chacun un module 31 de réception et envoi de réponse jeton 31. Ce module est conçu pour recevoir les jetons 31 de demande d'authentification générés par le module de génération 22 de jetons sur serveur central 20, et pour retourner ce jeton transformé au serveur central, en confirmation d'acceptation de l'authentification. Auverc-log-fr 3055053 12 [0049]Les échanges entre les éléments du système d'authentification sont effectués de façon connue en soit, par exemple par réseau filaire ou non. La figure 2 illustre un exemple où un réseau 40 tel qu'internet ou un réseau téléphonique est 5 utilisé. [0050]Chacun des éléments du système d'authentification dispose d'une unité de calcul tel qu'un microprocesseur 14, 27 et 32 avec des instructions, une mémoire de travail et un module de communication (non montré) permettant les échanges de 10 données entre les modules. [0051]Selon le mode de réalisation prévu, les jetons peuvent prendre diverses formes et/ou formats. Dans un mode de réalisation préférentiel, les jetons sont des nombres aléatoires. 15 [0052]La mise en oeuvre des différents modules préalablement décrits des trois constituants du système d'authentification (par exemple les modules 11, 12 et 13 du système applicatif, les modules 21 à 27 du serveur central et le module 31 des appareils utilisateurs) est avantageusement réalisée au moyen d'instructions de 20 mise en oeuvre, permettant aux modules d'effectuer la ou les opérations spécifiquement prévues pour le module concerné. Les instructions peuvent être sous la forme d'un ou plusieurs logiciels ou modules de logiciels mis en oeuvre par un ou plusieurs microprocesseurs. Le ou les modules et/ou le ou les logiciels sont avantageusement prévus dans un produit programme d'ordinateur comprenant un 25 support d'enregistrement ou medium d'enregistrement utilisable par un ordinateur et comportant un code programmé lisible par un ordinateur intégré dans ledit support ou medium, permettant à un logiciel applicatif son exécution sur un ordinateur ou autre dispositif comportant un microprocesseur tel qu'un ordinateur, une tablette, un téléphone de type « smartphone », ou autre. 30 Procédé d'authentification [0053]La figure 1 est un organigramme fonctionnel illustrant les principales étapes du procédé d'authentification. Ce procédé permet d'effectuer l'authentification d'un Auverc-log-fr 3055053 13 utilisateur d'un système applicatif 10 par un serveur central 20. La première étape 50, concerne une demande d'authentification d'un utilisateur effectuée par un système applicatif 10 auprès d'un serveur central 20. 5 [0054]A l'étape 51, le serveur central reçoit la demande d'authentification du système applicatif 10. A l'étape 52, le serveur central 20 prend en compte les données requises du système applicatif 10, et les données 28a d'identifiant utilisateur (par exemple pour quel système applicatif le serveur doit-il authentifier ? Et de quel utilisateur s'agit-il ?). 10 [0055]A l'étape 53, le serveur central prend en compte les données 15 des modes d'authentification mis en place pour cet utilisateur. Ensuite, à l'étape 55, le serveur central génère un jeton à durée limitée pour chaque mode d'authentification. 15 [0056]A l'étape 56, le serveur central envoie sensiblement simultanément à une pluralité d'appareils utilisateur 10 de l'utilisateur à authentifier les jetons générés. Il y a donc un jeton pour chacun des modes d'authentification utilisés. [0057]Au niveau de l'appareil utilisateur 30, un module 31 de réception/réponse 20 reçoit le jeton qui lui est destiné, à l'étape 57. L'utilisateur interagit avec son appareil pour entrer une commande de validation de l'authentification. Sur réception de cette commande utilisateur, le module 31 de réception/réponse ayant reçu ledit jeton modifie le jeton et le renvoie au serveur central (étape 58). 25 [0058]A l'étape 59, le serveur central reçoit le jeton modifié. Le module d'authentification 24 du serveur central 20 valide l'authentification et transmet cette validation au système applicatif 10 qui a adressé la demande (étape 61). [0059] Pour éviter que des jetons devenus inutiles perdurent après l'utilisation d'un 30 premier jeton, l'étape 60 prévoit qu'après réception d'un jeton modifié par un appareil utilisateur, le module d'authentification 24 du serveur central désactive les jetons envoyés en parallèle qui sont encore actifs. Auverc-log-fr 3055053 14 [0060]Afin d'augmenter la sécurité du processus, avant l'étape de validation 61 de l'authentification par le module d'authentification 13 du système applicatif 10, un module de sécurisation 26 du serveur central 20 envoie au système applicatif 10 une donnée de changement de statut d'un jeton (étape 63). Suite à cela, le module 5 d'authentification 13 du système applicatif demande en retour (étape 64) au module de sécurisation 26 du serveur central les données correspondant au changement de statut. En réponse à cette requête, le module de sécurisation 26 du serveur central envoie au système applicatif les détails de l'authentification (étape 65). 10 [0061]Avant l'étape 55 de génération de jeton, un module de vérification 25 des modes d'authentification disponibles du serveur central effectue une vérification des modes d'authentification 28b disponibles. Cette étape 54 est optionnelle. [0062]Les Figures et leurs descriptions faites ci-dessus illustrent l'invention plutôt 15 qu'elles ne la limitent. En particulier, l'invention et ses différentes variantes viennent d'être décrites en relation avec un exemple particulier comportant une architecture dans laquelle les éléments clés sont prévus au niveau du serveur central. [0063] Néanmoins, il est évident pour un homme du métier que l'invention peut être 20 étendue à d'autres modes de réalisation dans lesquels en variantes, on prévoit que certains modules sont agencés à un autre endroit. Par exemple, le module 21 de sélection des modes d'authentification peut être agencé au niveau d'un système applicatif. 25 [0064]Encore selon une autre variante, certains modules sont intégrés ou joints, bien que le mode de fonctionnement du procédé reste similaire à celui préalablement décrit. Auverc-log-fr REVENDICATIONS1. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20), comprenant les étapes dans lesquelles : un système applicatif (10) effectue (50) une demande d'authentification d'un utilisateur auprès d'un serveur (20) central ; le serveur (20) central reçoit (51) la demande d'authentification du système applicatif (10) ; le serveur central (20) prend en compte (52) les données requises du système applicatif (10) et les données (28a) d'identifiant utilisateur ; le serveur central (20) prend en compte (53) les données (15) des modes d'authentification mis en place pour cet utilisateur ; Le serveur central (20) génère (55) un jeton à durée limitée pour chaque mode d'authentification ; le serveur central (20) envoie (56) sensiblement simultanément à une pluralité d'appareils utilisateur (10) de l'utilisateur à authentifier les jetons générés, soit un jeton pour chacun des modes d'authentification ; un module (31) de réception/réponse d'au moins un des appareils utilisateur (30) reçoit (57) le jeton qui lui est destiné ; sur réception d'une commande utilisateur, le module (31) de réception/réponse ayant reçu ledit jeton modifie (58) le jeton et le renvoie au serveur central (20) ; le serveur central (20) reçoit (59) le jeton modifié ; le module d'authentification (24) du serveur central (20) valide (61) l'authentification et transmet cette validation au système applicatif (10) demandeur. 2. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20) selon la revendication 1, dans lequel, après réception d'un jeton modifié par un appareil utilisateur, le module d'authentification (24) serveur central (20) désactive (60) les jetons envoyés en parallèle qui sont encore actifs. 3. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20) selon l'une des revendications 1 ou 2, dans lequel avant l'étape de validation (61) de l'authentification par le module d'authentification (13) du Auverc-log-fr 3055053 16 système applicatif (10), un module de sécurisation (26) du serveur central (20) envoie (63) au système applicatif (10) une donnée de changement de statut d'un jeton. 5 4. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20) selon la revendication 3, dans lequel un module d'authentification (13) du système applicatif (10) demande en retour (64) au module de sécurisation (26) du serveur central (20) les données correspondant au changement de statut. 10 5. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20) selon la revendication 4, dans lequel le module de sécurisation (26) du serveur central (20) envoie (65) au système applicatif (10) les détails de l'authentification. 15 6. Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20) selon l'une des revendications 1 à 5, dans lequel, avant l'étape (55) de génération de jeton, un module de vérification (25) des modes d'authentification disponibles du serveur central (20) effectue (54) une vérification 20 des modes d'authentification (28b) disponibles. 7. Système d'authentification (1) d'un utilisateur d'un système applicatif (10) par un serveur central (20), ledit système étant constitué par : 25 -un serveur central (20), comprenant : -un module (21) de sélection de modes d'authentification, pour mettre en place une pluralité de modes d'authentification pour chacun des utilisateurs ; -un module (22) de génération de jetons, permettant de générer un jeton pour chacun des modes d'authentification mis en place qui seront effectivement 30 utilisés pour effectuer une authentification ; -un module (23) d'envoi sensiblement simultané de jetons pour au moins une partie des modes d'authentification préalablement mis en place, permettant d'envoyer les jetons générés par le module (22) de génération de jetons vers chacun des modes d'authentification retenus; Auverc-log-fr 3055053 17 -un module (24) d'authentification, permettant de surveiller une réponse éventuelle d'un appareil utilisateur, selon un des modes d'authentification utilisés ; -une pluralité de modules mémoire (28a, 28b, 28c), pour mémoriser les 5 données des utilisateurs (28a), des modes d'authentification (28b), des jetons (28c) ; -une pluralité de systèmes applicatifs (10), chacun d'entre eux comprenant : -un module (11) de sélection de modes d'authentification, permettant de mettre en place une pluralité de modes d'authentification pour chacun des utilisateurs ; 10 -un module (12) de demande d'authentification, permettant de demander au serveur central d'authentifier un utilisateur du système applicatif : -un module (13) d'authentification, permettant au système applicatif de valider l'authentification de l'utilisateur ; -au moins un module mémoire, pour mémoriser les données (15) de modes 15 d'authentification des utilisateurs du système et des données (16) utilisateur authentifiés. -au moins deux appareils utilisateurs (30) comportant chacun un module de réception et envoi de réponse jeton (31). 20 8. Système d'authentification (1) d'un utilisateur d'un système applicatif (10) selon la revendication 7, dans lequel le serveur central (20) comprend par ailleurs un module (26) de sécurisation, permettant au système applicatif (10) de dialoguer avec le serveur central (20) afin de générer par étapes la validation de l'authentification de l'utilisateur au niveau du système applicatif. 25 9. Système d'authentification (1) d'un utilisateur d'un système applicatif (10) selon l'une des revendications 7 ou 8, dans lequel le serveur central (20) comprend un module (25) de vérification des modes d'authentification disponibles, permettant de vérifier la disponibilité des modes d'authentification associés à un utilisateur 30 avant de transmettre une jeton par l'entremise de ce mode. Auverc-log-fr