HTTP 401 Non autorisé ou 403 interdit pour un utilisateur "désactivé"?
Un service d'authentification permet de désactiver les comptes utilisateurs (une sorte de soft-delete).
Si le serveur reçoit ensuite une demande d'authentification pour un utilisateur désactivé qui serait autrement valide, le serveur doit-il renvoyer 401 ou 403? Avec l'un ou l'autre code d'état, je retournerais un message indiquant que le compte avait été désactivé.
Pour référence rapide, citations pertinentes de spécification HTTP/1.1 (accent sur le mien):
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). 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 . 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'utilisateur DEVRAIT être présenté l'entité qui a été donnée dans la réponse , car cette entité peut inclure des informations de diagnostic pertinentes. L'authentification d'accès HTTP est expliquée dans "Authentification HTTP: Authentification d'accès de base et Digest" [43].
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, elle DEVRAIT décrire la raison du refus dans le . 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.
Basé sur n email écrit par Roy T. Fielding , il y a apparemment n bug dans la spécification HTTP actuelle.
La façon dont la spécification est destinée à lire est la suivante (en utilisant les citations de l'email ci-dessus):
401 "Non authentifié" :
vous ne pouvez pas faire cela parce que vous ne vous êtes pas authentifié
403 "Non autorisé" :
l'agent utilisateur a envoyé des informations d'identification valides mais n'a pas accès
Ainsi, dans le cas d'un utilisateur désactivé, 403 est la bonne réponse (et 404 est également une option).
J'ai deux réponses différentes pour savoir quoi retourner dans ce cas.
Choix sémantique - 401 Non autorisé. Dans ce cas, votre client a fourni des informations d'identification et la demande a été refusée en fonction des informations d'identification spécifiques. Si le client devait réessayer avec un autre ensemble d'informations d'identification, ou si le compte devait être réactivé à l'avenir, la même demande pourrait réussir.
Choix de sécurité - 404 introuvable. De nombreux services renverront simplement un 404 pour toute panne, afin d'éviter les fuites d'informations. Github me vient immédiatement à l'esprit.
De Informations générales sur l'API , dans les documents de développement de github:
Les demandes non authentifiées renverront 404 pour empêcher toute sorte de fuite d'informations privées.
Pour quelque chose que je déployais en tant que service public, j'irais probablement avec 404 pour éviter de donner à un attaquant des indices sur ses tentatives de connexion. Si c'était pour une consommation interne uniquement ou pour des tests, je retournerais probablement 401.
techniquement, les deux sont corrects, cela se résume vraiment à ce que vous voulez révéler.
renvoyer un 401 indique à l'appelant que le compte n'est pas valide, ce qui est correct, mais si votre API va ensuite être appelée à nouveau pour enregistrer un utilisateur avec les mêmes informations d'identification, cet appel échouera également. ce qui pourrait ne pas être très utile à l'appelant.
ainsi, cela dépend vraiment de la façon dont votre API sera utilisée et qui/quel est le public cible.