403 Interdit vs 401 Réponses HTTP non autorisées

2786

Pour une page Web qui existe, mais pour laquelle un utilisateur n'a pas les privilèges suffisants (ils ne sont pas connectés ou n'appartiennent pas au groupe d'utilisateurs approprié), quelle est la réponse HTTP appropriée à servir?

401 Unauthorized?
403 Forbidden?
Autre chose?

Ce que j'ai lu sur chacun jusqu'à présent n'est pas très clair sur la différence entre les deux. Quels cas d'utilisation conviennent à chaque réponse?

http-headers http-status-code-403 http-status-codes http-status-code-401 http-response-codes VirtuosiMedia
la source
358
401 'Non autorisé' devrait être 401 'Non authentifié', problème résolu!
Christophe Roussy
47
Je ne me souviens pas combien de fois moi et mes collègues sommes revenus à stackoverflow pour cette question. Peut-être que les normes HTTP devraient envisager de modifier les noms ou descriptions pour 401 et 403.
neurite
En fait, je reçois une version différente de cette erreur. comme "os_authType était 'any' et un cookie invalide a été envoyé". Tellement incapable de comprendre comment résoudre ce problème. Googlé beaucoup de temps, a eu des raisons mais n'a pas trouvé de solution.
Sandeep Anand
@Qwerty no, le nouveau RFC7231 obsolète le RFC2616. 403 a une signification différente maintenant.
fishbone
1
@fishbone vous n'avez également pas noté que le code de statut 401 a été supprimé de ce RFC: D
Barkermn01

Réponses:

4117

Une explication claire de Daniel Irvine :

Il y a un problème avec 401 Unauthorized , le code d'état HTTP pour les erreurs d'authentification. Et c'est tout: c'est pour l'authentification, pas l'autorisation. La réception d'une réponse 401 signifie que le serveur vous dit: «vous n'êtes pas authentifié - soit pas authentifié du tout ou authentifié de manière incorrecte - mais veuillez vous authentifier à nouveau et réessayer.» Pour vous aider, il comprendra toujours un en - tête WWW-Authenticate qui décrit comment s'authentifier.

Il s'agit d'une réponse généralement renvoyée par votre serveur Web, et non par votre application Web.

C'est aussi quelque chose de très temporaire; le serveur vous demande de réessayer.

Donc, pour l'autorisation, j'utilise la réponse interdite 403 . C'est permanent, c'est lié à ma logique d'application, et c'est une réponse plus concrète qu'un 401.

En recevant une réponse 403, le serveur vous dit: «Je suis désolé. Je sais qui vous êtes - je crois qui vous dites être - mais vous n'avez tout simplement pas la permission d'accéder à cette ressource. Peut-être que si vous demandez gentiment à l'administrateur système, vous obtiendrez la permission. Mais s'il vous plaît, ne me dérangez pas avant que votre situation ne change. »

En résumé, une réponse 401 non autorisée doit être utilisée pour une authentification manquante ou incorrecte, et une réponse 403 interdite doit être utilisée par la suite, lorsque l'utilisateur est authentifié mais n'est pas autorisé à effectuer l'opération demandée sur la ressource donnée.

Un autre joli format illustré de la façon dont les codes de statut http doivent être utilisés.

entrez la description de l'image ici

JPReddy
la source
43
Le message IIS 403 par défaut est "Il s'agit d'une erreur générique 403 et signifie que l'utilisateur authentifié n'est pas autorisé à afficher la page", ce qui semble être le cas.
Ben Challenor
333
@JPReddy Votre réponse est correcte. Cependant, je m'attendrais à ce que 401 soit nommé "Non authentifié" et 403 soit nommé "Non autorisé". Il est très déroutant que 401, qui a à voir avec l'authentification, ait le format accompagnant le texte "Non autorisé" .... Sauf si je ne suis pas bon en anglais (ce qui est tout à fait une possibilité).
p.matsinopoulos
64
@ZaidMasud, selon RFC, cette interprétation n'est pas correcte. La réponse de Cumbayah avait raison. 401 signifie "vous manquez la bonne autorisation". Cela implique "si vous le souhaitez, vous pouvez essayer de vous authentifier". Ainsi, un client qui ne s'est pas authentifié correctement et un client correctement authentifié qui n'a pas l'autorisation obtiendront un 401. 403 signifie "Je ne répondrai pas à cela, qui que vous soyez". RFC indique clairement que "l'autorisation n'aidera pas" dans le cas de 403.
Davide R.
84
401 est une erreur d'authentification, 403 est une erreur d'autorisation. Aussi simple que cela.
Shahriyar Imanov
30
Vous avez omis "Eh bien, c'est mon point de vue de toute façon :)" lors de la copie de son article de blog et, malheureusement, son point de vue est faux. Comme d'autres l'ont indiqué, 403 signifie que vous ne pouvez pas accéder à la ressource, quelle que soit la personne avec laquelle vous êtes authentifié. J'utilise généralement ce code d'état pour les ressources verrouillées par des plages d'adresses IP ou des fichiers dans ma racine Web auxquels je ne veux pas accéder directement (c'est-à-dire qu'un script doit les servir).
Kyle
403

