Quatorze mois : c’est la durée de validité restante découverte sur le jeton d’authentification d’un ancien élève, alors que sa formation s’était terminée depuis plus d’un an. L’établissement, une école proposant des cursus à distance couplés à un service e-learning tiers intégré à son site WordPress, ne s’en est rendu compte qu’en préparant un audit de sécurité annuel, en tombant sur un compte censé être clôturé qui répondait toujours aux appels API.
L’intégration reliait WordPress au service e-learning via un jeton d’API généré à l’inscription de chaque élève, stocké en métadonnée utilisateur et utilisé pour authentifier les appels vers les ressources pédagogiques protégées (cours, évaluations, attestations). Ce jeton n’avait, à l’origine, aucune date d’expiration configurée.
Symptôme : un compte qui répond alors qu’il ne devrait plus exister
L’audit a consisté à interroger l’API du service e-learning avec les jetons stockés pour un échantillon d’anciens élèves ayant terminé leur cursus depuis plus de six mois. Plusieurs de ces jetons répondaient encore normalement, donnant accès aux mêmes ressources qu’un élève actif : contenus de cours, résultats d’évaluation, et dans certains cas la génération de nouvelles attestations au nom de l’ancien élève.
Rien dans les journaux applicatifs ne signalait cette situation comme anormale : du point de vue du service e-learning, le jeton était simplement valide, exactement comme il l’était le premier jour de la formation. Aucune alerte automatique ne pouvait donc détecter le problème sans une vérification active et volontaire.
Diagnostic : l’expiration absente du cycle de vie
Le jeton avait été généré une seule fois, au moment de l’inscription, avec une durée de vie fixée par défaut par le service tiers à des valeurs très longues, pensées pour des cas d’usage professionnels où l’accès doit rester stable sur plusieurs années. Rien dans l’intégration WordPress ne reliait la fin d’un cursus, marquée par un changement de statut dans un champ personnalisé, à une action de révocation de ce jeton.
Autrement dit, deux événements métier auraient dû être liés et ne l’étaient pas : la fin de la formation d’un côté, l’expiration ou la révocation de l’accès de l’autre. Le système traitait ces deux informations comme indépendantes, alors qu’elles décrivent en réalité la même réalité vue sous deux angles différents.
Correctif : révoquer sur événement, pas seulement sur date
La correction a introduit un hook déclenché au changement de statut de l’élève, qui révoque immédiatement le jeton auprès du service e-learning dès que le cursus est marqué comme terminé, sans attendre une éventuelle expiration naturelle :
add_action('eleve_statut_change', function ($user_id, $nouveau_statut) {
if ($nouveau_statut === 'cursus_termine') {
$jeton = get_user_meta($user_id, 'elearning_token', true);
if ($jeton) {
wp_remote_post('https://api.elearning-partenaire.example/revoke', [
'headers' => ['Authorization' => 'Bearer ' . $jeton],
'body' => ['action' => 'revoke_immediately'],
]);
delete_user_meta($user_id, 'elearning_token');
}
}
}, 10, 2);En complément, une tâche planifiée hebdomadaire via wp_schedule_event vérifie systématiquement les jetons restants associés à des comptes inactifs depuis plus de trente jours, en filet de sécurité pour les cas où le hook métier n’aurait pas déclenché correctement, par exemple lors d’un import massif de statuts.
Prévention : aligner la durée de vie sur le cycle réel
Au-delà de ce correctif ponctuel, l’établissement a revu sa politique pour tout futur service tiers intégré : la durée de validité d’un jeton d’accès doit désormais être choisie en fonction du cycle métier réel de son utilisation, et non de la valeur par défaut proposée par le prestataire. Pour un cursus d’une durée déterminée, un jeton dont la validité dépasse largement cette durée constitue un risque résiduel qui n’a aucune justification fonctionnelle.
En résumé
Un jeton d’authentification qui survit à la relation qu’il était censé sécuriser n’est jamais un détail technique mineur : c’est un accès qui continue d’exister sans que personne ne le surveille activement. Relier chaque émission de jeton à un événement de révocation symétrique, plutôt que de compter sur une expiration par défaut, ferme cette fenêtre d’accès résiduel avant qu’un audit ou, pire, un incident ne la révèle.
