Introduction : pourquoi votre mot de passe n'est pas qu'une simple chaîne
\n\nImaginez : vous avez développé une super application Java pour une bibliothèque en ligne. Les utilisateurs s'inscrivent, sauvegardent des marque-pages, écrivent des critiques. Et soudain — fuite de la base de données. Tous les mots de passe en clair. Catastrophe ? Et comment ! En 2024, les fuites de données se produisent toutes les 39 secondes, et 81 % d'entre elles sont liées à une authentification faible. Si vous codez en Java et souhaitez que votre projet n'atterrisse pas dans les actualités cybernétiques — cet article est pour vous.
\n\nNous allons décortiquer l'authentification sécurisée dans les applications Java de A à Z : du hachage des mots de passe au JWT et à la protection CSRF. Pas de théorie ennuyeuse, seulement du code fonctionnel et des pratiques réelles. C'est parti !
\n\n1. Hachage des mots de passe : première ligne de défense
\n\nPremière règle de sécurité : ne stockez jamais les mots de passe en clair. Même si votre base de données est le Saint Graal, le chiffrement des mots de passe est un minimum obligatoire. En Java, on utilise des algorithmes comme bcrypt, scrypt ou Argon2. Pourquoi pas MD5 ou SHA ? Parce qu'ils sont trop rapides — un attaquant trouvera le mot de passe en quelques secondes.
\n\nPratique : bcrypt en action
\nAjoutez la dépendance dans pom.xml (Maven) :
<dependency>\n <groupId>org.springframework.security</groupId>\n <artifactId>spring-security-crypto</artifactId>\n <version>6.2.0</version>\n</dependency>\n\n\nMaintenant, hachons le mot de passe lors de l'inscription :
\nimport org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;\n\npublic class PasswordService {\n private final BCryptPasswordEncoder encoder = new BCryptPasswordEncoder();\n\n public String hashPassword(String rawPassword) {\n return encoder.encode(rawPassword); // génère un sel automatiquement\n }\n\n public boolean checkPassword(String rawPassword, String storedHash) {\n return encoder.matches(rawPassword, storedHash);\n }\n}\n\n\nImportant : bcrypt ajoute lui-même un sel aléatoire, donc même des mots de passe identiques auront une apparence différente. Le facteur de coût (cost factor) par défaut est de 10, mais pour les systèmes critiques, on peut le monter à 12-14.
\n\n2. JWT (JSON Web Tokens) : session légère et sécurisée
\n\nAprès l'inscription, l'utilisateur doit pouvoir prouver son identité. Des cookies ? Possible, mais JWT est la norme moderne pour les API REST. Le jeton contient des informations sur l'utilisateur et est signé avec une clé secrète. Pas de sessions côté serveur — tout est dans le jeton.
\n\nCréation d'un JWT en Java
\nAjoutez la bibliothèque io.jsonwebtoken:jjwt :
<dependency>\n <groupId>io.jsonwebtoken</groupId>\n <artifactId>jjwt-api</artifactId>\n <version>0.12.3</version>\n</dependency>\n\n\nGénération du jeton :
\nimport io.jsonwebtoken.Jwts;\nimport io.jsonwebtoken.security.Keys;\nimport javax.crypto.SecretKey;\nimport java.util.Date;\n\npublic class JwtUtil {\n private final SecretKey key = Keys.hmacShaKeyFor("clé_secrète_d'au_moins_256_bits".getBytes());\n\n public String generateToken(String username) {\n return Jwts.builder()\n .subject(username)\n .issuedAt(new Date())\n .expiration(new Date(System.currentTimeMillis() + 3600000)) // 1 heure\n .signWith(key)\n .compact();\n }\n\n public String extractUsername(String token) {\n return Jwts.parser()\n .verifyWith(key)\n .build()\n .parseSignedClaims(token)\n .getPayload()\n .getSubject();\n }\n}\n\n\nConseil : ne stockez pas la clé secrète dans le code ! Utilisez des variables d'environnement ou Vault. Et ne mettez jamais de données confidentielles (mots de passe, numéros de carte) dans le JWT — le jeton peut être décodé sans la signature.
\n\n