Voir RFC2616 :

401 non autorisé:

Si la demande contenait déjà des informations d'identification d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification.

403 Interdit:

Le serveur a compris la demande, mais refuse de la satisfaire.

Mise à jour

D'après votre cas d'utilisation, il apparaît que l'utilisateur n'est pas authentifié. Je retournerais 401.

Edit: RFC2616 est obsolète, voir RFC7231 et RFC7235 .

Oded
la source
21
Merci, cela m'a aidé à le clarifier. J'utilise les deux - le 401 pour les utilisateurs non authentifiés, le 403 pour les utilisateurs authentifiés avec des autorisations insuffisantes.
VirtuosiMedia
52
Je n'ai pas déçu, mais je trouve cette réponse assez trompeuse. 403 interdit est utilisé de manière plus appropriée dans le contenu qui ne sera jamais servi (comme les fichiers .config dans asp.net). c'est soit ça, soit un 404. à mon humble avis, il ne serait pas approprié de retourner 403 pour quelque chose qui peut être consulté, mais vous n'aviez tout simplement pas les bonnes informations d'identification. ma solution serait de donner un message d'accès refusé avec un moyen de changer les informations d'identification. ça ou un 401.
Mel
27
"La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée." Il semblerait que si vous ne souhaitez pas utiliser l'authentification de style HTTP, un code de réponse 401 n'est pas approprié.
Brilliand
8
Je soutiendrai Billiand ici. L'instruction est "Si la demande contient déjà des informations d'identification d'autorisation". Cela signifie que s'il s'agit d'une réponse d'une demande qui a fourni les informations d'identification (par exemple, la réponse d'une tentative d'authentification RFC2617). Il s'agit essentiellement de permettre au serveur de dire "Mauvaise paire compte / mot de passe, réessayez". Dans la question posée, l'utilisateur est vraisemblablement authentifié mais non autorisé. 401 n'est jamais la réponse appropriée à ces circonstances.
ldrut
6
Brilliand a raison, 401 n'est approprié que pour l'authentification HTTP.
Juampi
296

Quelque chose les autres réponses manquent est qu'il doit être compris que l'authentification et l'autorisation dans le contexte de la RFC 2616 se réfère UNIQUEMENT au protocole d'authentification HTTP de la RFC 2617. L'authentification par des schémas en dehors de la RFC2617 n'est pas prise en charge dans les codes d'état HTTP et n'est pas prise en compte pour décider d'utiliser 401 ou 403.

Bref et concis

Non autorisé indique que le client n'est pas authentifié RFC2617 et que le serveur lance le processus d'authentification. Interdit indique que le client est authentifié RFC2617 et n'a pas d'autorisation ou que le serveur ne prend pas en charge RFC2617 pour la ressource demandée.

Si vous avez votre propre processus de connexion roll-your-own et n'utilisez jamais l'authentification HTTP, 403 est toujours la bonne réponse et 401 ne doit jamais être utilisé.

Détaillé et en profondeur

De RFC2616

10.4.2 401 non autorisé

La demande nécessite une authentification utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation approprié (section 14.8).

et

10.4.4 403 Interdit Le serveur a compris la demande mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée.

La première chose à garder à l'esprit est que "Authentification" et "Autorisation" dans le contexte de ce document se réfèrent spécifiquement aux protocoles d'authentification HTTP de la RFC 2617. Ils ne font référence à aucun protocole d'authentification roll-your-own que vous avez pu créer. en utilisant des pages de connexion, etc. J'utiliserai "login" pour faire référence à l'authentification et l'autorisation par des méthodes autres que RFC2617

La vraie différence n'est donc pas le problème ou même s'il existe une solution. La différence est ce que le serveur attend du client.

401 indique que la ressource ne peut pas être fournie, mais le serveur DEMANDE que le client se connecte via l'authentification HTTP et a envoyé des en-têtes de réponse pour lancer le processus. Il existe peut-être des autorisations qui permettront l'accès à la ressource, peut-être pas, mais essayons de voir ce qui se passe.

