Configuration de l'authentification unique d' OpenID dans l'application personnalisée

Modifier en ligne

Utilisez « OpenID Connect » pour l'authentification unique afin de permettre aux applications de vérifier l'identité de leurs utilisateurs en s'appuyant sur l'authentification effectuée par Verify. Les utilisateurs n'ont pas besoin de créer un compte pour l'application. Les utilisateurs sont redirigés vers Verify pour se connecter. Verify vérifie l'identité des utilisateurs, transmet ces informations via un jeton d'identification et confirme à la partie de confiance que les utilisateurs sont autorisés à accéder à la ressource et à l'utiliser. https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configurationCette application utilise le fournisseur Connect d' OpenID, dont le point de terminaison de découverte est.

Avant de commencer

Remarque : une alternative à cette tâche est disponible à la rubrique « Enregistrement dynamique des clients ».

Vous devez disposer des droits d'administration pour effectuer cette tâche.
Ouvrez au moins deux fenêtres de navigateur pour terminer la configuration. L'un pour la Verify console d'administration et l'autre pour la console d'administration de l'application cible.
- Connectez-vous à la IBM® Verify console d'administration en tant qu'administrateur.
- Connectez-vous à la console d'administration de l'application cible avec votre compte administrateur.
Vous devez configurer les informations de base de l'instance de l'application dans l'onglet « Général ». Voir la section « Configuration des informations de base de l'application ».

A propos de cette tâche

Verify Les modèles d'application prédéfinis ne disposent pas de l'option de connexion « OpenID Connect ». Utilisez le modèle « Application personnalisée » pour configurer une application qui servira de partie de confiance ou d'application cliente pour OpenID, et qui déléguera l'authentification des utilisateurs à Verify.

Configurez Verify le système et la partie dépendante pour qu'ils puissent communiquer entre eux. Pour activer l'authentification unique d' OpenID Connect, vous devez fournir :

Verify avec certaines données provenant de la partie qui s'appuie sur ces informations.
La partie qui se fie à certaines données provenant de Verify.

Vous pouvez configurer IBM Verify Access des applications mobiles en tant que parties connectées à OpenID.

Procédure

Accédez à l'onglet « Connexion ».
Dans la méthode de connexion, sélectionnez « OpenID Connect » ( 1.0 ).

Fournir Verify des informations de base sur la partie qui s'appuie sur le certificat.


