Guide des mécanismes d’authentification dans les applications Web modernes
Ce document présente les mécanismes d’authentification utilisés dans les applications web modernes, leurs avantages, inconvénients, domaines d’usage, ainsi que les bonnes pratiques de sécurité issues des recommandations de l’OWASP et des standards actuels.
1. Qu’est-ce que l’OWASP ?
Présentation
OWASP (Open Worldwide Application Security Project) est une organisation internationale à but non lucratif dédiée à l’amélioration de la sécurité des applications web et logicielles.
Elle fournit :
- des guides de bonnes pratiques,
- des standards de sécurité,
- des outils open source,
- des référentiels reconnus mondialement.
L’OWASP est indépendante des éditeurs et des technologies, ce qui rend ses recommandations largement adoptées dans l’industrie.
OWASP Top 10
Le document le plus connu est le OWASP Top 10, qui recense les dix catégories de vulnérabilités les plus critiques. Plusieurs concernent directement l’authentification et la gestion des identités, notamment :
- Authentification défaillante,
- Mauvaise gestion des sessions,
- Contrôles d’accès cassés,
- Exposition de données sensibles.
Principe fondamental OWASP
Le client (navigateur, SPA, application mobile) ne doit jamais être considéré comme fiable.
Toute logique de sécurité doit être implémentée et validée côté serveur.
2. Concepts fondamentaux
Authentification vs autorisation
- L’authentification consiste à vérifier l’identité d’un utilisateur ou d’un système.
- L’autorisation consiste à vérifier ce que cet utilisateur ou système est autorisé à faire.
Une application sécurisée doit traiter ces deux notions séparément.
3. Authentification par session et cookies (Web traditionnel)
Principe
Après la saisie d’un identifiant et d’un mot de passe, le serveur crée une session et transmet un identifiant de session au navigateur via un cookie HTTP.
Le navigateur renvoie automatiquement ce cookie à chaque requête suivante.
Avantages
- Mécanisme simple et éprouvé,
- Excellente intégration avec les navigateurs,
- Contrôle total côté serveur,
- Facile à mettre en œuvre dans les applications web traditionnelles.
Inconvénients
- Peu adapté aux API REST,
- Scalabilité plus complexe en environnement distribué,
- Fortement couplé au navigateur.
Sécurité (OWASP)
- Protection contre les attaques CSRF obligatoire,
- Cookies configurés avec
HttpOnly,SecureetSameSite, - Invalidation systématique des sessions à la déconnexion.
4. Authentification HTTP Basic
Principe
Les identifiants sont envoyés à chaque requête HTTP via l’en-tête Authorization, encodés en Base64.
Avantages
- Très simple à implémenter,
- Supporté nativement par HTTP,
- Utile pour des tests ou des usages temporaires.
Inconvénients
- Aucun mécanisme de session,
- Le mot de passe est transmis à chaque requête,
- Sécurité entièrement dépendante de HTTPS.
Recommandation
Cette méthode est déconseillée en production pour des utilisateurs finaux.
5. JWT (JSON Web Token)
Principe
Le serveur délivre un token signé contenant des informations appelées claims.
Le token est auto-contenu et peut être vérifié sans accès à une base de données.
Avantages
- Stateless,
- Très scalable,
- Compatible avec SPA, applications mobiles et microservices,
- Standard largement adopté.
Inconvénients
- Révocation complexe,
- Risques importants en cas de mauvaise implémentation,
- Sécurité fortement dépendante du mode de stockage côté client.
Recommandations OWASP
- Ne jamais stocker un JWT dans
localStorage, - Préférer les cookies
HttpOnlycôté navigateur, - Utiliser des tokens de courte durée,
- Mettre en place des refresh tokens,
- Ne jamais stocker de données sensibles dans le token.
6. Authentification par token opaque
Principe
Le serveur génère un token aléatoire sans signification intrinsèque.
Ce token est stocké côté serveur et vérifié à chaque requête.
Avantages
- Révocation simple,
- Aucune donnée exposée côté client,
- Plus sûr que les JWT dans certains contextes.
Inconvénients
- Vérification serveur nécessaire à chaque requête,
- Moins performant que les JWT à très grande échelle.
7. Cas d’usage : authentification dans une SPA (frontend)
Problématique
Une application frontend (React, Vue, Angular, etc.) ne peut pas protéger un secret.
Tout code exécuté côté client est potentiellement accessible ou modifiable.
Bonnes pratiques
- Authentification réalisée via une API backend,
- Stockage du token :
- Cookie
HttpOnly(recommandé), - Mémoire volatile (state JavaScript),
- Cookie
- Protection contre les attaques XSS, CSRF et le rejeu de tokens.