403 indique que la ressource ne peut pas être fournie et il n'y a, pour l'utilisateur actuel, aucun moyen de résoudre ce problème via la RFC2617 et inutile d'essayer. Cela peut être dû au fait que l'on sait qu'aucun niveau d'authentification n'est suffisant (par exemple à cause d'une liste noire IP), mais cela peut être dû au fait que l'utilisateur est déjà authentifié et n'a pas de pouvoir. Le modèle RFC2617 est un utilisateur, un identifiant de sorte que le cas où l'utilisateur peut avoir un deuxième ensemble d'informations d'identification qui pourraient être autorisées peut être ignoré. Cela ne suggère ni n'implique qu'une sorte de page de connexion ou un autre protocole d'authentification non RFC2617 peut ou non aider - cela est en dehors des normes et de la définition RFC2616.

Edit: RFC2616 est obsolète, voir RFC7231 et RFC7235 .

ldrut
la source
7
Alors, que devons-nous faire lorsque l'utilisateur demande une page qui nécessite une authentification non http? Envoyer le code d'état 403?
marcovtwout
2
C'est la réponse qui a répondu à mes questions sur la distinction.
Patrick
9
Ceci est important: "si vous avez votre propre processus de connexion roll-your-own et n'utilisez jamais l'authentification HTTP, 403 est toujours la bonne réponse et 401 ne doit jamais être utilisé."
ggg
1
@marcovtwout Envoyer un 302 à votre page de connexion, ou un 403 contenant un corps avec des informations sur la connexion?
Alex
4
Le RFC7235 ne propose-t-il pas des défis d'authentification «à rouler soi-même» ou alternatifs? Pourquoi le flux de connexion de mon application ne peut-il pas présenter son défi sous la forme d'unWWW-Authenticate tête? Même si un navigateur ne le prend pas en charge, mon application React peut ...
jchook
127 
  + -----------------------
  | DES RESSOURCES EXISTENT? (si privé, il est souvent vérifié APRÈS vérification d'authentification)
  + -----------------------
    | |
 NON | v OUI
    v + -----------------------
   404 | EST CONNECTE? (authentifié, alias a une session ou un cookie JWT)
   ou + -----------------------
   401 | |
   403 NO | | OUI
   3xx vv
              401 + -----------------------
       (404 sans révélation) | PEUT ACCÉDER À LA RESSOURCE? (permission, autorisé, ...)
              ou + -----------------------
             rediriger | |
             pour vous connecter NON | | OUI
                               | |
                               vv
                               403 OK 200, rediriger, ...
                      (ou 404: pas de révélation)
                      (ou 404: la ressource n'existe pas si elle est privée)
                      (ou 3xx: redirection)

Les vérifications sont généralement effectuées dans cet ordre:

  • 404 si la ressource est publique et n'existe pas ou redirection 3xx
  • AUTREMENT:
  • 401 si non connecté ou session expirée
  • 403 si l'utilisateur n'est pas autorisé à accéder à la ressource (fichier, json, ...)
  • 404 si la ressource n'existe pas ou ne veut rien révéler, ou redirection 3xx

NON AUTORISÉ : Code d'état (401) indiquant que la demande nécessite une authentification , cela signifie généralement que l'utilisateur doit être connecté (session). Utilisateur / agent inconnu du serveur. Peut répéter avec d'autres informations d'identification. REMARQUE: cela prête à confusion car cela aurait dû être nommé «non authentifié» au lieu de «non autorisé». Cela peut également se produire après la connexion si la session a expiré. Cas spécial: peut être utilisé au lieu de 404 pour éviter de révéler la présence ou la non-présence de la ressource (crédits @gingerCodeNinja)

INTERDIT : Code d'état (403) indiquant que le serveur a compris la demande mais a refusé de l'exécuter. Utilisateur / agent connu par le serveur mais dont les informations d'identification sont insuffisantes . La demande répétée ne fonctionnera pas, à moins que les informations d'identification ne soient modifiées, ce qui est très peu probable dans un court laps de temps. Cas spécial: peut être utilisé au lieu de 404 pour éviter de révéler la présence ou la non-présence de la ressource (crédits @gingerCodeNinja)

NOT FOUND : Code d'état (404) indiquant que la ressource demandée n'est pas disponible. L'utilisateur / l'agent est connu mais le serveur ne révélera rien sur la ressource, fait comme s'il n'existait pas. La répétition ne fonctionnera pas. Il s'agit d'une utilisation spéciale de 404 (github le fait par exemple).

Comme mentionné par @ChrisH, il existe quelques options pour la redirection 3xx (301, 302, 303, 307 ou ne pas rediriger du tout et utiliser un 401):

Christophe Roussy
la source
Par exemple, je me suis connecté et je peux accéder à une page, mais cette autorisation n'est pas activée pour moi. Quel code de statut reviendra?
Barteloma
@bookmarker Loggin in est appelé authentification, ce qui est la première étape. Donc, si vous ne disposez pas de l'autorisation après la connexion, vous obtiendrez 403 Interdit (les informations d'identification insuffisantes signifient que vous n'avez pas suffisamment d'autorisations).
Christophe Roussy
3
Explication claire et simple. Juste ce que j'ai besoin.
Estevez
si l'utilisateur n'est pas connecté ou connecté mais n'a pas d'autorisation et que le contenu n'existe pas à l'emplacement, parfois vous voudrez probablement renvoyer 401/403 au lieu de 404, afin de ne pas exposer ce qui est ou n'est pas n'y a pas si l'utilisateur n'est pas authentifié et connecté. Le simple fait de savoir que quelque chose existe peut suggérer quelque chose ou casser le NDA. Donc, parfois, la partie 404 de ce diagramme doit être déplacée sous connecté / authentifié.
gingerCodeNinja
1
@MattKocaj note que le no revealcas peut parfois être détecté via des différences de synchronisation subtiles et ne doit pas être considéré comme une fonction de sécurité, il peut simplement ralentir les attaquants ou aider un peu à la confidentialité.
Christophe Roussy
113

Selon RFC 2616 (HTTP / 1.1) 403 est envoyé lorsque:

Le serveur a compris la demande, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée. Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre public pourquoi la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre ces informations à la disposition du client, le code d'état 404 (Not Found) peut être utilisé à la place

En d'autres termes, si le client PEUT accéder à la ressource par authentification, 401 doit être envoyé.

Cumbayah
la source
5
Et s'il n'est pas clair s'ils peuvent y accéder ou non? Disons que j'ai 3 niveaux d'utilisateurs - Public, Membres et Membres Premium. Supposons que la page est réservée aux membres Premium. Un utilisateur public n'est pratiquement pas authentifié et peut être membre ou membre Premium lorsqu'il se connecte. Pour le niveau d'utilisateur Membre, un 403 semble approprié. Pour les membres Premium, le 401. Mais que faites-vous pour le public?
VirtuosiMedia
27
à mon humble avis, c'est la réponse la plus précise. cela dépend de l'application, mais généralement, si un utilisateur authentifié n'a pas les droits suffisants sur une ressource, vous voudrez peut-être fournir un moyen de modifier les informations d'identification ou d'envoyer un 401. Je pense que le 403 est le mieux adapté pour le contenu qui n'est jamais servi. Dans asp.net, cela signifierait les fichiers web.config * les fichiers .resx, etc., car quel que soit l'utilisateur qui se connecte, ces fichiers ne seront JAMAIS servis, il est donc inutile de réessayer.
Mel
6
+1, mais un +1 incertain. La conclusion logique est qu'un 403 ne devrait jamais être retourné car 401 ou 404 serait une réponse strictement meilleure.
CurtainDog
12
@Mel Je pense qu'un fichier auquel le client ne devrait pas avoir accès devrait être un 404. C'est un fichier interne au système; l'extérieur ne devrait même pas savoir qu'il existe. En renvoyant un 403, vous faites savoir au client qu'il existe, pas besoin de donner ces informations aux pirates. La spécification pour 403 ditAn origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
Juan Mendes
3
Bien que cela me semble être probablement une interprétation exacte de l'ancien RFC 2616, notez que le RFC 7231 définit la sémantique d'un 403 différemment , et déclare en fait explicitement que "Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes." Donc, même si cette réponse était exacte en 2010, elle est complètement fausse aujourd'hui, car la signification du code de statut a été réécrite sous nos pieds. (Chose ennuyeuse, les modifications de l' annexe RFC 2616 ne reconnaissent pas le changement!)
Mark Amery
46

