Sélection de la langue

Government of Canada / Gouvernement du Canada

Conseils sur la configuration sécurisée des cadres liés à l’authentification et à l’autorisation - ITSP.40.063

Date d'entrée en vigueur

Le présent document entre en vigueur le 13 juillet 2026.

Historique des révisions

  1. Première diffusion : 13 juillet 2026.

Vue d'ensemble

La présente publication identifie et décrit les cadres liés à l'authentification et à l'autorisation que les organisations peuvent mettre en œuvre pour protéger l'information sensible. Dans le cas des ministères et des organismes du gouvernement du Canada (GC), les directives contenues dans ce document s'appliquent à l'information NON CLASSIFIÉ, PROTÉGÉ A, et PROTÉGÉ B. Il convient de consulter les présents conseils conjointement avec le document Algorithmes cryptographiques pour l'information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B (ITSP.40.111). Les configurations de la présente publication sont conformes aux exigences cryptographiques dans l'ITSP.40.111.

La capacité de votre organisation à traiter l'autorisation et l'authentification des utilisatrices et utilisateurs en toute sécurité est essentielle pour la prestation de vos programmes et services. Les cadres liés à la sécurité cryptographique servent à assurer la confidentialité, l'intégrité et la disponibilité de l'information du GC en plus d'aider à protéger ce dernier contre certaines menaces de cyberintrusion.

Une configuration appropriée des cadres liés à l'authentification et à l'autorisation permet d'assurer la confidentialité, l'intégrité et la disponibilité des données, l'authentification et l'imputabilité des intervenantes et intervenants, de même que la non-répudiation. Il se peut que vous ayez à utiliser divers cadres pour satisfaire aux exigences de votre organisation en matière de sécurité. Vous devriez sélectionner et mettre en œuvre chaque cadre de façon à respecter toutes les exigences.

Pour plus d'information sur la configuration sécurisée des cadres liés à l'authentification et à l'autorisation, communiquez avec le Centre canadien pour la cybersécurité (Centre pour la cybersécurité).

Table des matières

1 Introduction

Les organisations recourent à des systèmes de technologies de l'information (TI) pour atteindre leurs objectifs opérationnels. Ces systèmes interconnectés peuvent faire l'objet de sérieuses cyberattaques et d'autres menaces susceptibles de nuire à la disponibilité, à la confidentialité et à l'intégrité des actifs informationnels. Des réseaux, des systèmes ou des renseignements compromis peuvent influer négativement les activités opérationnelles et entraîner une atteinte à la protection des données ainsi que des pertes financières.

Cette publication fournit des conseils sur la configuration sécurisée des cadres liés à l'authentification et à l'autorisation pour protéger l'information sensible au moyen d'algorithmes cryptographiques recommandés par le Centre pour la cybersécurité pour les niveaux NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B. Le présent document complète la Ligne directrice sur la définition des exigences en matière d'authentification du Secrétariat du Conseil du Trésor du Canada (SCT). Chaque organisation est responsable de déterminer ses objectifs et exigences en matière de sécurité dans son cadre de gestion des risques.

1.1 Processus de gestion des risques liés à la sécurité des TI

Lors de la mise en place de protocoles de sécurité, les praticiennes et praticiens devraient tenir compte des activités relatives à la gestion des risques liés à la sécurité des TI qui sont décrites dans le document Gestion des risques liés à la cybersécurité et à la vie privée : Une méthode axée sur le cycle de vie (ITSP.10.033). L'ITSP.10.033 décrit deux niveaux d'activités de gestion des risques liés à la sécurité des TI, à savoir les activités du niveau ministériel et du niveau des systèmes d'information. Il comprend également un catalogue de contrôles de sécurité, comme les exigences de sécurité normalisées visant à protéger la confidentialité, l'intégrité et la disponibilité des biens de TI.

De plus, les organisations devraient tenir compte des activités de gestion des risques suivantes :

  • définir;
  • développer;
  • allouer;
  • surveiller et évaluer;
  • maintenir et mettre à jour.

Consultez le document Activités organisationnelles de gestion des risques pour la cybersécurité et la vie privée (ITSP.10.036) pour en apprendre plus sur ces activités.

