Se reconnecter avec identifiant et mot de passe à chaque requête serait à la fois pénible et risqué : plus une information sensible circule, plus elle a de chances d’être interceptée. Le jeton d’accès règle ce problème : après une authentification initiale réussie, le serveur délivre une chaîne opaque, généralement limitée dans le temps, que l’application présente ensuite dans l’en-tête Authorization de chaque requête suivante.
Jetons d’accès et WordPress
L’API REST native de WordPress s’appuie par défaut sur les cookies de session d’un utilisateur déjà connecté à l’administration, mais pour un usage externe (une application mobile, un script tiers), il faut un jeton d’accès distinct. C’est le rôle d’extensions comme JWT Authentication ou Application Passwords (fonctionnalité native depuis WordPress 5.6), qui génère un jeton propre à chaque application autorisée, révocable indépendamment du mot de passe principal.
Exemple
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Pièges fréquents
- Confondre jeton d’accès et clé d’API : la clé identifie souvent une application de façon durable, le jeton d’accès identifie en plus une autorisation précise, souvent limitée dans le temps.
- Stocker un jeton d’accès en clair dans le stockage local du navigateur (
localStorage) l’expose à un vol via une faille XSS ; un cookieHttpOnlyest en général plus prudent. - Oublier de gérer l’expiration : une application qui ne rafraîchit pas son jeton finit par recevoir des réponses 401 sans prévenir l’utilisateur de la cause réelle.