Ce guide détaille les meilleures pratiques pour gérer l’authentification dans une application Angular en s’appuyant sur des cookies HTTP-only et des tokens signés. Nous partirons des éléments du brouillon fourni et les organiserons de manière cohérente en abordant pourquoi éviter le LocalStorage pour les tokens, comment lire et vérifier une signature côté serveur, et comment sécuriser les échanges avec des headers Authorization de type Bearer selon les principes OAuth2. Le but est de donner une vision pragmatique et prête à l’emploi pour un développeur débutant autodidote.
Contexte et enjeux autour du stockage des tokens
Stocker le token dans le LocalStorage est une très mauvaise pratique. En effet, un JWT stocké dans le LocalStorage peut être modifié ou lu par du code JavaScript malveillant, ce qui fragilise gravement la sécurité de l’application. Par conséquent, la bonne méthode consiste à s’appuyer sur des cookies HTTP-only, qui ne sont pas lisibles par le navigateur via JavaScript et ne peuvent pas être facilement extraits par une injection XSS.
La lecture des informations et des droits associés à un token ne doit pas se faire côté client lorsque l’objectif est de protéger des ressources sensibles. Comme le montre le brouillon, la vérification de la signature avec la clé publique se fait côté serveur à chaque requête pour s’assurer que le token n’a pas été altéré. Le front-end peut toutefois bénéficier d’un mécanisme de vérification des droits via des appels authentifiés, sans exposer les secrets sur le client.
Approches recommandées pour l’authentification dans Angular
La méthode recommandée consiste à utiliser des en-têtes HTTP Authorization de type Bearer. Cf OAuth2. Le front-end envoie le token dans l’en-tête Authorization et le serveur valide la signature avec la clé publique avant d’accorder l’accès à la ressource protégée. Les cookies HTTP-only jouent alors le rôle de transporteur sécurisé du token sans être lisibles côté client.
Les cookies doivent être configurés avec les attributs appropriés pour combattre les vulnérabilités courantes telles que CSRF et XSS. En particulier, les cookies doivent être Secure, HttpOnly et SameSite (idéalement Strict ou Lax selon le flux). L’option withCredentials: true est nécessaire pour que les cookies soient envoyés et acceptés lors des requêtes cross-origin lorsque l’API et l’application front-end ne résident pas sur le même domaine.
Mise en œuvre Angular: flux sécurisé pas-à-pas
1) Backend génère le token et l’envoie au front-end via un cookie HTTP-only. Le serveur définit le cookie sur la réponse HTTP avec les attributs Secure, HttpOnly et SameSite adapté. Le front-end n’a pas accès au contenu du cookie mais bénéficie de son exposition automatique dans les en-têtes de requête.
2) Le front-end ne stocke pas le token dans le LocalStorage. Pour les appels API, il faut s’appuyer sur l’envoi automatique du cookie par le navigateur, tout en utilisant un en-tête Authorization Bearer pour les endpoints qui supportent cet usage selon le flux OAuth2.
3) Le front-end réalise des requêtes avec withCredentials: true lorsque le back-end se trouve sur un autre domaine (CORS). Cela permet au navigateur d’envoyer les cookies associés à la session et de recevoir les cookies de réponse sécurisés en retour.
Angular AuthGuard expliqué | Protégez vos routes en 7 minutes ! 🔐
Vérification côté serveur et sécurité des droits
La vérification de la signature du token et de ses droits se fait côté serveur à chaque requête utilisateur. Le serveur décode le JWT avec la clé publique, vérifie l’intégrité et lit les revendications (claims) pour déterminer les droits (par exemple admin). Si les droits ne permettent pas l’action demandée, le serveur renvoie une réponse 403 (Forbidden). Cela garantit que même si un utilisateur tente de manipuler le front-end, les vérifications critiques restent sur le serveur.
Le front-end peut effectuer une vérification superficielle pour améliorer l’expérience utilisateur (par exemple masquer des éléments UI basés sur les droits connus côté serveur), mais toute décision d’accès réel doit être validée par le back-end. Le brouillon indique clairement que le contrôle côté client ne sert à rien pour se protéger de l’utilisateur, et qu’une architecture sûre passe par le back-end.
Gestion des sessions et des tokens dans le front-end
Comme solution alternative ou complémentaire, certains projets utilisent le LocalStorage pour des données non sensibles ou des états UI, mais jamais pour des tokens d’authentification. Le brouillon mentionne également les risques liés au CSRF et l’intérêt des cookies SameSite-s pour limiter les attaques de type CSRF. Une approche robuste combine:
- Cookies HttpOnly pour les tokens d’accès et les tokens de refresh lorsque nécessaire, avec une rotation des tokens et une expiration appropriée.
- En-têtes Authorization Bearer pour les appels sensibles lorsque l’architecture le permet, en complément des cookies pour la session.
- WithCredentials pour les appels CORS afin d’assurer l’envoi des cookies entre origin différentes.
La bonne pratique est de minimiser l’exposition des tokens côté client et de confier la vérification d’intégrité et d’autorisations au serveur, tout en fournissant une expérience utilisateur fluide via des mécanismes de rafraîchissement des tokens et de gestion des sessions côté client.
Cas pratiques et conseils pour démarrer
- Évitez de stocker des tokens sensibles dans le LocalStorage ou le sessionStorage; privilégiez les cookies HttpOnly pour le transport des tokens.
- Utilisez l’authentification HTTP Bearer dans les appels API lorsque possible et combinez-la avec des cookies pour les sessions sécurisées.
- Configurez les cookies avec Secure, HttpOnly et SameSite adapté. Testez les scénarios CSRF et assurez-vous que l’architecture prévient ce type d’attaque.
- Implémentez une vérification côté serveur des signatures et des droits à chaque requête, et limitez les permissions accordées via les claims JWT.
Éléments techniques et considérations finales
La mise en œuvre d’un système d’authentification robuste dans Angular demande une compréhension des enjeux entre stockage local, sécurité des tokens et appels API. Le brouillon souligne l’importance d’un “header Authorization Bearer” Cf OAuth2 et rappelle que les vérifications critiques doivent être effectuées côté serveur. Les informations stockées du côté client doivent être non sensibles et ne pas permettre de contourner les contrôles d’accès.
Dans un projet réel, il est utile d’intégrer une approche de gestion des consentements et de conformité RGPD, surtout lorsque des cookies tiers ou premiers parties sont impliqués. L’usage de cookies pour le transport des tokens, associé à des mécanismes de rotation et de rafraîchissement, offre une solution équilibrée entre sécurité et expérience utilisateur.