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?

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.

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 .

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 .

  + -----------------------
  | 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):

• Différence entre les codes de redirection HTTP
• Combien de temps les navigateurs mettent-ils en cache HTTP 301?
• Quel est le code d'état HTTP correct lors de la redirection vers une page de connexion?
• Quelle est la différence entre une redirection 302 et 307?

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é.

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.

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.

• 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.

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.

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)

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.

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

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

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.

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.

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é).

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)"