Zone	Descriptif
URL de l'application	Il s'agit de l' URL d'initialisation de l'authentification unique utilisée pour se connecter à la partie de confiance OpenID Connect. L'application utilise cette adresse URL pour demander Verify le jeton d'identification contenant les informations de l'utilisateur. Lorsque les utilisateurs accèdent à l'application via cette page URL, ils sont redirigés vers Verify pour s'authentifier. Vous pouvez obtenir ces informations auprès de la partie utilisatrice lorsque vous configurez un fournisseur d'autorisation ou un fournisseur OpenID Connect sur le site ou l'interface utilisateur de la partie utilisatrice.
Types d'octroi	Cela indique le mécanisme que la partie de confiance peut utiliser pour récupérer le jeton d'identification auprès de Verify. Verify prend en charge les types de subventions suivants : Code d'autorisation Remarque : le code d'autorisation est présélectionné comme type d'autorisation par défaut, et l'option PKCE est également sélectionnée par défaut. Implicite Flux de dispositifs Remarque : si vous sélectionnez « Device Flow », vous pouvez également générer un code QR. Autorisation contextuelle Jeton bearer JWT Remarque : si vous sélectionnez « JWT bearer », vous avez la possibilité de configurer `JWKS URI`, `JWT bearer user identification` et `JWT bearer default identity source`. Pour plus d'informations sur l'utilisation du type d'autorisation JWT Bearer, consultez la section Types d'autorisation. Toute combinaison de code d'autorisation, d'octroi implicite, de flux d'appareils et d'octroi ROPC. Vous devez sélectionner au moins un type d'octroi. Si ROPC est le seul type d'octroi sélectionné, la section Stratégies d'accès n'est pas affichée. Consultez la section « Types de subventions » pour obtenir un aperçu comparatif des types de subventions pris en charge et déterminer celui qui convient le mieux à votre demande.
ID de client	Il s'agit de l'identifiant public unique attribué à l 'application cliente, qui est la partie de confiance « OpenID Connect ». Le serveur d'autorisation utilise ces informations pour identifier la partie utilisatrice et la demande d'autorisation. Ces informations sont générées automatiquement une fois que vous avez enregistré l'application personnalisée « OpenID Connect ». Vous devez fournir ces informations à la partie utilisatrice lorsque vous configurez Verify en tant que fournisseur OpenID Connect dans la console d'administration de l'application. La partie utilisatrice se sert de l'ID client à chaque fois qu'elle demande un jeton d'accès.
Secret Kubernetes	Le fichier YAML secret de Kubernetes est utilisé pour se connecter à Red Hat OpenShift. Vous devez télécharger le fichier YAML secret de Kubernetes pour obtenir les métadonnées.
Client public (pas de secret client)	Indique que le client ne possède pas de secret devant être fourni par l'application. Remarque : une fois cette option sélectionnée, le champ « Client Secret » est masqué et les algorithmes suivants sont supprimés des options d'algorithmes de signature : HS256 HS384 HS512 Générez un secret client uniquement si le type de client est confidentiel. Les clients confidentiels peuvent conserver l'ID et le secret client de manière sécurisée et n'exposent pas leurs données d'identification à des parties non autorisées. L'application client et le serveur d'autorisation seulement doivent connaître le secret client.
Secret client	Ces données sont utilisées avec l'ID client afin d'authentifier la partie utilisatrice et d'échanger un code d'autorisation contre un jeton d'ID : Ces informations sont générées automatiquement une fois que vous avez enregistré l'application personnalisée « OpenID Connect ». Vous devez fournir ces informations à la partie utilisatrice lorsque vous configurez Verify en tant que fournisseur OpenID Connect dans la console d'administration de l'application.
Méthode d'authentification client	Indique la méthode d'authentification pour les noeuds finaux, tels que le noeud final de jeton nécessitant une authentification client. Verify prend en charge les méthodes d'authentification client suivantes : Par défaut Méthode de base pour secret client POST pour secret client Jeton JWT pour secret client Jeton JWT pour clé privée Si vous conservez la valeur par défaut, les méthodes de base et POST pour secret client sont autorisées. Si la partie utilisatrice le permet, utilisez le jeton JWT pour clé privée comme configuration. Pour plus d'informations sur le JWT avec secret client et le JWT avec clé privée, consultez la section Créer un JWT avec secret client et un JWT avec clé privée.
Valider le JTI d'assertion client	Indique si l'élément JTI dans le jeton JWT d'assertion client est validé pour un usage unique. Cette option s'affiche uniquement lorsque vous sélectionnez la méthode d'authentification utilisant un jeton JWT pour secret client ou un jeton JWT pour clé privée.
Clés de vérification de signature autorisées	ID de clé de vérification de signature permettant de vérifier le jeton JWT d'assertion client. Cette option s'affiche uniquement lorsque vous sélectionnez la méthode d'authentification utilisant un jeton JWT pour clé privée.
Exiger une vérification PKCE (Proof Key for Code Exchange)	La méthode PKCE est utilisée pour limiter les attaques visant à intercepter les codes d'autorisation. Elle requiert l'obtention d'un code pour que le flux d'octroi de code d'autorisation puisse continuer. Cette option est disponible uniquement si le flux d'octroi de code d'autorisation est sélectionné.
URI de redirection	Il s'agit de l'adresse de rappel URL; c'est à cette adresse que Verify le serveur envoie sa réponse d'authentification à la partie de confiance. Les utilisateurs sont redirigés vers cette page URL après s'être authentifiés et autorisés par Verify. Vous devez spécifier au moins un URI. Si l'URI de rappel est le domaine de l'application, il peut s'agir du domaine du titulaire. Remarque : le domaine peut comporter un caractère générique. Bien que les caractères génériques ne soient pas pris en charge dans le chemin d'accès URI, le caractère « * » est un caractère valide dans ce chemin et est traité comme une chaîne littérale. Vous pouvez ajouter un maximum de 400 URI. Vous pouvez obtenir ces informations auprès de la partie utilisatrice lorsque vous configurez un fournisseur d'autorisation ou un fournisseur OpenID Connect sur le site ou l'interface utilisateur de la partie utilisatrice.
URI JWKS	URI où la partie utilisatrice publie ses clés publiques au format JWKS (JSON Web Keys). Cet URI est utilisé pour la vérification de la signature JWT. Le système peut rejeter un URI JWKS inaccessible ou qui n'a pas répondu. Le système peut également rejeter l'URL JWKS si la taille JWKS est trop grande. Si la partie utilisatrice ne publie pas d'URI JWKS, une clé publique peut être ajoutée dans le système, sous la forme d'un certificat X509. Voir la section « Gestion des certificats ». Le 'Nom usuel' associé au certificat public correspond à la valeur de l'en-tête d'ID de clé (enfant) de JWT.
Identification utilisateur du jeton bearer JWT Disponible pour le type d'octroi de jeton bearer JWT uniquement.	Cette configuration indique au système la façon dont le sujet de support JWT (enfant) est interprété pour identifier l'utilisateur associé à ce jeton bearer JWT. Le sous-système peut être `User ID`, `Username` ou `External ID`.
Source d'identité par défaut du jeton bearer JWT Disponible pour le type d'octroi de jeton bearer JWT uniquement.	Si le jeton bearer JWT n'indique pas le domaine, il s'agit du domaine de la source d'identité par défaut auquel appartient l'utilisateur identifié par l'enfant. Lorsque l'option `JWT bearer user identification` est définie sur `User ID`, ce paramètre n'est pas applicable.

