API, jetons et authentification

Les questions d'API et d'authentification portent sur l'ouverture d'une application à d'autres : des partenaires, une application mobile, un front Web. Elles demandent de choisir comment authentifier l'appelant (clé d'API, jeton, session), de protéger les échanges (HTTPS), de contrôler les droits dans l'API elle-même et de renvoyer le bon code de statut HTTP. Ce chapitre donne ces notions et les raisonnements attendus dans les sujets 2024 (GSIC), 2025 (Casterman, Kirassur).

Une API REST en quelques lignes

Une API REST expose des ressources (des contrats, des factures) à des adresses (/api/contrats/42) et s'utilise avec les méthodes du protocole HTTP. Chaque méthode a un rôle et un niveau de risque.

Les méthodes qui modifient ou suppriment sont les plus dangereuses pour l'intégrité : en 2025, le sujet Casterman faisait expliquer pourquoi DELETE et PUT exigent un contrôle d'autorisation, puis ajouter ce contrôle dans la méthode delete de l'API. La réponse est dans le corrigé du sujet Casterman.

Les codes de statut à connaître

Clé d'API, jeton, session : qui authentifie qui

Le sujet Kirassur combinait les deux premiers : la société partenaire s'authentifie avec sa clé d'API pour obtenir un jeton temporaire au nom d'un assuré, et l'assuré utilise ce jeton.

Pourquoi ne pas donner la clé d'API à l'assuré, même en HTTPS ? Parce que HTTPS protège le transport, pas ce que le destinataire fait de la clé. La clé est permanente et donne accès à toutes les interfaces du partenaire, pour tous ses clients : remise à un assuré, elle peut être copiée, publiée ou réutilisée pour consulter les contrats des autres. Le jeton applique le moindre privilège : un seul utilisateur, un seul périmètre, quelques minutes.

HTTPS : ce qu'il protège

En HTTP, les échanges circulent en clair : quiconque se place sur le chemin (Wi-Fi public, équipement compromis) peut les lire et les modifier. C'est une attaque de l'homme du milieu : vol de la clé d'API ou du jeton, puis usurpation de l'appelant. HTTPS ajoute la couche TLS, qui apporte trois garanties :

• la confidentialité : les échanges sont chiffrés ;
• l'intégrité : toute modification en transit est détectée ;
• l'authentification du serveur : son certificat, signé par une autorité de certification, prouve que tu parles bien au vrai serveur.

Utilise TLS 1.2 au minimum, TLS 1.3 de préférence ; les versions 1.0 et 1.1 sont abandonnées.

Transférer un fichier volumineux en sécurité

Transférer un fichier en sécurité, c'est garantir qu'il n'est lu que par son destinataire (confidentialité), qu'il arrive sans modification (intégrité) et qu'il vient bien de l'expéditeur (authenticité). Le sujet 2025 (cas Casterman, question B3.3) demandait une solution « sécurisée et adaptée à la taille des fichiers » pour envoyer à un imprimeur sous-traitant un PDF de 2 Go, trop lourd pour un courriel.

Réponse modèle :

« Un serveur SFTP hébergé par Casterman, avec un compte réservé à l'imprimeur, authentifié par clé et limité à un dossier de dépôt. Le transfert est chiffré par SSH, ce qui garantit la confidentialité, et la taille du fichier ne pose pas de problème. L'imprimeur vérifie ensuite la signature GPG du PDF avec la clé publique de l'éditeur : il s'assure ainsi que le fichier est intact et que c'est bien la version finale. »

Les jetons JWT

Un JWT (JSON Web Token) est un jeton en trois parties séparées par des points : un en-tête (l'algorithme de signature), une charge utile (les informations sur l'utilisateur et la date d'expiration exp) et une signature calculée avec une clé secrète du serveur.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJhc3N1cmUiLCJleHAiOjE4MDAwMDAwMDB9.<signature>
   en-tête (base64url)           charge utile (base64url)                              signature

Trois idées à retenir pour l'examen :

1. La charge utile n'est pas chiffrée, seulement encodée en base64url : n'importe qui peut la lire. On n'y met jamais de mot de passe ni de donnée sensible.
2. La signature garantit l'intégrité : si un utilisateur change "role":"assure" en "role":"admin", la signature ne correspond plus. À condition que le serveur vérifie la signature, avec un algorithme imposé, et refuse un jeton expiré.
3. Un jeton d'accès vit peu de temps (quelques minutes), un jeton de rafraîchissement plus longtemps : il sert à obtenir un nouveau jeton d'accès sans redemander le mot de passe. Une erreur invalid_token après une pause signale typiquement un jeton d'accès expiré : le client doit utiliser son jeton de rafraîchissement.

En Node.js, avec la bibliothèque jsonwebtoken :

// middleware Express : refuse toute requête sans jeton valide
const jwt = require('jsonwebtoken');

function exigerJeton(req, res, next) {
  const entete = req.headers.authorization ?? '';
  const jeton = entete.startsWith('Bearer ') ? entete.slice(7) : null;
  if (!jeton) return res.status(401).json({ erreur: 'Jeton manquant' });
  try {
    // verify contrôle la signature ET l'expiration ; decode ne contrôle rien
    req.utilisateur = jwt.verify(jeton, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    next();
  } catch {
    return res.status(401).json({ erreur: 'Jeton invalide ou expiré' });
  }
}

Authentification unique et multifacteur

L'authentification unique (SSO, single sign-on) permet de s'authentifier une fois auprès d'un fournisseur d'identité pour accéder à plusieurs applications. Le protocole le plus répandu est OpenID Connect, construit sur OAuth 2.0 : le fournisseur d'identité délivre un jeton d'identité (au format JWT) et un jeton d'accès. Le sujet 2024 (cas GSIC) portait sur sa mise en place.

Avantages pour la sécurité : un seul mot de passe à protéger, une politique de mots de passe centralisée, une désactivation immédiate de tous les accès au départ d'un salarié. Inconvénient : le compte SSO devient une cible de grande valeur, d'où l'authentification multifacteur (MFA), qui combine au moins deux facteurs de natures différentes :

• ce que l'on sait : un mot de passe, un code PIN ;
• ce que l'on possède : un téléphone qui génère un code temporaire, une clé de sécurité physique ;
• ce que l'on est : une empreinte digitale, la reconnaissance faciale.

Un mot de passe et une question secrète sont deux facteurs de la même nature : ce n'est pas du multifacteur. Les données biométriques servant à identifier une personne sont des données sensibles au sens de l'article 9 du RGPD, ce que le sujet 2024 faisait relever pour une authentification biométrique sur mobile.

Contrôler les droits dans l'API

L'authentification dit qui appelle ; l'autorisation dit ce qu'il a le droit de faire. Une API doit vérifier les deux elle-même, à chaque requête : une API est joignable sans passer par l'application qui l'utilise, avec Postman ou un simple curl.

Le sujet Kirassur montrait un journal de serveur Web où un partenaire, avec sa clé valide, consultait des contrats en incrémentant leur numéro. Les réponses attendues :

• le diagnostic : l'API vérifie la clé (authentification) mais pas que le contrat demandé appartient au partenaire (autorisation). C'est un contrôle d'accès défaillant ;
• la correction, sans coder : à chaque requête, vérifier que le contrat est rattaché au partenaire titulaire de la clé et renvoyer 403 sinon ; utiliser des identifiants non prévisibles (UUID) en défense complémentaire ; limiter le nombre de requêtes par clé ;
• la parade réseau : bloquer l'adresse IP sur le pare-feu, ou utiliser un outil qui bannit automatiquement une adresse au comportement anormal à partir des journaux (comme fail2ban), ou un pare-feu applicatif (WAF).

Une dernière idée, posée en 2025 (Casterman) : pour publier un catalogue en lecture, il vaut mieux créer une API publique séparée en lecture seule que d'ouvrir l'API authentifiée existante. Les routes de modification n'existent tout simplement pas dans l'API publique : la surface d'attaque est réduite, et une faille dans l'API publique ne permet aucune écriture.

Le cours Node.js et Express montre l'authentification par JWT et les middlewares de contrôle dans une application complète.

Pour aller plus loin. Le cours Authentification détaille les sessions et JWT, OAuth 2.0 et OpenID Connect et la MFA ; le chapitre Sécuriser une API REST du cours Sécurité applicative et le chapitre TLS 1.3 et HTTPS complètent ce chapitre.

Exercices