Les activités de gestion des risques au niveau ministériel (ou au niveau organisationnel pour les organismes qui ne font pas partie du GC) font partie des programmes de sécurité ministériels ou organisationnels dans l'objectif de planifier, de gérer, d'évaluer et d'améliorer la gestion des risques à la sécurité des TI.

Les activités de gestion des risques au niveau des systèmes d'information sont comprises dans le cycle de vie des systèmes d'information par l'intermédiaire du processus d'application de la sécurité dans les systèmes d'information (PASSI). Lors de la mise en place des protocoles de sécurité réseaux, vous devriez tenir compte des étapes du PASSI. Consultez le document Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes (ITSP.10.037) pour en apprendre plus sur la gestion des risques liés à la sécurité des systèmes d'information.

1.2 Recommandations générales

Pour chaque cadre mentionné dans cette publication, il est préférable de considérer les recommandations comme un ensemble. Le fait de ne pas suivre l'ensemble des recommandations peut entraîner des failles de sécurité.

Lors de l'utilisation d'une infrastructure à clé publique (ICP) avec l'un ou l'autre de ces cadres, vous devriez suivre les conseils sur les ICP contenus dans le document Conseils sur la configuration sécurisée des protocoles réseau (ITSP.40.062).

1.3 Cryptographie post-quantique

L'informatique quantique menace de percer de nombreux cryptosystèmes à clé publique que nous utilisons actuellement. En août 2024, le National Institute of Standards and Technology (NIST) a publié des normes pour la normalisation de la cryptographie post-quantique. Ces normes sont conçues pour résister aux avantages qu'auront les ordinateurs quantiques à venir. Pour de plus amples renseignements sur ces normes, consultez le document Algorithmes cryptographiques pour l'information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B (ITSP.40.111).

Lorsque les normes pour les divers cadres d'authentification et d'autorisation auront été révisées afin de tenir compte de la cryptographie post-quantique, le Centre pour la cybersécurité prévoit inclure des recommandations relatives aux configurations post-quantiques dans une mise à jour du présent document.