Si vous éditez une application existante, vous pouvez utiliser les options de secret client suivantes :

Sélectionnez pour afficher le secret du client.
Sélectionnez pour masquer le secret du client.
Cliquez sur pour copier l'identifiant client ou la clé secrète dans le presse-papiers.
Cliquez ici pour afficher les secrets client mis à jour.
- Sélectionnez un ou plusieurs secrets client renouvelés dans la liste, puis cliquez sur « Supprimer » pour les supprimer.
Sélectionnez pour générer un nouveau secret client. Utilisez cette option si vous pensez que le secret client est compromis. Si vous régénérez le secret client, vous devez le mettre à jour dans tous les clients OAuth de l'application.
- Cochez la case « Conserver le secret actuel » pour ajouter le secret client actuel à la liste des secrets clients renouvelés.
- Si la case « Conserver le secret actuel » est cochée, sélectionnez la description du secret client et la date d'expiration (selon l'heure locale du navigateur). Si aucune durée d'expiration n'est sélectionnée, la durée de vie du secret renouvelé du locataire définie dans les paramètres de l'application s'appliquera.
- Les secrets client renouvelés sont hachés et ne peuvent plus être récupérés en clair, mais ils restent utilisables jusqu'à la date d'expiration choisie.
- Une fois la confirmation effectuée, le secret client est immédiatement renouvelé. Le nouveau secret client s'affiche à l'écran.

Configurez l'expiration du jeton d'accès et du jeton d'actualisation afin de limiter la durée pendant laquelle l'accès est autorisé en cas de vol de ces jetons.

Le jeton d'accès est utilisé pour autoriser l'accès à la ressource protégée. Après son expiration, l'autorisation est révoquée.

