Sur Internet, une question revient sans cesse : à qui ou à quoi avons-nous affaire ?

1. Identité, identification, authentification

Trois actes distincts, dans l’ordre où ils se présentent à un serveur :

1. L’identité est l’ensemble des informations qui distinguent une entité des autres. Pour un système, « c’est moi » ne suffit pas : il faut une représentation manipulable (un courriel, un matricule, un compte, une clé).
2. L’identification est l’acte par lequel une entité revendique une identité. Saisir alice@example.com ne prouve rien : cela annonce seulement l’identité prétendue.
3. L’authentification est la vérification de cette revendication : prouver que l’entité est bien celle qu’elle prétend être.

2. Le problème de la distance

En personne, la reconnaissance est organique : on cumule des indices (visage, voix, comportement habituel, contexte attendu) sans preuve unique. Sur Internet, cette reconnaissance riche est remplacée par des signaux techniques (identifiant, mot de passe, adresse, appareil, certificat, jeton), et la distance ouvre des risques :

• interception : un tiers écoute et lit ce qui passe ;
• usurpation : un tiers envoie des requêtes en se faisant passer pour un autre ;
• rejeu : un tiers capte une requête valide et la renvoie telle quelle ;
• intermédiaire : un tiers s’interpose, relaie et peut modifier les messages.

3. Une question de confiance

Le problème de la distance laisse un vide : si je ne peux pas vérifier moi-même une revendication, sur quoi m’appuyer ? La réponse habituelle est de déléguer la confiance à un tiers que je tiens déjà pour fiable, et qui se porte garant. La confiance devient alors transitive : je fais confiance à l’autorité, l’autorité atteste une revendication, donc j’étends une confiance conditionnelle à ce qu’elle atteste, sans l’avoir vérifié moi-même.

La création d’autorité. Une autorité est un tiers dont le rôle est de vérifier une fois et d’attester auprès de tous. Sa valeur tient à deux conditions : la rigueur de sa vérification avant d’attester, et le fait que toutes les parties s’accordent à lui faire confiance. Cette seconde condition est essentielle : une attestation ne vaut que si chacun reconnaît la même autorité comme point d’ancrage commun.

Les autorités de certification du web

Le cas le plus concret est celui de HTTPS. Une autorité de certification lie une clé publique à une identité, en pratique un nom de domaine, au moyen d’un certificat signé. Cette confiance s’organise en chaîne.

• La racine possède un certificat auto-signé, dont la clé publique est préinstallée dans le magasin de confiance du navigateur ou du système d’exploitation. C’est l’ancre : on lui fait confiance par défaut, parce que l’éditeur du navigateur l’a vérifiée et admise.
• La racine signe des autorités intermédiaires, qui signent à leur tour les certificats des sites. On garde ainsi la clé racine hors ligne et mieux protégée.
• Le certificat feuille est celui du serveur, présenté au navigateur à la connexion.

À la connexion, le navigateur valide la chaîne : il vérifie que chaque signature remonte jusqu’à une racine de confiance, contrôle les dates de validité, la correspondance du domaine et l’état de révocation. Cette vérification du domaine est reprise plus loin, à la section sur la sécurisation des échanges. Un point à ne pas confondre : l’autorité atteste le lien entre une clé et un domaine, pas l’honnêteté du site. Un site d’hameçonnage peut détenir un certificat parfaitement valide. HTTPS prouve « tu parles bien au domaine annoncé, de façon chiffrée », pas « ce domaine est digne de confiance ».

Le même schéma hors du web.

Le motif est récurrent : vérifier une fois, attester à plusieurs, pour éviter que chacun revérifie tout. Une institution éducative atteste une compétence par un diplôme, qu’un employeur accepte sans refaire passer les examens. Un ordre professionnel (l’Ordre des ingénieurs du Québec, le Collège des médecins, le Barreau) atteste le droit d’exercer et sert de garde-fou pour le public. Un passeport est l’attestation d’identité d’un État, reconnue par les autres.
Variante décentralisée : les systèmes de réputation (avis, notes, évaluations), où la confiance émerge de l’agrégation de nombreux témoignages plutôt que d’une institution unique.

4. L’authenticité d’une information

Une information est authentique quand on peut répondre à deux questions : d’où vient-elle (origine) et a-t-elle été altérée (intégrité) ? Cela diffère de la confidentialité (empêcher de lire) : un message peut être authentique sans être secret, et secret sans être authentique.

