401 signifie non authentifié, 403 signifie authentifié mais non autorisé. Répondez à quatre questions sur une requête et obtenez le bon code de statut, avec les en-têtes et le code.
Renvoyez 401 Unauthorized quand la requête n'a pas d'identifiants valides : pas de jeton, une session expirée, une signature incorrecte. Se connecter pourrait régler le problème, et la réponse doit porter un en-tête WWW-Authenticate. Renvoyez 403 Forbidden quand vous savez qui est l'appelant et qu'il n'a toujours pas le droit de faire cela : se reconnecter ne change rien.
Unauthorized ou Forbidden
Répondez à quatre questions sur la requête que votre serveur refuse. Le sélecteur renvoie le code à envoyer, l'en-tête qui l'accompagne et une raison en une ligne à mettre dans un commentaire de code. Il couvre aussi le cas où vous préférez ne pas révéler que la ressource existe.
401 indique que le serveur ne sait pas qui vous êtes, ou n'a pas accepté la preuve envoyée. 403 indique qu'il sait qui vous êtes et que la réponse reste non.
Oui. La RFC 9110 indique qu'un serveur qui génère une réponse 401 doit envoyer au moins un champ d'en-tête WWW-Authenticate avec un challenge, comme Bearer pour les API à jeton.
401. Les identifiants ne sont plus valides, et de nouveaux identifiants régleraient le problème. Un challenge Bearer peut le préciser avec error="invalid_token".
Oui. La spécification permet à un serveur d'envoyer 404 au lieu de 403 pour masquer l'existence de la ressource. C'est un choix courant pour les identifiants qui appartiennent à d'autres utilisateurs.
C'est possible. Les serveurs envoient 403 pour tout refus qu'ils jugent définitif pour cette requête : règles IP, permissions de fichier manquantes, règle de pare-feu ou échec de vérification de rôle. Le corps de la réponse ou le journal du serveur indique généralement laquelle.
verifyToken remplace votre propre vérification de session ou de JWT. L'ordre compte : authentifier, puis autoriser.
Un chemin envoie l'utilisateur vers la connexion ; l'autre explique le refus.
Oui
Non
La requête portait-elle des identifiants (cookie de session, jeton, en-tête Authorization) ?
Ces identifiants étaient-ils valides et non expirés ?
Cet appelant a-t-il le droit d'effectuer cette action sur cette ressource ?
Faut-il empêcher les appelants sans accès de savoir que la ressource existe ?
Envoyez ceci
Personne n'est connecté. Demandez des identifiants avec un challenge.
Des identifiants sont arrivés mais ont été rejetés. De nouveaux identifiants régleraient le problème.
L'appelant est connu et n'a pas la permission. Se reconnecter ne servira à rien.
L'appelant n'a pas la permission et vous préférez ne pas révéler que la ressource existe.
Authentifié et autorisé. Servez la requête.
Question non posée, car une réponse précédente a déjà déterminé le code.
Commencer gratuitement · Sans carte bancaire