Tableau 1. Paramètres des jetons
Zone	Descriptif
Expiration du jeton d'accès (secs)	Définit la durée en secondes au bout de laquelle le jeton d'accès expire. Définissez l'expiration d'un jeton d'accès pour limiter la durée pendant laquelle un agresseur informatique peut accéder à la ressource s'il a volé le jeton lorsque l'application client est comprise. Seuls les entiers positifs sont autorisés. La valeur par défaut est `7200` secondes. La valeur minimale admise est `1` seconde et la valeur maximale admise est `2147483647` secondes.
Format du jeton d'accès	Indique si le jeton d'accès est généré sous la forme d'une chaîne opaque, c'est-à-dire`Default`sous forme de paramètre ou au format JWT.
Audiences	Spécifie les cibles qui sont les destinataires du jeton. Ces valeurs sont répertoriées dans la réclamation aud pour les jetons formatés JWT et dans la charge introspection sous la forme soit d'une chaîne unique, soit d'un tableau de chaînes.
Mappage d'attributs d'introspection	Cette liste de mappages d'attributs est utilisée pour inclure des réclamations dans le contenu de l'introspection et le jeton d'accès au format JWT (jeton Web JSON).
Nom d'attribut	Nom de l'attribut que la partie de confiance utilise et exige de Verify. Les noms d'attributs suivants ne peuvent pas être utilisés : aud, exp, groupIds, groupUids at_hash, c_hash, rt_hash, s_hash, iat, iss,, nonce, sub, client_id, grant_id, grant_type et scope.
Attributs	Répertorie toutes les sources d'attributs que vous avez définies pour chaque type dans Répertoire > Attributs. La valeur de votre source d'attribut sélectionnée est affectée en tant que valeur d'attribut pour le nom d'attribut de la partie utilisatrice dans le jeton d'ID.
Générer un jeton d'actualisation	Indique si l 'application cliente peut demander et utiliser un jeton de rafraîchissement pour obtenir un nouveau jeton d'accès auprès du serveur d'autorisation du fournisseur d'identité OpenID Connect. N'utilisez cette option que si l'application prévoit d'utiliser le jeton d'accès pour effectuer des opérations via Verify des API. Il suffit d'obtenir un nouveau jeton d'accès si le précédent est arrivé à expiration. Cette option n'est pas pertinente si vous avez sélectionné "Implicite" dans la zone Types d'octroi.
Expiration du jeton d'actualisation (secs)	Définit la durée en secondes au bout de laquelle le jeton d'actualisation expire. Ce paramètre détermine la fréquence à laquelle l'utilisateur peut se réauthentifier. Définissez la durée de validité du jeton d'actualisation afin de garantir que l'utilisateur relance l'opération complète d'authentification unique après Verify un certain laps de temps. Cette option est affichée uniquement si vous avez activé l'option Générer un jeton d'actualisation. Un jeton d'actualisation est utilisé pour obtenir un nouveau jeton d'accès afin d'assurer la continuité de l'accès à la ressource protégée. Seuls les entiers positifs sont autorisés. La valeur par défaut est `604800` secondes. La valeur minimale admise est `1` seconde et la valeur maximale admise est `2147483647` secondes.
Renouveler la durée de vie du jeton d'actualisation	Cette option indique si la durée de vie du jeton d'actualisation est renouvelée lorsqu'un jeton d'actualisation est utilisé pour obtenir un nouvel ensemble de jetons. Si cette case est cochée, la durée de vie définie par Expiration du jeton d'actualisation est renouvelée chaque fois que les jetons d'actualisation sont actualisés. Si elle ne l'est pas, le jeton d'actualisation renouvelé arrive à expiration lorsque le délai initial défini par Expiration du jeton d'actualisation est atteint.

Spécifiez les options de signature et de chiffrement du jeton d'identification. La partie qui se fie à la signature utilise celle-ci pour vérifier l'intégrité et l'authenticité des informations d'identification de l'utilisateur contenues dans le jeton, ainsi que celles du fournisseur d'identité OpenID Connect qui a signé le jeton. Le jeton peut être chiffré de sorte que seule la partie utilisatrice puisse le déchiffrer.

Tableau 2. Options de signature et de chiffrement
Zone	Descriptif
Algorithme de signature	L'algorithme utilisé Verify pour signer le jeton d'identification. L'algorithme doit correspondre à celui que la partie de confiance a enregistré auprès de Verify. Choisissez l'un des algorithmes de hachage suivants pour vérifier la signature : HS256 HS384 HS512 ES256 ES384 ES512 PS256 PS384 PS512 RS256 (valeur par défaut) RS384 RS512 Remarque : Si l'algorithme de signature ES256 est sélectionné, le certificat doit être ECDSA avec P-256. Si l'algorithme de signature ES384 est sélectionné, le certificat doit être ECDSA avec P-384. Si l'algorithme de signature ES512 est sélectionné, le certificat doit être ECDSA avec P-521. Les algorithmes HS ne sont pas affichés si vous choisissez de ne pas générer un secret client.
Signature du certificat	Cette option est affichée uniquement si vous avez sélectionné des algorithmes de signature RS, ES ou PS. Utilisez ce certificat pour signer le jeton d'ID au cours de la connexion unique. La sélection par défaut fait référence au certificat personnel par défaut que vous avez configuré dans Sécurité > Certificats > Certificats personnels.
Algorithme de chiffrement	Algorithme de chiffrement utilisé pour chiffrer ou déterminer la valeur de la clé de chiffrement de contenu (CEK). Les algorithmes suivants sont pris en charge : RSA-OAEP RSA-OAEP-256
Algorithme de contenu	Algorithme de chiffrement de contenu utilisé pour effectuer un chiffrement authentifié sur le texte en clair pour produire le texte de chiffrement et la balise d'authentification. Les algorithmes suivants sont pris en charge : A128GCM A192GCM A256GCM
Clé de chiffrement	Libellé de certificat ou ID de la clé à utiliser pour le chiffrement.

