Je me souviens avoir regardé la page de connexion d'un grand projet il y a un an et m'être dit : « Mon Dieu, comment tout cela fonctionne-t-il ? » Quatre boutons pour entrer, des jetons, des redirections... Ça donne le tournis. Aujourd'hui, nous allons tout mettre en ordre pour que vous ne vous noyiez pas dans cette mer de technologies.
Pourquoi l'autorisation n'est pas seulement « entrer un mot de passe » 🔐
En 2026, les utilisateurs veulent se connecter aux applications rapidement, en toute sécurité et sans maux de tête. Certains préfèrent l'e-mail et le mot de passe classiques, d'autres préfèrent un seul bouton « Connexion via Google », d'autres encore veulent recevoir un code par SMS et ne pas avoir à se soucier des mots de passe.
Votre tâche en tant que développeur est de leur donner tout cela, et de manière à ce que le système soit sûr et ne se transforme pas en code spaghetti 🍝
Commençons par la base que chaque junior doit comprendre, puis nous irons plus loin.
E-mail/mot de passe : la vieille école qui n'a pas disparu ✉️
L'autorisation classique par e-mail et mot de passe est la base. Oui, beaucoup de gens disent qu'elle est dépassée, mais la vérité est qu'elle est encore utilisée par des millions de services. Et il est essentiel de savoir comment cela fonctionne correctement.
Que se passe-t-il lors de l'inscription
L'utilisateur saisit une adresse e-mail et un mot de passe. Votre première tâche est la validation. L'e-mail doit être réel (au moins syntaxiquement correct) et le mot de passe doit être suffisamment complexe.
En 2026, le minimum est de 8 caractères, lettres de casse différente, chiffres, caractères spéciaux. Mais les exigences dépendent du projet, vous n'avez pas besoin d'un « mot de passe comme un coffre-fort de banque » partout.
Ensuite, le plus important : jamais, tu entends, JAMAIS ne stocke pas les mots de passe en texte clair. Vous devez hacher le mot de passe avant de l'enregistrer dans la base de données. En 2026, la norme est bcrypt ou Argon2.
// Exemple avec bcrypt (Node.js)
const bcrypt = require('bcrypt');
// Lors de l'inscription
const saltRounds = 10;
const hashedPassword = await bcrypt.hash(userPassword, saltRounds);
// Enregistrer hashedPassword dans la base de données
// À l'entrée
const isValid = await bcrypt.compare(userPassword, hashedPasswordFromDB);
if (isValid) {
// Utilisateur autorisé
}Que se passe-t-il lors de la connexion
L'utilisateur saisit une adresse e-mail et un mot de passe. Vous recherchez cet e-mail dans la base de données, obtenez le hachage du mot de passe et le comparez avec le mot de passe saisi via bcrypt.compare. Si cela correspond, générez un jeton (généralement JWT) et donnez-le au client.
JWT est votre nouveau meilleur ami 🤝
JSON Web Token est une chaîne qui contient des informations cryptées sur l'utilisateur. Après une autorisation réussie, vous créez un JWT avec les données de l'utilisateur (id, email, rôle) et l'envoyez au client. Le client enregistre le jeton et l'envoie à chaque requête à l'API.
const jwt = require('jsonwebtoken');
// Création d'un jeton
const token = jwt.sign(
{ userId: user.id, email: user.email },
process.env.JWT_SECRET,
{ expiresIn: '7d' }
);
// Vérification du jeton
const decoded = jwt.verify(token, process.env.JWT_SECRET);Actualiser les jetons : lorsque le jeton d'accès est périmé 🧊
Le jeton d'accès ne dure généralement pas longtemps, de 15 minutes à plusieurs heures. Lorsqu'il expire, l'utilisateur n'a pas à saisir à nouveau le mot de passe. Pour cela, on utilise un refresh token, un jeton à longue durée de vie qui est stocké dans un endroit sûr (généralement httpOnly cookie) et est utilisé pour obtenir un nouveau access token.
La logique est simple : jeton court pour le travail, jeton long pour mettre à jour le court. Tu rencontreras ce modèle dans la plupart des projets réels.
OAuth 2.0 : « Se connecter avec Google » et toute cette magie ✨
Lorsqu'un utilisateur clique sur « Se connecter avec Google » ou « Se connecter avec Apple », une danse OAuth 2.0 se déroule en coulisses. Il s'agit d'une norme qui permet aux services tiers d'autoriser les utilisateurs sans transmettre de mot de passe.
Comment cela fonctionne en quelques mots
L'utilisateur clique sur « Se connecter avec Google »
Vous le redirigez vers la page Google
L'utilisateur se connecte et donne son autorisation
Google redirige vers votre site avec un temporaire code
Tu changes code sur le jeton et obtenir les données de l'utilisateur
Ce que les juniors doivent savoir
Vous devez enregistrer l'application dans la console (Google/Apple) et obtenir Client ID et Client Secret.
Le scénario le plus populaire est Authorization Code Flow.
Ne perdez pas l'état entre les redirections — utilisez le paramètre
state(protection contre le CSRF).Client Secret ne doit jamais arriver au frontend.
// Exemple avec Passport.js (Node.js)
const passport = require('passport');
const GoogleStrategy = require('passport-google-oauth20').Strategy;
passport.use(new GoogleStrategy({
clientID: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_CLIENT_SECRET,
callbackURL: "http://localhost:3000/auth/google/callback"
},
async (accessToken, refreshToken, profile, done) => {
// Ici, vous obtenez les données de l'utilisateur
// Vous le recherchez dans votre base de données ou vous en créez un nouveau
const user = await findOrCreateUser(profile);
return done(null, user);
}
));Apple Sign In : caractéristiques 🍏
Apple prend la confidentialité au sérieux. Ils peuvent masquer le véritable e-mail de l'utilisateur et donner un e-mail proxy de type randomstring@privaterelay.appleid.com. De plus, ils ont leur propre spécificité avec la génération de client_secret : il est créé par logiciel, et pas simplement émis dans la console.
Les principaux problèmes : redirect_uri incorrect (doit correspondre à 1 sur 1), absence de state, « user cancelled » non traité et fuite de Client Secret vers le front.
OTP : mots de passe à usage unique et codes SMS 📲
One-Time Password est un code qui ne dure que quelques minutes et qui n'est utilisé qu'une seule fois. En 2026, c'est l'une des méthodes d'autorisation les plus populaires, en particulier dans les applications mobiles.
Comment ça marche
L'utilisateur saisit le numéro de téléphone
Vous générez un code (4-6 chiffres), enregistrez avec TTL (souvent dans Redis)
Vous envoyez le code via une passerelle SMS
L'utilisateur saisit le code → vous vérifiez → vous créez une session
// Génération d'OTP
function generateOTP(length = 6) {
const digits = '0123456789';
let otp = '';
for (let i = 0; i < length; i++) {
otp += digits[Math.floor(Math.random() * 10)];
}
return otp;
}
// Sauvegarde avec TTL (Redis)
await redis.setex(`otp:${phoneNumber}`, 300, otp); // 5 minutes
// Envoi de SMS
await smsService.send(phoneNumber, `Your code: ${otp}`);
// Vérification
const storedOTP = await redis.get(`otp:${phoneNumber}`);
if (storedOTP === userInputOTP) {
// Autorisation réussie
await redis.del(`otp:${phoneNumber}`);
}TOTP : quand le SMS n'est pas une option ⏱️
Time-based One-Time Password : codes générés par des applications telles que Google Authenticator ou Authy. Fonctionne sur la base d'une clé secrète et de l'heure. Une excellente option pour la 2FA.
const speakeasy = require('speakeasy');
// Génération de secret
const secret = speakeasy.generateSecret({ name: 'MyApp (user@email.com)' });
// secret.base32 — c'est ce qui doit être enregistré dans la base de données
// Vérification du code
const verified = speakeasy.totp.verify({
secret: secret.base32,
encoding: 'base32',
token: userInputCode,
window: 2 // tolérance de désynchronisation de l'heure
});Sécurité OTP
Limitez le nombre de tentatives de saisie (généralement 3 à 5)
Utilisez la limitation de débit (pas plus de N SMS par numéro par heure)
Faites des codes assez longs (au moins 6 chiffres)
Assurez-vous de mettre TTL (5–10 minutes)
L'illustration « carte d'autorisation » fonctionnera bien ici, pour tout rassembler visuellement en une seule image : e-mail/mot de passe → JWT → refresh → OAuth → OTP.
Ce que le junior doit savoir : liste de contrôle pour l'entretien 🧠
Les choses de base
Différence entre authentification et autorisation
Qu'est-ce que JWT et de quelles parties se compose-t-il (Header, Payload, Signature)
Pourquoi ne pas stocker les mots de passe en texte clair
Qu'est-ce que le sel dans le hachage de mot de passe
Niveau moyen
Access token vs refresh token
Comment OAuth 2.0 fonctionne à un niveau élevé
Qu'est-ce que le CSRF et la protection via state/token/origin
Où stocker les jetons sur le front et pourquoi (httpOnly cookies / memory / localStorage)
Niveau avancé
Déconnexion avec JWT (liste noire dans Redis ou TTL court)
PKCE dans OAuth et pourquoi il est nécessaire
Protection contre les attaques par force brute avec OTP (limitation de débit, backoff, captcha)
En 2026, ce n'est plus sorcier 🚀
Il y a encore 5 à 10 ans, OAuth semblait inaccessible. Maintenant, c'est une norme intégrée dans tous les frameworks normaux. Les bibliothèques font 80 % du travail, et vous devez comprendre les concepts et être capable de tout assembler correctement.
Commencez par la base : e-mail/mot de passe et JWT. Ensuite, ajoutez OAuth. Et si nécessaire, OTP pour plus de commodité ou de sécurité. Rappelez-vous toujours du minimum : hachez les mots de passe, vérifiez les jetons, limitez les tentatives de connexion, utilisez HTTPS.
Tout cela et bien plus encore peut être étudié dans le Codex 🎓
Si, après avoir lu cet article, vous avez des questions (et elles sont certainement apparues, l'autorisation est un sujet profond), venez à Code.
Kodik — apprentissage de la programmation avec un accent sur la pratique : nous analysons les sujets en détail, avec des exemples de code en direct et des explications sur les pièges. Pas de « voici le code, copiez-le », mais une compréhension de comment et pourquoi tout fonctionne.
Tâches pratiques : vous collecterez l'autorisation à partir de zéro - de l'e-mail / mot de passe à OAuth et 2FA
Renforcement des compétences par des exercices et des mini-projets
Analyse des erreurs et des modèles typiques à partir d'applications réelles
Besoin d'aide ? Il y a une communauté 👥
Chez nous canal Telegram actif, où plus de 2000 développeurs sont assis. Vous pouvez poser une question, discuter d'un problème, demander une révision de code ou simplement discuter avec des personnes qui suivent le même parcours.
Rejoignez Kodik — nous allons analyser l'autorisation de manière à ce que vous puissiez l'expliquer aux autres les yeux fermés 😉