UnauthorizedError: No authorization token was found

Si l’erreur n’est pas gérée, Express l’affiche avec sa pile d’appels, en commençant par « UnauthorizedError: No authorization token was found ». `err.code` distingue `credentials_required` (aucun jeton) de `credentials_bad_scheme` et de `credentials_bad_format` (« Format is Authorization: Bearer [token] »).

express-jwt (Node.js) — UnauthorizedError, code credentials_required

Ce que cela signifie

express-jwt protège la route mais n’a trouvé aucun jeton : la requête n’a pas d’en-tête `Authorization` et aucune fonction `getToken` personnalisée n’en a renvoyé. Comme `credentialsRequired` vaut `true` par défaut, le middleware lève `UnauthorizedError` avec `code: "credentials_required"` et `status: 401`, et la requête n’atteint jamais votre gestionnaire. Un en-tête présent mais qui n’est pas de la forme `Bearer <token>` échoue plutôt avec « Format is Authorization: Bearer [token] ».

Pourquoi cela se produit

• Le client n’a envoyé aucun en-tête Authorization

  fréquente

  Utilisateur pas encore connecté, client HTTP sans l’intercepteur qui ajoute l’en-tête, ou jeton effacé après son expiration. Examinez la requête dans le panneau Réseau du navigateur.

• Le jeton passe par un cookie ou par la chaîne de requête

  fréquente

  Par défaut, express-jwt ne lit que `Authorization: Bearer`. Les jetons placés dans un cookie HttpOnly, un paramètre `?access_token=` ou un en-tête personnalisé nécessitent une fonction `getToken`, et les cookies nécessitent en plus `cookie-parser`.

• Un proxy a supprimé l’en-tête

  occasionnelle

  Les passerelles d’API avec des mappages d’en-têtes explicites, les proxys qui ne transmettent qu’une liste d’en-têtes autorisés ou une règle de réécriture qui vide l’en-tête peuvent supprimer `Authorization` avant que la requête n’atteigne Node. Le navigateur montre l’en-tête ; le serveur ne le reçoit jamais.

• Le middleware protège aussi les routes publiques

  occasionnelle

  `app.use(expressjwt(...))` placé avant les routes protège tout, y compris les routes de diagnostic, la connexion et les ressources statiques. Les requêtes vers ces routes ne portent, légitimement, aucun jeton.

Comment corriger l’erreur

1. 1.

   Indiquer à express-jwt où se trouve le jeton

   `getToken` reçoit la requête et renvoie la chaîne du jeton ou `null`. Gardez-la simple et évitez d’accepter des jetons provenant de plusieurs endroits à la fois.

   import cookieParser from "cookie-parser";
   import { expressjwt } from "express-jwt";
   
   app.use(cookieParser());
   app.use(
     expressjwt({
       secret: getSigningKey,          // e.g. jwks-rsa's expressJwtSecret(...)
       algorithms: ["RS256"],
       getToken: (req) => req.cookies.access_token ?? null,
     }),
   );

2. 2.

   Exempter les routes publiques ou rendre l’authentification facultative

   `.unless()` ignore les chemins listés. `credentialsRequired: false` laisse passer les requêtes sans jeton, sans `req.auth`, pour que chaque route puisse décider.

   app.use(
     expressjwt({ secret, algorithms: ["HS256"] }).unless({ path: ["/health", "/login", /^\/public\//] }),
   );
   
   // Or keep authentication optional and decide per route:
   app.use(expressjwt({ secret, algorithms: ["HS256"], credentialsRequired: false }));

3. 3.

   Transformer l’erreur en véritable réponse 401

   Le gestionnaire par défaut d’Express utilise le `status` de l’erreur (401), mais répond avec une page HTML (qui inclut la pile d’appels en développement) et sans en-tête `WWW-Authenticate`. Convertissez vous-même `UnauthorizedError` en une réponse 401 JSON avec cet en-tête.

   app.use((err, req, res, next) => {
     if (err.name === "UnauthorizedError") {
       return res.status(401).set("WWW-Authenticate", "Bearer").json({ error: err.code });
     }
     next(err);
   });

← Parcourir toute la base de données des erreurs de signature