Verify Répertoriez les attributs utilisateur pris en charge et fournis à la partie de confiance via le jeton d'identification.

Verify pourrait étendre le schéma JSON standard des revendications afin d'y inclure des attributs supplémentaires tels que le poste de l'employé, son supérieur hiérarchique et son service.

Remarque : les attributs suivants sont déjà ajoutés par défaut au jeton d'identification : userType, uniqueSecurityName, displayName, realmName, name, preferred_username jti,, at_hash, ext. Certains de ces attributs peuvent être supprimés du jeton d'identification en les mappant à une source d'attributs configurée pour ne renvoyer aucune valeur.

La section « Mappages d'attributs » comprend les éléments suivants, décrits dans le tableau 3.

Une option de case à cocher pour l'envoi de tous les attributs utilisateur connus.
Possibilité d'ajouter des noms d'attributs et leur source correspondante dans Verify.

Tableau 3. Correspondances d'attributs
Informations	Descriptions
Envoyer tous les attributs utilisateur connus dans le jeton d'ID	Une fois cette option sélectionnée, tous les attributs d'identification de l'utilisateur connus et disponibles via la source d'identité du fournisseur « OpenID Connect » sont automatiquement inclus dans le jeton d'identification. Les attributs connus des données d'identification utilisateur sont les suivants : Attributs standard Ces attributs proviennent du Verify répertoire Cloud, qui comprend les attributs intégrés affichés dans Répertoire > Attributs. Attributs étendus Ces attributs proviennent du fournisseur d'identité d'entreprise « SAML » que vous avez configuré dans Authentification > Fournisseurs d'identité. Sinon, définissez uniquement les attributs spécifiques requis par la partie utilisatrice dans le jeton d'ID. Spécifiez le nom d'attribut et la source d'attribut.
Nom d'attribut	VerifyNom de l'attribut utilisé et exigé par la partie de confiance. Les noms d'attributs suivants ne peuvent pas être utilisés : aud, exp, groupIds, groupUids at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, client_id, grant_id,, grant_type et scope. Si le nom de l'attribut est `sub`, ce mappage d'attribut modifie la valeur de `sub` dans la réponse d'introspection, le jeton d'accès JWT, la réponse userinfo et le jeton d'identification.
Attributs	Répertorie toutes les sources d'attributs que vous avez définies pour chaque type dans Répertoire > Attributs. La valeur de votre source d'attribut sélectionnée est affectée en tant que valeur d'attribut pour le nom d'attribut de la partie utilisatrice dans le jeton d'ID. Remarque : si la mention « Sans balise » apparaît pour la valeur source de l'attribut, c'est que la fonction de cet attribut a été modifiée. Les applications existantes qui se servent de l'attribut peuvent continuer de l'utiliser jusqu'à ce que vous remappiez l'application afin d'utiliser un attribut différent pour ce même but. Par exemple, si la case à cocher Connexion unique est désélectionnée pour un attribut existant, les applications qui se servent déjà de cet attribut pour la connexion unique peuvent continuer de l'utiliser pour la connexion unique. Le même comportement s'applique aux mappages des attributs d'application des accès lorsque le but Application des accès est retiré.

Sélectionnez les sources d'identité et la stratégie qui déterminent la manière dont les utilisateurs peuvent accéder à l'application.
1. Sélectionnez les sources d'identité pouvant être utilisées pour la connexion à cette application.
  
  Le paramètre par défaut permet d'autoriser l'accès à partir de toutes les sources d'identité d'entreprise configurées pour le titulaire. Pour limiter les sources d'identité permettant de se connecter à l'application, choisissez Sélectionner des sources d'identité prises en charge spécifiques. Cochez les cases correspondant aux sources d'identité à partir desquelles vous souhaitez autoriser la connexion.
