Authentification
Authentification vs Autorisation
- Authentification — qui es-tu ? Vérifie l’identité.
- Autorisation — qu’as-tu le droit de faire ? Vérifie les permissions.
Les deux sont indépendants : être authentifié ne suffit pas pour accéder à une ressource.
Exemple : tu peux te connecter à une application (authentifié) sans pour autant avoir accès à l’espace admin (non autorisé).
Facteurs d’authentification
| Facteur | Type | Exemples | Forces / Faiblesses |
|---|---|---|---|
| Connaissance | Ce que tu sais | Mot de passe, PIN, question secrète | Facile à déployer, mais volable par phishing ou leak |
| Possession | Ce que tu as | Téléphone (TOTP/SMS), clé FIDO2, carte à puce | Résistant au phishing si hardware (FIDO2), SMS interceptable (SIM swap) |
| Inhérence | Ce que tu es | Empreinte digitale, FaceID, voix | Non révocable si compromis, dépend du hardware |
OTP : TOTP vs SMS
- TOTP (ex. Google Authenticator) — code généré sur ton appareil, jamais transmis. Plus sûr.
- SMS OTP — le code passe par le réseau téléphonique. Vulnérable au SIM swapping : un attaquant convainc l’opérateur de transférer ton numéro sur sa propre carte SIM, et reçoit tes SMS à ta place.
MFA : ce qui compte vraiment
MFA = combiner ≥ 2 facteurs de catégories différentes.
- ✅ Mot de passe + TOTP → Connaissance + Possession
- ✅ Mot de passe + FIDO2 → Connaissance + Possession (hardware)
- ❌ Mot de passe + question secrète → Connaissance + Connaissance (= pas du MFA)
- ⚠️ Mot de passe + SMS → MFA, mais le maillon SMS est faible
Résistance au phishing
La plupart des MFA restent vulnérables au phishing en temps réel : l’attaquant crée une fausse page de login, relaie tes identifiants et ton code OTP au vrai site dans la foulée. Seul FIDO2/WebAuthn est résistant par design : le challenge est lié au domaine exact, une fausse page ne peut pas l’exploiter.
Sessions
Après l’authentification, le serveur doit se souvenir que tu es connecté. Il existe deux grandes approches.
Stateful
Le serveur crée un identifiant de session et te le donne sous forme de cookie. À chaque requête, tu renvoies ce cookie, le serveur retrouve ta session.
- Avantage : la session peut être révoquée immédiatement (déconnexion forcée, suspicion de compromission).
- Inconvénient : le serveur doit stocker l’état de chaque utilisateur connecté — complexe à scaler sur plusieurs machines.
Stateless
À la place d’un identifiant, le serveur te donne un token signé qui contient directement tes informations (identité, expiration). Le serveur n’a rien à stocker : il vérifie juste la signature.
- Avantage : fonctionne facilement sur plusieurs serveurs ou services différents.
- Inconvénient : difficile à révoquer avant expiration. Sans mécanique spécifique, un token volé reste valide jusqu’à son expiration.
Bonne pratique : durée de vie courte (15 min) pour le token principal, complété par un refresh token à plus longue durée pour en obtenir un nouveau sans se reconnecter.
OAuth 2.0 & OpenID Connect (OIDC)
Ces protocoles permettent à une application de déléguer l’authentification à un service tiers (Google, GitHub, votre SSO d’entreprise).
Les acteurs
| Terme | Rôle | Exemple concret |
|---|---|---|
| Resource Owner | L’utilisateur | Toi |
| Client | L’application | Une app qui délègue l’authentification |
| Authorization Server | Le service qui authentifie | Un fournisseur d’identité (IdP) |
| Resource Server | L’API protégée | L’API de ton app |
Le flux standard (Authorization Code)
- L’app te redirige vers le fournisseur d’identité pour te connecter.
- Tu t’authentifies chez le fournisseur et donnes ton consentement.
- Le fournisseur renvoie un code temporaire à l’app.
- L’app échange ce code contre des tokens, côté serveur.
L’utilisateur ne touche jamais directement les tokens — c’est l’app qui les récupère en backend.
OIDC est une couche au-dessus d’OAuth 2.0 qui ajoute un token d’identité : l’app sait non seulement que tu es autorisé, mais aussi qui tu es.
Ce qu’il ne faut pas faire
- Implicit flow — les tokens apparaissaient directement dans l’URL du navigateur. Déprécié.
- Password Grant — l’app collecte elle-même ton mot de passe au lieu de déléguer. À éviter : l’app ne devrait jamais voir tes credentials.
Attaques communes
| Attaque | Ce qui se passe | Comment s’en protéger |
|---|---|---|
| Brute force | L’attaquant essaie des milliers de mots de passe en automatique | Limiter le nombre de tentatives, ajouter un délai |
| Credential stuffing | Il réutilise des credentials volés sur d’autres sites | MFA, détection de connexions inhabituelles |
| Phishing | Fausse page de login pour voler tes identifiants | FIDO2/passkeys, sensibilisation |
| Session hijacking | Vol du cookie de session (via XSS ou réseau non sécurisé) | HTTPS, cookies bien configurés, rotation de session |
| CSRF | Forcer ton navigateur à effectuer une action à ton insu sur un site où tu es connecté | Cookies SameSite, tokens anti-CSRF |
Passkeys (FIDO2 / WebAuthn)
Les passkeys remplacent le mot de passe par de la cryptographie asymétrique :
- Lors de l’inscription, ton appareil génère une paire de clés : la clé publique est envoyée au site, la clé privée reste sur ton appareil.
- Lors de la connexion, le site envoie un défi aléatoire que ton appareil signe avec ta clé privée. Le site vérifie avec ta clé publique.
- Ta clé privée ne quitte jamais ton appareil — rien à voler côté serveur.
- La liaison au domaine rend le phishing impossible : une fausse page ne peut pas déclencher l’authentification.
Support natif sur iOS, Android, Windows et macOS.