En supposant que l'authentification HTTP (en - têtes WWW-Authenticate et Authorization ) est en cours d'utilisation , si l'authentification en tant qu'un autre utilisateur autorise l'accès à la ressource demandée, alors 401 Unauthorized doit être renvoyé.

403 Interdit est utilisé lorsque l'accès à la ressource est interdit à tout le monde ou restreint à un réseau donné ou autorisé uniquement via SSL, tant qu'il n'est pas lié à l'authentification HTTP.

Si l'authentification HTTP n'est pas utilisée et que le service est un schéma d'authentification basé sur les cookies comme c'est la norme de nos jours, alors un 403 ou un 404 doit être retourné.

Concernant 401, cela provient de la RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Authentification):

3.1. 401 non autorisé

Le code d'état 401 (non autorisé) indique que la demande n'a pas été appliquée car il manque des informations d'identification d'authentification valides pour la ressource cible. Le serveur d'origine DOIT envoyer un champ d'en-tête WWW-Authenticate (section 4.4) contenant au moins un défi applicable à la ressource cible. Si la demande incluait des informations d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations.. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.1). Si la réponse 401 contient le même défi que la réponse précédente, et l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors l'agent utilisateur DEVRAIT présenter la représentation jointe à l'utilisateur, car elle contient généralement des informations de diagnostic pertinentes.