Le lien avec l’authentification est direct : authentifier une entité, c’est établir l’authenticité de sa revendication d’identité. La question « ce jeton a-t-il vraiment été émis par le serveur ? » ou « ce courriel vient-il vraiment de la banque ? » est une question d’authenticité.

5. Mécanismes et facteurs d’authentification

Prouver une identité repose sur un ou plusieurs facteurs :

L’authentification simple repose sur un seul facteur (le mot de passe). L’authentification multifacteur en combine au moins deux de natures différentes (mot de passe et code temporaire), pour que la compromission d’un seul élément ne suffise plus.

6. Le secret partagé

Le cas le plus répandu est le mot de passe : un secret connu du client et du serveur. Le serveur ne le conserve pas en clair ; il garde un condensat salé (le résultat d’une fonction de hachage lente appliquée au mot de passe combiné à une valeur aléatoire propre au compte). À la connexion, il recalcule le condensat et le compare. Ainsi, une fuite de la base de données ne livre pas les mots de passe.

import bcrypt from "bcrypt";

// à l'inscription : on ne garde que le condensat
const condensat = await bcrypt.hash(motDePasse, 12);

// à la connexion : on vérifie sans jamais stocker le secret en clair
const valide = await bcrypt.compare(motDePasseRecu, condensat);
if (!valide) return res.status(401).json({ erreur: "identifiants invalides" });

7. Authentification et autorisation

L’authentification répond à « qui es-tu ? ». L’autorisation répond à « qu’as-tu le droit de faire ? ». Les deux sont distinctes : être authentifié ne donne pas tous les droits.

Authentifié n’est pas autorisé

Une entité authentifiée n’accède qu’aux ressources permises par ses droits. La décision dépend de plusieurs éléments : le rôle de l’entité, le propriétaire de la ressource, l’état de la ressource, la date, le contexte de la requête.

Un étudiant peut modifier son propre rapport tant que la date limite n’est pas passée.

Cette règle combine l’identité (l’étudiant), la propriété (son rapport), l’état (avant la date limite) et l’action (modifier). La distinction se traduit dans deux codes de statut :

• 401 Unauthorized : aucune preuve d’identité valable, l’entité n’est pas authentifiée.
• 403 Forbidden : l’entité est authentifiée, mais non autorisée pour cette ressource.

Modèles d’autorisation

Il existe plusieurs manières d’organiser les droits.

Par rôle (RBAC, Role-Based Access Control). Les permissions sont attachées à des rôles (étudiant, correcteur, enseignant, admin), et une entité reçoit un ou plusieurs rôles. Ce modèle est simple à comprendre, mais il devient rigide lorsque les droits dépendent fortement du contexte.

Par attributs (ABAC, Attribute-Based Access Control). La décision dépend d’attributs de l’utilisateur, de la ressource, de l’action et du contexte. Ainsi « un correcteur peut évaluer une copie seulement si elle lui est assignée » : le rôle ne suffit pas, il faut l’attribut assignée à.

Par capacité. Posséder un jeton, un lien ou une clé transférable donne le droit d’agir : lien de réinitialisation, URL signée, invitation à un document. Ce modèle est commode, mais il exige de gérer la durée de vie, la portée, la révocation et le risque de partage accidentel.

L’autorisation déléguée : le flux OAuth

Souvent, une application doit accéder à une ressource détenue ailleurs, par exemple lire l’agenda Google d’un utilisateur. Sans mécanisme dédié, il faudrait confier son mot de passe Google à l’application, qui aurait alors accès à tout le compte. L’autorisation déléguée accorde un accès limité sans jamais transmettre le mot de passe à l’application.

Le flux ci-dessous (de type code d’autorisation) fait intervenir quatre acteurs : l’utilisateur, l’application, le fournisseur (Google) et l’API de ressource.

8. La continuité de l’identité

HTTP étant sans état, chaque requête arrive seule : le serveur ne se souvient pas de la précédente. Après l’authentification, il faut donc une représentation persistée que le client présente à chaque requête.

• Session côté serveur : le serveur garde l’état et ne remet qu’un identifiant de session opaque, dans un cookie HttpOnly.
• Jeton autoportant : l’état est encodé et signé dans un jeton que le client renvoie, souvent dans l’en-tête Authorization. Le serveur vérifie la signature sans garder d’état.

9. Synthèse : le cycle de connexion

L’identification, l’authentification, la création de session, l’autorisation et la traçabilité s’enchaînent. La séquence ci-dessous déroule une connexion puis une première requête authentifiée.

10. À retenir