POST /auth/signin répond 404 au lieu de 401 lorsqu'un en-tête Authorization est présent

[DavidPivert]

• Relevé par : David
• Le : 29/07/26

Description du problème

Sur l'API (confiture-rest-api), la route POST /api/auth/signin répond
404 Cannot POST /api/auth/signin dès que la requête porte un en-tête
Authorization: Bearer <jeton> invalide ou expiré. Sans cet en-tête, la même
requête répond bien 401 Unauthorized.

Impact usager — il concerne les clients de l'API plutôt que l'application
web. Un client qui conserve un jeton et tente de se reconnecter après son
expiration envoie naturellement l'en-tête, et reçoit alors un 404 qui laisse
croire que la route n'existe plus, au lieu d'une erreur d'authentification.
Le diagnostic part dans la mauvaise direction : on cherche un changement d'API,
pas un problème de jeton.

Navigateur

Sans objet — reproduit en appel HTTP direct (fetch, Node 25). Le
comportement de l'application web n'est pas affecté, celle-ci n'envoyant pas
d'en-tête Authorization sur la connexion.

Scénario pour reproduire le bug

Avec des identifiants volontairement invalides, contre
https://ara.numerique.gouv.fr/api :

# 1. Sans Authorization → 401 Unauthorized (comportement attendu)
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://ara.numerique.gouv.fr/api/auth/signin \
  -H "Content-Type: application/json" \
  -d '{"username":"nobody@example.invalid","password":"x"}'

# 2. Avec un Authorization invalide → 404 Cannot POST /api/auth/signin
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://ara.numerique.gouv.fr/api/auth/signin \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer jeton-invalide" \
  -d '{"username":"nobody@example.invalid","password":"x"}'

Requête	Réponse observée
sans Authorization	401 — {"message":"Unauthorized","statusCode":401}
avec Authorization invalide	404 — {"message":"Cannot POST /api/auth/signin","error":"Not Found","statusCode":404}

Correction à apporter

La route de connexion devrait ignorer l'en-tête Authorization : la
présence d'un jeton, même invalide, n'a pas à influer sur la résolution d'une
route publique. Le comportement attendu est un 401 dans les deux cas (ou un
200/201 si les identifiants sont valides).

Il est possible que ce soit une conséquence de la configuration d'un guard sur
le contrôleur d'authentification, plutôt qu'un choix délibéré.

---

Relevé en développant un client tiers de l'API. Contournement de mon côté : ne
pas envoyer l'en-tête sur cette route — donc rien d'urgent pour moi, mais le
prochain intégrateur y perdra probablement le même temps.

[DavidPivert]

Complément : ma description initiale était trop restrictive. Le comportement n'est pas propre à /auth/signin — il touche l'API entière.

Un en-tête Authorization porteur d'un jeton invalide ou expiré fait répondre 404 « Cannot <MÉTHODE> <chemin> » sur n'importe quelle route, au lieu d'une erreur d'authentification :

Requête	Réponse
GET /api/audits/<id> sans Authorization	404 {"message":"Not Found"} — la ressource n'existe pas
GET /api/audits/<id> avec Bearer invalide	404 Cannot GET /api/audits/<id>
POST /api/audits sans Authorization	400 + erreurs de validation
POST /api/audits avec Bearer invalide	404 Cannot POST /api/audits

Les deux formes de 404 se distinguent d'ailleurs à leur corps : {"message":"Not Found","statusCode":404} pour une ressource absente, {"message":"Cannot POST /api/audits","error":"Not Found","statusCode":404} quand c'est la résolution de route qui échoue.

Pourquoi ça change l'impact. Ce n'est pas seulement la reconnexion qui est concernée : dès qu'un jeton expire en cours de session, toute l'API devient « introuvable » pour le client. Le symptôme oriente vers une API supprimée ou renommée, alors qu'il suffirait de se réauthentifier. C'est ce qui m'est arrivé, et j'ai cherché du mauvais côté un bon moment.

Un 401 dans ces cas rendrait le diagnostic immédiat, et permettrait aux clients de déclencher automatiquement un rafraîchissement de jeton — ce qui est le comportement attendu d'une API à jetons.

(Aucune urgence de mon côté : contourné en n'envoyant pas l'en-tête là où il n'a pas lieu d'être.)