La sémantique de 403 (et 404) a changé au fil du temps. C'est de 1999 (RFC 2616):

10.4.4 403 Interdit

Le serveur a compris la demande, mais refuse de la satisfaire.
L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée.
Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre
public pourquoi la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre ces informations à la disposition du client, le code d'état 404
(Not Found) peut être utilisé à la place.

En 2014, la RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): sémantique et contenu) a changé la signification de 403:

6.5.3. 403 Interdit

Le code d'état 403 (interdit) indique que le serveur a compris la demande mais refuse de l'autoriser. Un serveur qui souhaite rendre public pourquoi la demande a été interdite peut décrire cette raison dans la charge utile de réponse (le cas échéant).

Si des informations d'authentification ont été fournies dans la demande, le
serveur les considère insuffisantes pour accorder l'accès. Le client
NE DEVRAIT PAS répéter automatiquement la demande avec les mêmes
informations d'identification. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes. Cependant, une demande peut être interdite pour des raisons
sans rapport avec les informations d'identification.

Un serveur d'origine qui souhaite "masquer" l'existence actuelle d'une
ressource cible interdite PEUT plutôt répondre avec un code d'état de
404 (introuvable).

Ainsi, un 403 (ou un 404) pourrait désormais signifier n'importe quoi. Fournir de nouvelles informations d'identification pourrait aider ... ou non.

Je crois que la raison pour laquelle cela a changé est que la RFC 2616 a supposé que l'authentification HTTP serait utilisée alors que dans la pratique, les applications Web d'aujourd'hui créent des schémas d'authentification personnalisés en utilisant par exemple des formulaires et des cookies.

Erwan Legrand
la source
2
C'est intéressant. Basé sur RFC 7231 et RFC 7235, je ne vois pas de distinction évidente entre 401 et 403
Brian
2
403 signifie "Je vous connais mais vous ne pouvez pas voir cette ressource." Il n'y a aucune raison de confusion.
Michael Blackburn
"Si la demande comprenait des informations d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.1)." Cependant, "4.2. Le champ d'en-tête" Autorisation "permet à un agent utilisateur de s'authentifier auprès d'un serveur d'origine". On dirait que dans la RFC7235, ils utilisent le terme "autorisation" comme s'il s'agissait "d'authentification". Dans ce cas, il pourrait sembler qu'un utilisateur authentifié mais non autorisé ne devrait pas obtenir un 401, mais plutôt un 403
arcuri82
29

C'est une question plus ancienne, mais une option qui n'a jamais été vraiment évoquée était de renvoyer un 404. Du point de vue de la sécurité, la réponse la plus votée souffre d'une vulnérabilité potentielle de fuite d'informations . Supposons, par exemple, que la page Web sécurisée en question soit une page d'administration système, ou plus couramment, soit un enregistrement dans un système auquel l'utilisateur n'a pas accès. Idéalement, vous ne voudriez pas qu'un utilisateur malveillant sache même qu'il y a une page / un enregistrement, et encore moins qu'il n'y a pas accès. Lorsque je crée quelque chose comme ça, j'essaie d'enregistrer les demandes non authentifiées / non autorisées dans un journal interne, mais je renvoie un 404.

OWASP dispose de plus d'informations sur la manière dont un attaquant pourrait utiliser ce type d'informations dans le cadre d'une attaque.

