L’authentification vérifie l’identité d’un utilisateur (ou, dans les scénarios machine-to-machine, d’un client ou d’un service) avant qu’il ne puisse accéder à une ressource protégée. Elle répond à la question fondamentale « Qui êtes-vous ? ».

Avant qu’une application n’accorde l’accès, elle doit confirmer que l’entité qui le demande est bien celle qu’elle prétend être. L’authentification est la première étape du contrôle des accès et précède toujours l’autorisation. Vous devez vérifier l’identité avant de déterminer ce à quoi cette identité est autorisée à accéder.

Les utilisateurs et les services prouvent leur identité en présentant des identifiants ou des facteurs de vérification que le système valide par rapport aux enregistrements stockés ou à un fournisseur d’identité (IdP) externe de confiance. Pour vous représenter le processus, imaginez qu’un développeur présente une clé Secure Shell (SSH) à un serveur distant ; le serveur vérifie alors la signature de la clé pour confirmer l’identité du client.

Pourquoi c’est important : l’authentification établit l’identité avant d’accorder l’accès. Sans identité vérifiée, votre application ne peut pas appliquer les politiques d’autorisation, protéger les données sensibles ou établir des pistes d’audit.

Les facteurs d’authentification sont classés en trois catégories distinctes. Le niveau de sécurité inhérent à l’authentification multifacteur (MFA) provient de la combinaison de facteurs appartenant à au moins deux catégories.

Catégorie de facteur	Mécanisme de preuve	Exemple courant
Connaissance (une information que vous connaissez)	Secret mémorisé par l’utilisateur	Mot de passe, numéro d’identification personnel (PIN), phrase de passe
Possession (quelque chose que vous possédez)	Appareil physique ou token sous le contrôle de l’utilisateur	Smartphone (pour TOTP/push), clé de sécurité matérielle, clé FIDO2/WebAuthn, carte à puce
Inhérence (une caractéristique qui vous est propre)	Caractéristique biologique unique et vérifiable	Empreinte digitale, reconnaissance faciale, scan de l’iris

Outre les mots de passe de base, il existe plusieurs méthodes d’authentification, chacune offrant des compromis différents pour concilier sécurité et facilité d’utilisation.

Authentification par mot de passe

L’authentification par mot de passe est la méthode la plus courante. Les utilisateurs fournissent des identifiants, qui sont vérifiés par rapport à des enregistrements stockés de façon sécurisée.

Le stockage sécurisé des mots de passe nécessite des algorithmes de hachage adaptatifs et coûteux en termes de calcul, tels qu’Argon2, bcrypt ou PBKDF2, toujours avec des valeurs salt uniques pour chaque mot de passe (NIST SP 800-63B). N’utilisez jamais d’anciens algorithmes tels que MD5 ou SHA-1.

Vulnérabilité des mots de passe :

• Le phishing et les malwares volent directement les mots de passe.
• La réutilisation des mots de passe sur plusieurs sites permet à une seule brèche de compromettre plusieurs comptes.
• Les mots de passe faibles sont ceux que les utilisateurs choisissent parce qu’ils sont faciles à retenir.
• Le credential stuffing est une technique qui utilise des listes de mots de passe ayant fait l’objet de brèches antérieures.

L’authentification par mot de passe uniquement n’est pas suffisante pour les systèmes de production.

Authentification multifacteur (MFA)

L’authentification multifacteur (MFA, Multi-Factor Authentication) exige des utilisateurs qu’ils vérifient leur identité à l’aide d’au moins deux facteurs distincts appartenant à des catégories différentes avant que l’accès ne leur soit accordé.

Après avoir saisi un mot de passe, les utilisateurs doivent fournir un deuxième facteur, comme un code provenant d’une application d’authentification, une confirmation par notification push ou un contrôle biométrique. Ces mesures bloquent la plupart des attaques par vol d’identifiants, car les acteurs malveillants ont besoin des deux facteurs. Les codes reçus par SMS et par e‑mail sont moins sécurisés que les notifications push ou les authentificateurs matériels FIDO2.