2. Sélectionnez la stratégie qui détermine la manière dont les utilisateurs peuvent accéder à l'application.
  Vous pouvez continuer d'utiliser la stratégie d'accès par défaut affectée, c'est-à-dire Autoriser l'accès depuis tous les appareils. Vous pouvez également décocher la case, puis cliquer sur pour choisir parmi la liste des politiques d'accès prédéfinies. Une fois la politique d'accès sélectionnée, vous pouvez l'appliquer aux différents types d'autorisation API en cochant la case correspondante pour chaque type d'autorisation. Pour plus d'informations, consultez la section « Politiques d'accès ».
Indiquez si vous souhaitez demander le consentement de l'utilisateur.
La demande d'accord de la part de l'utilisateur peut être ajoutée à des applications Open ID Connect. Elle est disponible pour tous les types d'octroi sauf pour ROPC (Resource Owner Password Credentials). Si ROPC est le seul type d'octroi sélectionné pour l'application, l'option Accord de l'utilisateur est masquée. Si la valeur par défaut Demander l'accord reste sélectionnée, l'utilisateur est invité à autoriser explicitement les portées et les droits d'accès aux API. Il peut accorder ou refuser les droits permettant d'accéder aux API. Les applications Open ID Connect existantes ne requièrent pas d'accord. Vous devez éditer ces applications si vous voulez que l'accord de l'utilisateur soit demandé. Voir la section « Gestion des autorisations des applications ».
Une fois que l'application a été créée, la zone Type d'accord est affichée avec la valeur Avancé sous Demander l'accord. La valeur Avancé indique que les accords utilisateur sont stockés dans DPCM. Les applications OIDC personnalisées plus anciennes affichent cette zone après la migration de leurs accords vers DPCM.
Facultatif : limiter les champs d'application personnalisés.
Des portées personnalisées peuvent être demandées par un client IODC/OAuth dans les flux d'octroi IODC/OAuth pris en charge. Si l'option Restreindre les portées personnalisées est activée (elle l'est par défaut), les portées octroyées au client à la fin du flux se limitent à celles qui figurent dans cette section. Si l'option Limiter les portées personnalisées est désactivée, toutes les portées personnalisées demandées sont accordées à la fin du flux.
openidRemarque : les portées standard, profile, email, phone, et address ne peuvent pas être restreintes.
1. Assurez-vous que la case « Restreindre les champs d'application personnalisés » est cochée.
2. Entrez le nom de la portée personnalisée à octroyer ainsi qu'une description.
  Le nom de la portée référence la portée OAuth2/OIDC qui est demandée par une partie utilisatrice/un client. La description est une explication compréhensible de la portée.
  
  Un autre ensemble de zones de portée est affiché.
3. Répétez l'étape précédente pour chaque portée personnalisée à octroyer.
Facultatif : attribuer des autorisations API au jeton d'authentification.
Le paramètre Restrict API access est le paramètre par défaut des nouvelles applications. L'application ne dispose pas d'autorisation sur les jetons de connexion. Pour octroyer des autorisations d'accès aux API, procédez comme suit :
1. Cliquez sur l'icône Editer.
  L'assistant Editer le client API démarre.
2. Sélectionnez les droits utilisateur et non utilisateur à octroyer au jeton de connexion.
  Si vous cochez la case « Autorisations par défaut pour les jetons utilisateur » ou décochez la case « Restreindre l'accès à l'API », un ensemble de droits par défaut est attribué aux jetons utilisateur.
3. Cliquez sur Enregistrer.
Cliquez sur Enregistrer.

Que faire ensuite

Fournissez à la partie de confiance les Verify informations nécessaires pour finaliser la configuration de l'authentification « Connect » d' OpenID entre Verify [nom de l'entité] et la partie de confiance. Voir les instructions fournies dans l'interface utilisateur.
Ajoutez des habilitations d'utilisateur ou de groupe pour permettre l'accès aux applications configurées. Voir « Gestion des droits d'accès aux applications » (par l'administrateur ou le propriétaire de l'application).
Imposez aux utilisateurs l'authentification à deux facteurs pour un meilleur contrôle de la sécurité lorsqu'ils se connectent aux applications configurées. Voir la section « Configuration des facteurs d'authentification ».