Patrick White
la source
3
L'utilisation d'un 404 a été mentionnée dans les réponses précédentes. Vous êtes sur le point de re: fuite d'informations et cela devrait être une considération importante pour quiconque déploie son propre schéma d'authentification / autorisation. +1 pour avoir mentionné OWASP.
Dave Watts
Ironiquement, le lien OWASP va maintenant à une page 404. J'ai trouvé quelque chose de similaire (je pense) sur owasp.org/index.php/…
anned20
Merci pour l'avertissement, je l'ai mis à jour!
Patrick White
Dépend de l'API et de la manière dont l'accès est accordé. Mais la "fuite" n'est pas un problème si elle renvoie 401 pour le nom d'utilisateur / mot de passe est-ce la même chose que pour un formulaire Web?
James
26
  • 401 Non autorisé : je ne sais pas qui vous êtes. C'est une erreur d'authentification.
  • 403 Interdit : je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource. Il s'agit d'une erreur d'autorisation.
Akshay Misal
la source
Je ne suis pas sûr que cela signifie «toujours» que l'expéditeur était inconnu. Tout ce qu'ils demandaient n'était pas autorisé.
James
22

Cette question a été posée il y a quelque temps, mais la réflexion des gens continue.

La section 6.5.3 de ce projet (rédigé par Fielding et Reschke) donne au code de statut 403 une signification légèrement différente de celle documentée dans la RFC 2616 .

Il reflète ce qui se passe dans les schémas d'authentification et d'autorisation utilisés par un certain nombre de serveurs Web et de frameworks populaires.

J'ai mis l'accent sur ce que je pense être le plus saillant.

6.5.3. 403 Interdit

Le code d'état 403 (interdit) indique que le serveur a compris la demande mais refuse de l'autoriser. Un serveur qui souhaite rendre public pourquoi la demande a été interdite peut décrire cette raison dans la charge utile de la réponse (le cas échéant).

Si des informations d'authentification ont été fournies dans la demande, le serveur les considère insuffisantes pour accorder l'accès. Le client NE DEVRAIT PAS répéter la demande avec les mêmes informations d'identification. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes. Cependant, une demande peut être interdite pour des raisons sans rapport avec les informations d'identification.

Un serveur d'origine qui souhaite "masquer" l'existence actuelle d'une ressource cible interdite PEUT plutôt répondre avec un code d'état de 404 (non trouvé).

Quelle que soit la convention que vous utilisez, l'important est d'assurer l'uniformité de votre site / API.

Dave Watts
la source
2
Le projet a été approuvé et est maintenant RFC 7231.
Vebjorn Ljosa
13

TL; DR

  • 401: Un refus lié à l'authentification
  • 403: Un refus qui n'a RIEN à voir avec l'authentification

Exemples pratiques

Si apache nécessite une authentification (via .htaccess) et que vous appuyez surCancel , il répondra par401 Authorization Required

Si nginx trouve un fichier, mais n'a aucun droit d'accès (utilisateur / groupe) pour le lire / y accéder, il répondra par403 Forbidden

RFC (2616 section 10)

401 Non autorisé (10.4.2)

Signification 1: besoin de s'authentifier

La demande nécessite une authentification utilisateur. ...

Signification 2: authentification insuffisante

... Si la demande contenait déjà des informations d'identification d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. ...

403 Interdit (10.4.4)

Signification: sans rapport avec l'authentification

... L'autorisation n'aidera pas ...

Plus de détails:

  • Le serveur a compris la demande, mais refuse de la satisfaire.

  • Il DEVRAIT décrire la raison du refus dans l'entité

  • Le code d'état 404 (Introuvable) peut être utilisé à la place

    (Si le serveur souhaite conserver ces informations du client)

lévite
la source
11

ils ne sont pas connectés ou n'appartiennent pas au groupe d'utilisateurs approprié

Vous avez indiqué deux cas différents; chaque cas doit avoir une réponse différente:

  1. S'ils ne sont pas du tout connectés, vous devez retourner 401 Unauthorized
  2. S'ils sont connectés mais n'appartiennent pas au groupe d'utilisateurs approprié, vous devez renvoyer 403 Forbidden

Note sur le RFC basée sur les commentaires reçus à cette réponse:

Si l'utilisateur n'est pas connecté, il n'est pas authentifié, dont l'équivalent HTTP est 401 et est trompeusement appelé non autorisé dans la RFC. Comme l'indique la section 10.4.2 pour 401 non autorisé :

"La demande nécessite une authentification utilisateur ."

Si vous n'êtes pas authentifié, 401 est la bonne réponse. Cependant, si vous n'êtes pas autorisé, dans le sens sémantiquement correct, 403 est la bonne réponse.