Passkeys (FIDO2/WebAuthn)

Les passkeys, ou clés d’accès, remplacent les mots de passe par des identifiants FIDO2 qui, par leur conception, sont résistants au phishing. Elles s’appuient sur le protocole FIDO2 (WebAuthn et CTAP).

Les passkeys utilisent la cryptographie à clé publique. Lors de l’inscription, l’appareil génère une paire de clés publique/privée. La clé privée est liée cryptographiquement à l’appareil et conçue de façon à ne pas pouvoir être exportée de l’enclave sécurisée de l’appareil. La clé publique s’enregistre auprès du service, prouvant ainsi l’authenticité de l’appareil.

Lors de la connexion, l’appareil signe une demande d’authentification cryptographique. Cette signature ne fonctionne que pour le domaine spécifique qui l’a demandé. Un site de phishing ne peut pas intercepter et réutiliser la signature, même avec des proxys de phishing en temps réel. Les passkeys offrent une sécurité de niveau MFA résistante au phishing, car la clé privée ne quitte jamais l’appareil et est déverrouillée par la biométrie ou le code PIN de l’appareil. Elles peuvent être synchronisées entre les appareils via les gestionnaires d’identifiants de la plateforme (par exemple iCloud Keychain), à moins que les politiques exigent qu’elles restent liées à l’appareil.

Identité fédérée et authentification sociale

L’identité fédérée délègue l’authentification à un IdP externe de confiance.

OpenID Connect (OIDC) : les utilisateurs s’authentifient auprès de l’IdP. L’application reçoit un token d’identification signé cryptographiquement et contenant des revendications d’identité vérifiées (e‑mail, nom) sans avoir à manipuler les identifiants de l’utilisateur.

Cela élimine la nécessité de stocker les identifiants, réduit les frictions liées à l’onboarding et permet à l’application de tirer parti de l’infrastructure de sécurité de l’IdP. Dans les entreprises, SAML 2.0 est également utilisé pour l’authentification unique (SSO).

Authentification unique (SSO)

L’identification unique (SSO, Single Sign-On) permet aux utilisateurs de s’authentifier une fois auprès d’un IdP central et d’accéder ensuite à plusieurs applications sans avoir à saisir à nouveau leurs identifiants.

Le SSO utilise des protocoles tels que SAML 2.0 ou OpenID Connect. L’IdP émet un token de sécurité après la connexion de l’utilisateur et maintient la session. Les applications font confiance à cette session pour l’accès sans exiger de nouvelles connexions. De nombreuses entreprises alignent la durée de vie des sessions SSO sur celle des journées de travail normales. Les durées réelles dépendent des politiques de sécurité, des signaux de risque et des exigences posées par certaines polices d’assurance.

L’authentification moderne utilise un serveur d’autorisation dédié ou un IdP qui émet des tokens conformes aux standards établis pour l’accès.

OpenID Connect (OIDC) et OAuth 2.0

Comprendre la différence :

OAuth 2.0 est un cadre d’autorisation conçu uniquement pour la délégation d’accès. Il ne comprend pas de token ou de protocole standardisé pour vérifier l’identité de l’utilisateur final.

OpenID Connect (OIDC) est une couche d’identités fonctionnant par-dessus OAuth 2.0. OIDC offre aux clients un moyen standardisé de vérifier l’identité de l’utilisateur à l’aide d’un token d’identification, qui contient des revendications d’authentification signées de l’IdP.

Ils fonctionnent ensemble : OIDC gère l’authentification (preuve d’identité) et OAuth 2.0 gère l’autorisation (octroi de l’accès à l’API).

Flux de code d’autorisation avec PKCE

Le flux de code d’autorisation avec PKCE (Proof Key for Code Exchange) est le flux recommandé pour les applications web et mobiles. PKCE prévient les attaques par interception de code d’autorisation.

