00 - Authentification vs autorisation

Ce que tu vas apprendre

• La différence entre authentification et autorisation
• Pourquoi confondre les deux créé des failles de sécurité
• Ce que cette serie d'articles couvre

Prerequisites

Aucun. C'est le point de depart de la serie.

Le videur de boîte de nuit

La meilleure analogie que je connaisse pour expliquer la différence entre authentification et autorisation, c'est le videur devant une boîte de nuit.

Tu arrives a l'entree. Le videur te demande ta carte d'identité. Il regarde ta photo, il regarde ta tête, il vérifié que c'est bien toi. Ca, c'est l'authentification : prouver ton identité. "Qui es-tu ?"

Ensuite, il regarde sa liste. Est-ce que ton nom est sur la liste VIP ? Est-ce que tu as le bon bracelet ? Est-ce que tu as l'age requis ? Ca, c'est l'autorisation : vérifier ce que tu as le droit de faire. "Qu'est-ce que tu peux faire ici ?"

Deux questions différentes, deux mecanismes différents. Mais les juniors les melangent tout le temps.

Authentification : "Qui es-tu ?"

L'authentification, c'est le processus qui vérifié l'identité d'un utilisateur. En pratique, ca se traduit par :

• Un login + mot de passe (le plus courant)
• Une clé SSH (voir la serie clés et chiffrement)
• Un token OAuth2 (on en parlera dans l'article 03)
• Une empreinte biometrique sur ton telephone

Le serveur ne te fait pas confiance par défaut. Tu dois prouver que tu es bien celui que tu pretends etre.

Autorisation : "Qu'as-tu le droit de faire ?"

L'autorisation vient apres l'authentification. Tu as prouve qui tu es. Maintenant, le système vérifié tes permissions. Est-ce que tu peux lire cette page ? Modifier cet enregistrement ? Supprimer ce compte ?

Sur paltemps.fr, j'ai deux couches distinctes. L'authentification admin passe par un mot de passe (vérifié avec bcrypt). Mais meme si tu connais le mot de passe, tu ne peux pas te connecter si ton IP n'est pas dans la whitelist. Le mot de passe, c'est l'authentification. La whitelist IP, c'est l'autorisation.

typescript// Authentification : verifier le mot de passe
const isValid = await Bun.password.verify(password, hashedPassword);

// Autorisation : verifier l'IP
const ALLOWED_IPS = process.env.ADMIN_ALLOWED_IPS.split(",");
function isIpAllowed(ip: string): boolean {
  if (ALLOWED_IPS.length === 0) return true;
  return ALLOWED_IPS.includes(ip);
}

Pourquoi confondre les deux est dangereux

Je vois régulièrement ce genre de code en revue :

typescript// BAD : on melange tout
if (user.role === "admin") {
  // on autorise l'acces
}

Le problème ? On saute l'authentification. Comment sait-on que user est bien qui il pretend etre ? Comment est-il arrive la ? Si un attaquant peut forger un objet user avec role: "admin", c'est fini.

Un autre classique : un endpoint API qui vérifié que l'utilisateur est connecte (authentifié), mais pas qu'il a le droit d'acceder a cette ressource spécifique (autorise). Tu es connecte en tant que User #42, tu changes l'URL pour voir les donnees de User #43, et ca marche. C'est un problème d'autorisation, pas d'authentification.

HTTP 401 vs 403

Le protocole HTTP a deux codes d'erreur pour ca, et leurs noms sont trompeurs :

401 Unauthorized : en réalité, ca veut dire "non authentifié". Tu n'as pas prouve ton identité. Le header WWW-Authenticate dans la réponse t'indique comment t'authentifier. Le nom "Unauthorized" est un mensonge historique.

403 Forbidden : ca veut dire "authentifié mais pas autorise". Le serveur sait qui tu es, mais tu n'as pas le droit d'acceder a cette ressource. Reenvoyer tes identifiants ne changera rien.

Comme le dit la RFC 7235 : 401 = "qui es-tu ?", 403 = "je sais qui tu es, et tu n'as pas le droit".

Ce que cette serie couvre

J'ai organise cette serie en 9 articles :

1. Cette introduction : tu y es
2. Sessions et cookies : le modèle classique, et pourquoi il marche toujours
3. JWT : comment ca marche et quand l'utiliser (spoiler : moins souvent que tu crois)
4. OAuth2 : les flows sans jargon
5. Refresh tokens : garder l'utilisateur connecte
6. Hashing de mots de passe : bcrypt, argon2, et pourquoi pas SHA-256
7. RBAC : rôles, permissions et middleware
8. XSS, CSRF, injection : les failles classiques
9. Glossaire : tous les termes au meme endroit

Chaque article contient du vrai code TypeScript, tire de projets réels. Pour les secrets et la gestion des clés, consulte aussi la serie secrets et variables d'environnement.

Prochain article : Sessions et cookies : le modèle classique.

Navigation : Introduction | Suivant : 01 - Sessions et cookies

Sources

• RFC 7235 - HTTP/1.1 Authentication par IETF
• Authentication vs. Authorization par Auth0
• OWASP Authentication Cheat Sheet par OWASP

Retrouve d'autres articles techniques sur paltemps.fr.