D'ici là, le Centre pour la cybersécurité recommande les étapes de haut niveau suivantes :

  • évaluer la sensibilité des renseignements de l'organisation et en déterminer la longévité afin d'identifier les renseignements pouvant être à risque (p. ex. dans le cadre de processus continus d'évaluation des risques);
  • passer en revue le budget et le plan de gestion du cycle de vie des TI de l'organisation pour déterminer les mises à jour logicielles et matérielles pouvant s'avérer importantes;
  • sensibiliser le personnel à la menace quantique.

Pour obtenir de plus amples renseignements, veuillez consulter le document Préparez votre organisation à la menace que pose l'informatique quantique pour la cryptographie (ITSAP.00.017).

Les organisations devraient attendre que les normes pour l'utilisation de la cryptographie post-quantique dans les cadres soient publiées avant de faire une révision des configurations pour protéger l'information ou les systèmes.

Haut de la page 

2 OAuth et OpenID Connect

OAuth est un cadre de protocole d'autorisation qui tire parti d'un serveur d'autorisation tiers permettant à une utilisatrice ou un utilisateur final d'autoriser un client à accéder à ses ressources. Le protocole OpenID Connect (OIDC) peut être utilisé avec OAuth pour effectuer l'authentification des utilisatrices et utilisateurs. Les recommandations contenues dans cette section s'appliquent à l'utilisation de OAuth et de OIDC, à moins d'une indication contraire.

Dans OIDC, un client OAuth est désigné par le terme « partie utilisatrice » (relying party en anglais) et un serveur d'autorisation OAuth est désigné par les termes « fournisseur OpenID » ou « fournisseur d'identité ».

Le Centre pour la cybersécurité recommande d'utiliser la version 2.0 de OAuth, définie à l'origine dans le document Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749 The OAuth 2.0 Authorization Framework (en anglais seulement) et dans les mises à jour des demandes de commentaires (RFC pour Request for Comments) subséquentes, conformément aux conseils formulés dans cette section.

Lorsque vous utilisez OIDC, employez la version définie dans le document OpenID Connect Core 1.0 incorporating errata set 2 (en anglais seulement).

Le Centre pour la cybersécurité recommande également de sécuriser toutes les communications OAuth et OIDC avec le protocole TLS (pour Transport Layer Security) configuré conformément au document Conseils sur la configuration sécurisée des protocoles réseau (ITSP.40.062).

2.1 Clients OAuth et OpenID Connect

OAuth définit deux types de clients : public et confidentiel. Le Centre pour la cybersécurité recommande d'utiliser un client de type « confidentiel ».

Lorsque des demandes sont effectuées au serveur d'autorisation OAuth, votre organisation devrait utiliser l'une des méthodes suivantes pour l'authentification client :

  • client_secret_jwt
  • private_key_jwt
  • tls_client_auth (quand OAuth est utilisé seul)
  • self_signed_tls_client_auth (en utilisant seulement OAuth)

Dans le cas de la méthode d'authentification « client_secret_jwt » ou « private_key_jwt », l'identifiant d'émetteur (issuer identifier en anglais) du serveur d'autorisation devrait être utilisé comme valeur pour la déclaration « aud ».

2.1.1 Enregistrement des clients et découverte du serveur

Pour enregistrer des clients OAuth et OIDC, le Centre pour la cybersécurité recommande d'utiliser l'enregistrement dynamique conformément au document IETF RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol (en anglais seulement) et, dans le cas de clients OIDC, au document OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2 (en anglais seulement). Lorsqu'il y a un conflit entre ces deux spécifications, suivez les directives mentionnées dans le document RFC 7591.

Durant l'enregistrement, le Centre pour la cybersécurité recommande d'enregistrer l'information facultative suivante avec le serveur d'autorisation :

  • Tous les URI (pour Uniform Resource Identifier) de redirection que le client peut utiliser dans la demande d'autorisation; tous les URI doivent être complets et utiliser le schéma « https ».
  • La méthode d'authentification client et les algorithmes de signature associés qui seront utilisés aux points de terminaison du serveur d'autorisation.
  • Les algorithmes de chiffrement et de signature utilisés par les deux parties tout au long du protocole.

Les clients devraient enregistrer chaque URI de redirection avec seulement un serveur d'autorisation.

Le Centre pour la cybersécurité recommande d'utiliser le paramètre client « jwks_uri ». Les clients incapables d'héberger des adresses URL publiques devraient utiliser le paramètre « jwks ».

De plus, le Centre pour la cybersécurité recommande que les serveurs d'autorisation :

  • fournissent une façon pour les clients de demander et de mettre à jour leur information d'enregistrement;
  • assignent des ID client uniques à différentes instances du même logiciel;
  • assignent des secrets client uniques à toutes les demandes d'enregistrement, même celles provenant du même logiciel ou instance de logiciel;
  • fournissent des listes d'algorithmes de chiffrement et de signature pris en charge pour chaque type de données signées ou chiffrées;
  • fournissent l'emplacement du point de terminaison UserInfo (lorsque OIDC est utilisé).

Lorsque OIDC est utilisé, il convient d'appliquer le protocole de découverte OIDC, conformément au document OpenID Connect Discovery 1.0 incorporating errata set 2 (en anglais seulement).

Haut de la page 

2.2 Signatures numériques et chiffrement

OAuth et OIDC font largement appel aux signatures Web JSON (JWS pour JavaScript Object Notation [JSON] Web Signatures) et au chiffrement Web JSON (JWE pour JSON Web Encryptions).

Dans le cas où une JWS est utilisée dans OAuth ou OIDC, le Centre pour la cybersécurité recommande d'utiliser l'une des valeurs suivantes pour le paramètre « alg » :

  • PS256 (RSASSA-PSS utilisant SHA-256 et MGF1 avec SHA-256)
  • PS384 (RSASSA-PSS utilisant SHA-384 et MGF1 avec SHA-384)
  • PS512 (RSASSA-PSS utilisant SHA-512 et MGF1 avec SHA-512)
  • ES256 (ECDSA utilisant P-256 et SHA-256)
  • ES384 (ECDSA utilisant P-384 et SHA-384)
  • ES512 (ECDSA utilisant P-521 et SHA-512)
  • Ed25519 (EdDSA utilisant la courbe Ed25519)
  • Ed448 (EdDSA utilisant la courbe Ed448)

Si aucune des valeurs ci-dessus n'est disponible, il est suffisant d'utiliser l'une des valeurs suivantes pour le paramètre « alg » :

  • RS256 (RSASSA-PKCS1-v1_5 utilisant SHA-256)
  • RS384 (RSASSA-PKCS1-v1_5 utilisant SHA-384)
  • RS512 (RSASSA-PKCS1-v1_5 utilisant SHA-512)

S'il est nécessaire d'utiliser la méthode d'authentification « client_secret_jwt », l'un des algorithmes suivants peut être utilisé pour le paramètre JWS « alg » lors de la signature du jeton Web JSON (JWT pour JSON Web Token) d'authentification du client :

  • HS256 (HMAC utilisant SHA-256)
  • HS384 (HMAC utilisant SHA-384)
  • HS512 (HMAC utilisant SHA-512)

Dans le cas où un JWE est utilisé dans OAuth ou OIDC, le Centre pour la cybersécurité recommande d'utiliser l'une des valeurs suivantes pour le paramètre « alg » :

  • RSA-OAEP-256 (RSAES OAEP utilisant SHA-256 et MGF1 avec SHA-256)
  • RSA-OAEP-384 (RSA-OAEP utilisant SHA-384 et MGF1 avec SHA-384)
  • RSA-OAEP-512 (RSA-OAEP utilisant SHA-512 et MGF1 avec SHA-512)
  • ECDH-ES (ECDH-ES utilisant Concat KDF)
  • ECDH-ES+A128KW (ECDH-ES utilisant Concat KDF et enveloppement « A128KW »)
  • ECDH-ES+A192KW (ECDH-ES utilisant Concat KDF et enveloppement « A192KW »)
  • ECDH-ES+A256KW (ECDH-ES utilisant Concat KDF et enveloppement « A256KW »)

Dans le cas où un JWE est utilisé dans OAuth ou OIDC, le Centre pour la cybersécurité recommande d'utiliser l'une des valeurs suivantes pour le paramètre « enc » :

  • A128CBC-HS256 (algorithme de chiffrement authentifié AES_128_CBC_HMAC_SHA_256)
  • A192CBC-HS384 (algorithme de chiffrement authentifié AES_192_CBC_HMAC_SHA_384)
  • A256CBC-HS512 (algorithme de chiffrement authentifié AES_256_CBC_HMAC_SHA_512)
  • A128GCM (AES GCM utilisant une clé de 128 bits)
  • A192GCM (AES GCM utilisant une clé de 192 bits)
  • A256GCM (AES GCM utilisant une clé de 256 bits)
Haut de la page 

2.3 Autorisation

Le Centre pour la cybersécurité recommande d'utiliser l'octroi de code d'autorisation (authorization code grant en anglais) pour OAuth et le flux de code d'autorisation (authorization code flow en anglais) pour OIDC. Lorsqu'un client OAuth demande l'accès à ses propres ressources, l'octroi de justificatifs d'accès du client (client credentials grant en anglais) peut être utilisé à la place.

Les codes d'autorisation devraient avoir une durée de vie maximale de 60 secondes.

2.3.1 Demandes et réponses d'autorisation

Le Centre pour la cybersécurité recommande d'utiliser les paramètres « redirect_uri » et « state » dans les demandes d'autorisation. Les serveurs d'autorisation devraient s'assurer qu'il existe une correspondance exacte de chaînes entre la valeur du « redirect_uri » et l'un des URI de redirection fournis lors de l'enregistrement. Vous devriez aussi utiliser le paramètre « nonce » lorsque vous utilisez OIDC.

Le Centre pour la cybersécurité recommande d'utiliser l'un des modes de réponse suivants :

  • form_post
  • jwt (chiffré)
  • jwt (chiffré)
  • jwt (chiffré ou non chiffré)

Lorsque vous utilisez OAuth, vous devriez utiliser les demandes d'autorisation enrichies, conformément au document IETF RFC 9396 OAuth 2.0 Rich Authorization Requests (en anglais seulement), et l'extension Clé de preuve pour l'échange de code (PKCE pour Proof Key for Code Exchange) conformément au document IETF RFC 7636 Proof Key for Code Exchange by OAuth Public Clients (en anglais seulement) avec « S256 » comme méthode de défi par code. L'utilisation de la PKCE avec OIDC est facultative.

Au moins l'un des paramètres « state », « nonce » et « code_challenge » devrait être lié cryptographiquement à l'agent utilisateur.

Les réponses d'autorisation devraient contenir la déclaration de l'identifiant d'émetteur « iss », conformément au document IETF RFC 9207 OAuth 2.0 Authorization Server Issue Identification (en anglais seulement) ou être encodées, conformément au document JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) (en anglais seulement).

2.3.2 Demandes d'autorisation poussées

Le Centre pour la cybersécurité recommande d'utiliser les demandes d'autorisation poussées, conformément au document IETF RFC 9126 OAuth 2.0 Pushed Authorization Requests (en anglais seulement). Toute adresse URI générée par le serveur d'autorisation aux fins d'utilisation avec des demandes d'autorisation poussées devrait avoir une durée de vie maximale de 60 secondes et être à usage unique. Les clients ne devraient pas être autorisés à utiliser des adresses URI de redirection non enregistrées.

2.3.3 Demande d'autorisation sécurisée par JWT

Les demandes d'autorisation sécurisées par JWT (JAR pour JWT-secured authorization request), conformément au document IETF RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) (en anglais seulement), peuvent être utilisées facultativement. Lorsqu'une JAR est utilisée, le Centre pour la cybersécurité recommande d'utiliser le paramètre « request » pour envoyer l'objet de demande au serveur d'autorisation. Les objets de demande devraient être signés et les clés utilisées ne devraient pas être utilisées pour signer d'autres JWT. L'objet de demande peut être chiffré après la signature. De plus, les objets de demande devraient être à usage unique et contenir un paramètre « state » unique. En ce qui a trait à OIDC, l'objet de demande devrait contenir un paramètre « nonce » unique. Les serveurs d'autorisation devraient vérifier la source d'une demande en vérifiant la signature JWS.

Haut de la page 

2.4 Jetons

2.4.1 Échange d'acquisition de jetons

L'échange d'acquisition de jetons permet au client d'obtenir des jetons d'ID et d'accès. Le client devrait inclure la valeur de l'URI de redirection dans la demande d'acquisition de jetons et s'assurer que la valeur est la même que celle dans la demande d'autorisation correspondante.

Le serveur d'autorisation devrait vérifier qu'un code d'autorisation n'est utilisé qu'une fois. Si le serveur d'autorisation détecte une tentative de réutilisation d'un code d'autorisation, il devrait révoquer tous les jetons émis pour ce code d'autorisation.

2.4.2 Jetons d'accès

Les jetons d'accès autorisent un client à accéder à un serveur de ressources au nom d'une utilisatrice ou un utilisateur. Le Centre pour la cybersécurité recommande que les implémentations formatent les jetons d'accès comme des JWT et que ceux-ci soient signés. Le chiffrement de ces jetons est facultatif.

Les jetons d'accès devraient :

  • avoir une durée de vie maximale de 3 600 secondes;
  • être transmis dans l'en-tête HTTP;
  • être associés à un seul serveur de ressources.

Lors de l'utilisation de OAuth, l'objet contenant les détails de l'autorisation (authorization details object en anglais) devrait être inclus comme déclaration dans le jeton.

Le Centre pour la cybersécurité recommande d'utiliser des jetons d'accès aux ressources contraints à l'émetteur en utilisant l'une des méthodes suivantes :

Lorsque le TLS mutuel est utilisé, vous devriez :

Lorsque la démonstration de la preuve de possession est utilisée, vous devriez utiliser un « DPoP nonce » fourni par le serveur et lier le code d'autorisation à la clé DPoP.

2.4.3 Jetons d'ID du protocole OpenID Connect

Cette sous-section s'applique seulement à OIDC.

Un jeton d'ID contient des déclarations affirmant que l'utilisatrice ou utilisateur a été authentifié. Lorsqu'un jeton d'ID et un jeton d'accès sont émis ensemble, la déclaration « at_hash » devrait être incluse dans le jeton d'ID.

Le Centre pour la cybersécurité recommande que tous les jetons d'ID soient signés et que les jetons d'ID qui sont renvoyés par un point de terminaison d'autorisation soient chiffrés. Les jetons d'ID renvoyés par un point de terminaison d'acquisition de jetons peuvent être chiffrés, au besoin.

2.4.4 Jetons d'actualisation

Un jeton d'actualisation permet à un client d'obtenir un nouveau jeton d'accès ou d'ID sans réauthentifier l'utilisatrice ou utilisateur. Le Centre pour la cybersécurité recommande de formater les jetons d'actualisation comme des JWT signés, qui peuvent être chiffrés au besoin.

De plus, les jetons d'actualisation devraient :

  • être révocables et avoir un délai d'expiration;
  • être contraints à l'émetteur ou à usage unique;
  • être utilisés avec une rotation des jetons d'actualisation.

Lors de l'utilisation de OIDC, si un jeton d'ID est renvoyé dans une réponse d'actualisation, ce jeton ne devrait pas contenir le nonce qui était dans le jeton d'ID original.

2.5 Point de terminaison UserInfo d'OpenID Connect

Cette sous-section s'applique seulement à OIDC.

Un point de terminaison UserInfo permet aux clients de récupérer les déclarations concernant une utilisatrice ou un utilisateur authentifié. Les demandes UserInfo devraient utiliser la méthode HTTP « GET » et envoyer les jetons d'accès en utilisant le champ d'en-tête « authorization ».

Le Centre pour la cybersécurité recommande aussi que la réponse UserInfo soit signée. La réponse UserInfo peut être chiffrée après la signature, au besoin.

Haut de la page 

3 Protocole de négociation d'octrois et d'autorisation (GNAP pour Grant Negotiation and Authorization Protocol)

Le GNAP est précisé dans les documents IETF RFC 9635 Grant Negotiation and Authorization Protocol (GNAP) (en anglais seulement) et IETF RFC 9767 Grant Negotiation and Authorization Protocol Resource Server Connections (en anglais seulement). Il définit un mécanisme permettant à une instance de logiciel client d'envoyer une demande à un serveur d'autorisation pour obtenir l'accès délégué aux ressources d'une utilisatrice ou un utilisateur sur un serveur de ressources et/ou à son information d'identification.

3.1 Clé d'instance client

La clé d'instance client est liée au jeton d'accès pour une instance client particulière et peut être utilisée par les serveurs d'autorisation pour identifier cette instance. Les clients qui interagissent avec de multiples serveurs d'autorisation devraient utiliser une différente clé pour chaque serveur avec lequel ils interagissent.

Les clients devraient utiliser l'un des formats de clé suivants :

  • jwk
  • cert
  • cert#S256

Lors de l'utilisation du format jwk, utilisez l'un des algorithmes suivants pour le paramètre « alg » :

  • RSA-OAEP-256 (RSAES OAEP utilisant SHA-256 et MGF1 avec SHA-256)
  • RSA-OAEP-384 (RSA-OAEP utilisant SHA-384 et MGF1 avec SHA-384)
  • RSA-OAEP-512 (RSA-OAEP utilisant SHA-512 et MGF1 avec SHA-512)
  • ECDH-ES (ECDH-ES utilisant Concat KDF)
  • ECDH-ES+A128KW (ECDH-ES utilisant Concat KDF et enveloppement « A128KW »)
  • ECDH-ES+A192KW (ECDH-ES utilisant Concat KDF et enveloppement « A192KW »)
  • ECDH-ES+A256KW (ECDH-ES utilisant Concat KDF et enveloppement « A256KW »)
  • A128KW (enveloppement de clé AES utilisant une clé de 128 bits)
  • A192KW (enveloppement de clé AES utilisant une clé de 192 bits)
  • A256KW (enveloppement de clé AES utilisant une clé de 256 bits)
  • A128GCMKW (enveloppement de clé avec AES GCM utilisant une clé de 128 bits)
  • A192GCMKW (enveloppement de clé avec AES GCM utilisant une clé de 192 bits)
  • A256GCMKW (enveloppement de clé avec AES GCM utilisant une clé de 256 bits)

Le Centre pour la cybersécurité recommande d'utiliser l'un des formats de preuve suivants, conformément au RFC 9635 :

  • httpsig
  • mtls
  • jwsd
  • jws

3.2 Réponse d'octroi (grant response)

Après avoir reçu une demande d'une instance client, le serveur d'autorisation envoie une réponse d'octroi. Dans la réponse d'octroi, l'un des formats de jetons suivants (conformément au RFC 9767) devrait être utilisé :

  • jwt-signed
  • jwt-encrypted

Les jetons au porteur (bearer tokens en anglais) ne devraient pas être utilisés comme jetons d'accès à l'extérieur des systèmes internes de confiance. Tous les jetons d'accès devraient être liés à une clé. Les jetons d'ID devraient utiliser le format d'assertion « id_token », conformément au RFC 9635.

3.3 Interaction

Le Centre pour la cybersécurité recommande d'utiliser ce qui suit :

  • le mode de démarrage d'interaction « redirect »;
  • la méthode de finalisation d'interaction « redirect »;
  • l'une des méthodes de hachage suivantes pour la méthode de hachage employée lors de la finalisation d'interaction :
    • sha-256
    • sha-384
    • sha-512
    • sha3-256
    • sha3-384
    • sha3-512
Haut de la page 

4 Fast Identity Online 2

Fast Identity Online 2 (FIDO2) est un cadre comprenant deux protocoles : WebAuthn (pour Web Authentication) et CTAP (pour Client-to-Authenticator Protocol). Lorsqu'ils sont utilisés ensemble, ils permettent à un serveur, appelé « partie utilisatrice » (relying party en anglais), d'authentifier une utilisatrice ou un utilisateur final en employant des clés d'accès basées sur la cryptographie à clé publique plutôt que des mots de passe traditionnels.

Le Centre pour la cybersécurité recommande de sécuriser toutes les communications entre l'application et le serveur de la partie utilisatrice avec le protocole TLS configuré conformément aux conseils formulés dans le document Configuration sécurisée des protocoles réseau (ITSP.40.062). Les applications client devraient vérifier l'authenticité du serveur avant d'effectuer toute action au nom de ce serveur.

Les parties utilisatrices devraient utiliser une interface de programmation d'application (API pour Application Programming Interface) WebAuthn fournie par un navigateur Web ou par un système d'exploitation pour effectuer des opérations FIDO2.

4.1 Enregistrement de justificatifs d'accès

Dans l'objet « PublicKeyCredentialCreationOptions » :

  • l'option « attestation » devrait avoir la valeur « direct »;
  • l'option « authenticatorSelection » devrait avoir les paramètres suivants :
    • « residentKey » avec la valeur « required »;
    • « requireResidentKey » avec la valeur « true »;
    • « userVerification » avec la valeur « required »;
  • l'option « pubKeyCredParams » devrait utiliser l'une des valeurs suivantes pour le paramètre « alg » :
    • ES256 (ECDSA avec SHA-256)
    • ES384 (ECDSA avec SHA-384)
    • ES512 (ECDSA avec SHA-512)
    • Ed25519 (EdDSA utilisant la courbe Ed25519)
    • Ed448 (EdDSA utilisant la courbe Ed448)
    • PS256 (RSASSA-PSS utilisant SHA-256 et MGF1 avec SHA-256)
    • PS384 (RSASSA-PSS utilisant SHA-384 et MGF1 avec SHA-384)
    • PS512 (RSASSA-PSS utilisant SHA-512 et MGF1 avec SHA-512)
  • Si aucune des valeurs ci-dessus n'est disponible pour le paramètre « alg », il est suffisant d'utiliser l'une des valeurs suivantes :
    • RS256 (RSASSA-PKCS1-v1_5 utilisant SHA-256)
    • RS384 (RSASSA-PKCS1-v1_5 utilisant SHA-384)
    • RS512 (RSASSA-PKCS1-v1_5 utilisant SHA-512)

Les parties utilisatrices devraient prendre en charge l'extension de protection des justificatifs d'accès (credential protection extension en anglais) et sélectionner la valeur « true » pour le paramètre « enforceCredentialProtectionPolicy » ainsi que la valeur « userVerificationRequired » pour le paramètre « credentialProtectionPolicy ».

Une attestation devrait être requise dans la réponse à la demande de création de justificatifs d'accès. De plus, la partie utilisatrice devrait seulement accepter une attestation liée à un certificat racine d'une source de confiance.

4.2 Authentification

Le Centre pour la cybersécurité recommande de sélectionner la valeur « required » pour l'option « userVerification » dans l'objet « PublicKeyCredentialRequestOptions ».

L'authentification devrait échouer si la valeur du compteur de signatures (signature count en anglais) reçue dans une réponse d'authentification est inférieure ou égale à la valeur que la partie utilisatrice associe actuellement au justificatif d'accès.

Haut de la page 
Date de modification :