Fonctionnement : l’application génère un vérificateur de code à haute entropie et une demande d’authentification de code avec hachage. L’utilisateur s’authentifie auprès du serveur d’autorisation. Le serveur émet un code d’autorisation de courte durée (qui expire en quelques minutes). Le serveur contrôle que le vérificateur correspond à la demande avant d’émettre des tokens.

Le serveur émet un token d’identification contenant des revendications d’authentification pour le client, et un token d’accès pour appeler les API. Lorsque l’application demande un accès hors ligne (via le champ d’application offline_access), le serveur émet un token d’actualisation qui peut être utilisé pour renouveler les tokens d’accès sans réauthentification.

Authentification par token et JWT

Les API n’authentifient pas directement les utilisateurs : elles valident les tokens. Cette approche rend l’authentification sans état et évolutive, car l’API n’a pas besoin de conserver les informations de session dans une base de données.

Les JWT (JSON Web Token) sont le format de token le plus courant. Ils permettent une validation sans état de l’API, car toutes les revendications requises sont contenues dans le token. Certaines architectures restent totalement sans état, tandis que d’autres effectuent facultativement des contrôles supplémentaires (par exemple le statut de l’utilisateur ou la révocation du token) en fonction des exigences de sécurité.

Lorsqu’un client appelle l’API, il inclut le token d’accès dans le header Authorization: Bearer <token>. L’API doit valider le JWT à chaque demande pour s’assurer qu’il est authentique, qu’il n’a pas expiré et qu’il est destiné à l’application, selon les indications ci-dessous :

• Vérifier que la structure du token est conforme au format JWT `header.payload.signature`.
• Vérifier l’intégrité de la signature à l’aide de la clé appropriée pour s’assurer que le token n’a pas été altéré.
• Vérifier l’expiration (exp) et, éventuellement, les revendications nbf (not before) et iat (issued at) pour rejeter les tokens invalides ou prématurés.
• Confirmer que l’émetteur (iss) correspond à votre IdP de confiance.
• Vérifier que l’audience (aud) correspond à votre application.
• Préférer les algorithmes de signature asymétriques (RS256 ou ES256) afin que l’API valide les tokens à l’aide d’une clé publique sans stocker de secrets partagés ; n’utiliser HS256 que dans des environnements entièrement fiables.
• Ne jamais accepter l’algorithme none, car il contourne la vérification de la signature.

Les API, les services et les communications machine-to-machine nécessitent une vérification cryptographique de l’identité qui ne repose pas sur une interaction humaine.

Flux d’identifiants clients : le flux OAuth 2.0 pour les communications entre serveurs. Le service s’authentifie à l’aide de son client_id et de son client_secret (qui doivent être protégés en tant qu’identifiants sensibles et ne jamais être enregistrés dans le contrôle de version). Après avoir validé les identifiants, le serveur d’autorisation émet un token d’accès.

Paires de clés asymétriques : les services peuvent utiliser des paires de clés asymétriques pour authentifier les clients au moyen d’une assertion JWT signée (RFC 7523). Le serveur d’autorisation valide la signature à l’aide de la clé publique enregistrée, sans s’appuyer sur des secrets partagés.

Identité de la charge de travail : les plateformes cloud se portent garantes cryptographiquement des services en cours d’exécution, en émettant dynamiquement des identifiants à très courte durée de vie. Cela permet d’éliminer les secrets statiques à longue durée de vie.

Pour créer des applications sécurisées, il faut suivre les bonnes pratiques en matière d’identité moderne.