Zaid Masud
la source
5
Ce n'est pas correct. Reportez-vous à RFC et à la réponse de @ Cumbayah.
Davide R.
7
@DavideR. le RFC utilise l' authentification et l' autorisation de manière interchangeable. Je crois que cela a plus de sens lorsqu'il est lu avec le sens d' authentification .
Zaid Masud
Cette réponse est inversée. Non autorisé n'est pas identique à Non authentifié. @DavideR a raison. L'authentification et l'autorisation NE SONT PAS interchangeables
BozoJoe
2
2616 devrait être brûlé. Plusieurs nouveaux RFC sont beaucoup plus clairs qu'il est nécessaire de faire la différence entre "Je ne vous connais pas" et "Je vous connais mais vous ne pouvez pas y accéder". Il n'y a aucune raison légitime de reconnaître l'existence d'une ressource qui ne sera jamais remplie (ou non via http), comme le suggèrent les 403 véridistes.
Michael Blackburn
6

Ce sont les significations:

401 : L'utilisateur n'est pas (correctement) authentifié, la ressource / page nécessite une authentification

403 : Utilisateur authentifié, mais son rôle ou ses autorisations ne permettent pas d'accéder à la ressource demandée, par exemple l'utilisateur n'est pas un administrateur et la page demandée est pour les administrateurs

Luca C.
la source
C'est une excellente réponse TLDR à cette question.
Kousha
5

C'est plus simple dans ma tête qu'ailleurs ici, donc:

401: vous avez besoin de l'authentification de base HTTP pour voir cela.

403: Vous ne pouvez pas voir cela, et l'authentification de base HTTP n'aidera pas.

Si l'utilisateur a juste besoin de se connecter en utilisant le formulaire de connexion HTML standard de votre site, 401 ne serait pas approprié car il est spécifique à l'authentification de base HTTP.

Je ne recommande pas d'utiliser 403 pour refuser l'accès à des choses comme /includes, car en ce qui concerne le Web, ces ressources n'existent pas du tout et devraient donc 404.

Cela laisse 403 comme "vous devez être connecté".

En d'autres termes, 403 signifie "cette ressource nécessite une autre forme d'authentification que l'authentification de base HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Vladimir Kornea
la source
5

Je pense qu'il est important de considérer que, pour un navigateur, 401 ouvre une boîte de dialogue d'authentification pour que l'utilisateur entre de nouvelles informations d'identification, tandis que 403 ne le fait pas. Les navigateurs pensent que, si un 401 est renvoyé, l'utilisateur doit se réauthentifier. Ainsi, 401 représente une authentification non valide tandis que 403 signifie un manque d'autorisation.

Voici quelques cas dans cette logique où une erreur serait renvoyée de l'authentification ou de l'autorisation, avec des phrases importantes en gras.

  • Une ressource nécessite une authentification mais aucune information d'identification n'a été spécifiée .

401 : Le client doit spécifier les informations d'identification.

  • Les informations d'identification spécifiées sont dans un format non valide .

400 : Ce n'est ni 401 ni 403, car les erreurs de syntaxe doivent toujours renvoyer 400.

  • Les informations d'identification spécifiées font référence à un utilisateur qui n'existe pas .

401 : Le client doit spécifier des informations d'identification valides.

  • Les informations d'identification spécifiées ne sont pas valides mais spécifiez un utilisateur valide (ou ne spécifiez pas d'utilisateur si un utilisateur spécifié n'est pas requis).

401 : Encore une fois, le client doit spécifier des informations d'identification valides.

  • Les informations d' identification spécifiées ont expiré .

401 : C'est pratiquement la même chose que d'avoir des informations d'identification non valides en général, donc le client doit spécifier des informations d'identification valides.

  • Les informations d'identification spécifiées sont complètement valides mais ne suffisent pas à la ressource particulière , bien qu'il soit possible que des informations d'identification avec plus d'autorisations le puissent.

403 : la spécification des informations d'identification valides n'accorderait pas l'accès à la ressource, car les informations d'identification actuelles sont déjà valides mais n'ont pas d'autorisation.

  • La ressource particulière est inaccessible quelles que soient les informations d'identification.

403 : ceci est indépendamment des informations d'identification, donc la spécification d'informations d'identification valides ne peut pas aider.

  • Les informations d'identification spécifiées sont entièrement valides mais le client en particulier ne peut pas les utiliser.

403 : Si le client est bloqué, la spécification de nouvelles informations d'identification ne fera rien.

Grant Gryczan
la source
4

En anglais:

401