Considération de sécurité	Recommandation à l’intention des développeurs
Protection contre le phishing	Priorisez les passkeys FIDO2/WebAuthn par rapport à tous les autres facteurs (y compris les SMS et TOTP) afin d’assurer la meilleure défense possible contre le vol d’identifiants.
Sécurité des flux	Implémentez le flux de code d’autorisation avec PKCE pour tous les clients.
Durée de vie des tokens	Utilisez des tokens d’accès de courte durée (par exemple de 15 à 60 minutes) pour réduire la fenêtre d’attaque en cas de vol. Utilisez la rotation du token d’actualisation pour un renouvellement en douceur.
Stockage des tokens	Évitez de stocker des tokens sensibles (accès ou actualisation) dans localStorage ou sessionStorage, en raison des risques d’attaques XSS (Cross-Site Scripting). Pour les applications sur navigateur, préférez les cookies HttpOnly sécurisés pour les applications monopages, stockez les tokens uniquement dans la mémoire, et non dans localStorage ou sessionStorage. Les applications web traditionnelles doivent utiliser des sessions côté serveur avec des cookies HttpOnly sécurisés.
Validation des tokens API	Validez la signature JWT à chaque requête d’API protégée. Le fait d’ignorer cette vérification constitue une faille de sécurité critique.
Protection des identifiants	Appliquez de bonnes pratiques de sécurité en matière de mots de passe avec un hachage adaptatif (Argon2 ou bcrypt) et implémentez la limitation du débit pour vous protéger contre les attaques par force brute et credential stuffing. Utilisez la détection de mots de passe volés pour signaler automatiquement les identifiants compromis.

Quelle est la différence entre l’authentification et l’autorisation ?

L’authentification vérifie l’identité et répond à la question « Qui êtes-vous ? ». L’autorisation détermine l’accès et répond à la question « Que pouvez-vous faire ? ». L’authentification précède l’autorisation ; vous devez prouver votre identité avant que le système ne vérifie vos autorisations.

Pourquoi l’authentification par mot de passe uniquement n’est-elle plus sécurisée ?

Les mots de passe constituent la vulnérabilité de sécurité majeure d’un environnement. Ils sont très vulnérables aux attaques de phishing et de credential stuffing. La sécurité moderne exige l’ajout du MFA ou le passage à des méthodes sans mot de passe résistantes au phishing, comme les passkeys.

Quelle est la méthode d’authentification la plus sûre disponible aujourd’hui ?

Les passkeys FIDO2/WebAuthn sont actuellement les plus sûres. Elles utilisent la cryptographie à clé publique et sont liées à l’origine. L’identifiant ne fonctionne que pour un domaine spécifique, de sorte que les attaquants ne peuvent pas l’intercepter et le réutiliser.

Quel est le rôle d’OpenID Connect (OIDC) dans l’authentification ?

OIDC étend OAuth 2.0 avec la vérification d’identité. Il ajoute le token d’identification, un token Web JSON (JWT), qui fournit une preuve standardisée et vérifiable de l’identité de l’utilisateur. OAuth 2.0 ne peut pas faire cela à lui seul.

Quel est le principal risque de sécurité lié au vol d’un token d’accès JWT ?

Un token d’accès volé permet à un attaquant d’usurper l’identité de l’utilisateur jusqu’à ce qu’il expire. Les JWT étant sans état et difficiles à révoquer immédiatement, utilisez des tokens d’accès de très courte durée (15 à 60 minutes) et une rotation des tokens d’actualisation pour limiter les risques. La rotation permet de détecter immédiatement les vols, car le serveur invalide le token précédent après chaque utilisation.

Comment fonctionne l’authentification sans mot de passe ?

L’authentification sans mot de passe élimine la nécessité de mémoriser des secrets. En revanche, elle s’appuie sur des facteurs de possession (par exemple une passkey liée à l’appareil ou une clé physique) ou d’inhérence (par exemple la biométrie) pour vérifier en toute sécurité l’identité de l’utilisateur.

L’authentification est fondamentale pour la sécurité des applications, mais ce n’est que la première étape. Pour mettre en place un modèle de sécurité complet, il faut comprendre comment l’accès est contrôlé une fois l’identité confirmée. Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.