Vous êtes potentiellement autorisé à accéder, mais pour une raison quelconque, cette demande vous a été refusée. Comme un mauvais mot de passe? Réessayez, avec la bonne demande, vous obtiendrez une réponse positive à la place.

403

Vous n'êtes jamais autorisé. Votre nom ne figure pas sur la liste, vous n'entrerez jamais, partez, n'envoyez pas de nouvelle demande, il sera toujours refusé. Allez-vous en.

James
la source
1

Compte tenu des derniers RFC sur le sujet ( 7231 et 7235 ), le cas d'utilisation semble assez clair (italiques ajoutés):

  • 401 est pour non authentifié ("manque d'authentification valide"); c'est-à-dire «je ne sais pas qui vous êtes, ou je ne crois pas que vous êtes qui vous dites être».

401 non autorisé

Le code d'état 401 (non autorisé) indique que la demande n'a pas été appliquée car il manque des informations d'identification d' authentification valides pour la ressource cible. Le serveur générant une réponse 401 DOIT envoyer un champ d'en-tête WWW-Authenticate (section 4.1) contenant au moins un défi applicable à la ressource cible.

Si la demande comprenait des informations d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations. L'agent utilisateur PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.2). Si la réponse 401 contient le même défi que la réponse précédente, et l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors l'agent utilisateur DEVRAIT présenter la représentation jointe à l'utilisateur, car elle contient généralement des informations de diagnostic pertinentes.

  • 403 est pour non autorisé ("refuse d'autoriser"); c'est-à-dire «je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource».

403 Interdit

Le code d'état 403 (interdit) indique que le serveur a compris la demande mais refuse de l'autoriser . Un serveur qui souhaite rendre public pourquoi la demande a été interdite peut décrire cette raison dans la charge utile de réponse (le cas échéant).

Si des informations d'authentification ont été fournies dans la demande, le serveur les considère insuffisantes pour accorder l'accès. Le client NE DEVRAIT PAS répéter automatiquement la demande avec les mêmes informations d'identification. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes. Cependant, une demande peut être interdite pour des raisons sans rapport avec les informations d'identification.

Un serveur d'origine qui souhaite "masquer" l'existence actuelle d'une ressource cible interdite PEUT plutôt répondre avec un code d'état de 404 (non trouvé).

cjbarth
la source
2
-1; ces passages ont déjà été cités dans d'autres réponses ici, et le vôtre n'ajoute rien de nouveau. Je dirais que la distinction n'est manifestement pas claire; vous résumez les deux codes comme "manque d'authentification valide" et "refuse d'autoriser" mais je ne peux imaginer aucune situation dans laquelle l'une de ces courtes descriptions s'appliquerait alors que l'autre ne pourrait pas être interprétée comme s'appliquant également.
Mark Amery
Il existe de nombreuses réponses ici qui couvrent de nombreux RFC et sont éditées et mises à jour pour brouiller les eaux. J'ai inclus un lien pour expliquer ce qui authenticatedest et ce qui authorizedest et laissé de côté tous les RFC obsolètes afin que l'application soit claire.
cjbarth
Votre modification clarifie votre interprétation des deux codes, ce qui semble correspondre à l'interprétation de beaucoup d'autres personnes. Cependant, je pense personnellement que l'interprétation n'a guère de sens. L'utilisation de la phrase " Si des informations d'authentification ont été fournies" dans la description du 403 implique qu'un 403 peut être approprié même si aucune information d'identification n'a été fournie - c'est-à-dire le cas "non authentifié". Pendant ce temps, pour moi, l'interprétation la plus naturelle de l'expression "pour la ressource cible" incluse dans la description 401 est qu'un 401 peut être utilisé pour un utilisateur authentifié mais non autorisé.
Mark Amery
-6

Dans le cas de 401 vs 403, cela a été répondu plusieurs fois. Il s'agit essentiellement d'un débat sur «l'environnement de requête HTTP», et non sur un débat «d'application».

Il semble y avoir une question sur le problème de connexion par rouleau (application).

Dans ce cas, le simple fait de ne pas être connecté ne suffit pas pour envoyer un 401 ou un 403, sauf si vous utilisez HTTP Auth vs une page de connexion (non liée à la définition de HTTP Auth). Il semble que vous recherchiez un "201 créé", avec un écran de connexion par rouleau présent (au lieu de la ressource demandée) pour l'accès au niveau de l'application à un fichier. Cela dit:

"Je vous ai entendu, c'est ici, mais essayez plutôt (vous n'êtes pas autorisé à le voir)"

Shawn
la source
Qu'est-ce qui est créé exactement?
Grant Gryczan