Code d'état HTTP 401 ou 403 ? Comment les erreurs d'authentification et d'autorisation diffèrent
401 Non autorisé indique que le client n'est pas authentifié et nécessite des informations d'identification valides. 403 Interdit signifie que le client est authentifié mais n'a pas les permissions nécessaires pour accéder à la ressource.
GuamianProduct & Design
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Chaque fois que vous chargez une page web, effectuez un paiement ou vous connectez à une application, une conversation invisible a lieu entre votre appareil et un serveur. C'est un peu comme envoyer un message et attendre une réponse : parfois c'est un pouce levé, parfois c'est un courtois « réessayez », et, occasionnellement, c'est un net « non ». Ces réponses, connues sous le nom de codes d'état HTTP, sont les héros méconnus de l'internet, guidant silencieusement le flux de communication et s'assurant que tout fonctionne bien—ou du moins vous informant quand ce n'est pas le cas.
Les codes d'état HTTP ressemblent à des signaux dans une conversation entre un client (comme votre navigateur ou application) et un serveur. Ils fournissent des mises à jour rapides et claires sur ce qui s'est passé lorsque vous avez fait une demande—si tout s'est bien passé, si quelque chose a mal tourné, ou si une action supplémentaire est nécessaire. Imaginons cela comme visiter une boulangerie bien gérée :
Vous demandez un croissant, et le boulanger sourit, vous le tend, et dit, « Voilà ! » C'est un 200 OK HTTP—la demande a été couronnée de succès, et tout fonctionnait comme prévu.
Le 200 OK HTTP est l'un des codes les plus couramment utilisés, indiquant que la demande du client a été reçue, comprise et traitée avec succès par le serveur.
Vous arrivez à votre boulangerie préférée, mais il y a un panneau indiquant, « Nous avons déménagé au 123 New Street. » C'est un 301 Déplacé de manière permanente. Le serveur indique à votre navigateur de se rendre automatiquement à la nouvelle adresse.
Le code d'état HTTP 301 Déplacé de manière permanente indique que la ressource demandée a été définitivement déplacée vers une nouvelle URL. Ce code d'état informe le client (par exemple, un navigateur ou un client API) de mettre à jour ses enregistrements et d'utiliser la nouvelle URL pour les futures demandes.
Vous demandez un scone au chocolat, et le boulanger dit, « Nous ne fabriquons pas ceux-ci ici. » C'est un 404 Non trouvé—la ressource que vous recherchez n'existe pas sur le serveur.
Le code d'état HTTP 404 Non trouvé indique que le serveur n'a pas pu trouver la ressource demandée. Cette réponse signifie que la demande du client était valide, mais que le serveur ne pouvait pas localiser la ressource demandée.
Vous essayez d'entrer dans le salon VIP, mais le videur vous arrête et dit, « Vous devez montrer votre carte de membre. » C'est un 401 Non autorisé—l'authentification est requise avant que vous puissiez accéder à la ressource.
Le code d'état HTTP 401 Non autorisé indique que la demande du client n'a pas été appliquée car elle manque d'informations d'identification d'authentification valides. Le serveur exige que le client s'authentifie pour accéder à la ressource demandée.
Vous montrez votre carte de membre, mais le videur dit, « Seuls les membres platine peuvent entrer. » C'est un 403 Interdit—vous êtes authentifié mais vous n'avez pas les permissions nécessaires pour accéder à la ressource.
Le code d'état HTTP 403 Interdit indique que le serveur comprend la demande du client mais refuse de la satisfaire car le client ne dispose pas des permissions nécessaires. Ceci est différent d'un statut 401 Non autorisé, car le client est authentifié (ou la demande ne nécessite pas d'authentification), mais l'accès à la ressource est explicitement refusé.
Vous passez une commande, mais soudainement de la fumée commence à sortir de la cuisine. Le boulanger dit, « Nous ne pouvons pas honorer votre commande; quelque chose a mal tourné en interne. » C'est un 500 Erreur interne du serveur—le serveur a rencontré un problème inattendu.
Le code d'état HTTP 500 Erreur interne du serveur indique que le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la demande. Il s'agit d'une réponse d'erreur générique et ne fournit pas de détails spécifiques sur ce qui a mal tourné.
Vous visitez la boulangerie, mais il y a un panneau « Fermé pour maintenance ». La boulangerie rouvrira plus tard. C'est un 503 Service indisponible—le serveur est temporairement incapable de répondre à votre demande, souvent en raison d'une surcharge ou d'une maintenance.
Le code d'état HTTP 503 Service indisponible indique que le serveur est temporairement incapable de traiter la demande. Cela pourrait être dû à une surcharge du serveur, une maintenance, ou d'autres conditions temporaires. Contrairement à un 500 Erreur interne du serveur, un 503 implique que le problème devrait être résolu bientôt.
Les codes d'état HTTP sont essentiels pour maintenir une communication efficace entre les clients et les serveurs. Ils informent rapidement les clients si leurs demandes ont réussi, échoué, ou nécessitent une action supplémentaire. Pour les développeurs et les professionnels de l'informatique, comprendre ces codes aide à déboguer les problèmes, concevoir un meilleur traitement des erreurs, et améliorer l'expérience utilisateur globale.
Considérez-les comme des signaux professionnels et standardisés dans la conversation continue de l'internet.
Dans cet article, je souhaite me concentrer sur les erreurs 401 et 403, car elles sont étroitement liées à l'authentification (AuthN) et à l'autorisation (AuthZ).
Le code d'état HTTP 401 Non autorisé est utilisé lorsque la demande du client nécessite une authentification, mais elle est soit manquante, invalide, ou échouée. Cela informe le client qu'il doit s'authentifier pour accéder à la ressource demandée. La relation entre authentification et le code d'état 401 Non autorisé réside dans le rôle de l'authentification pour déterminer si une demande peut se poursuivre.
401 non autorisé doit inclure un en-tête WWW-Authenticate, fournissant des détails sur la manière de s'authentifier.
Alors, quels sont les scénarios courants pour utiliser 401 Non autorisé?
Authentification manquante
La demande ne comprend pas les informations d'identification d'authentification requises. Par exemple : Une demande à un point d'extrémité API protégé est effectuée sans en-tête Authorization.
Le client fournit des informations d'identification, mais elles sont incorrectes ou ne correspondent pas à ce que le serveur attend. Par exemple, un utilisateur envoie une clé API invalide ou un jeton mal formé.
Jeton d'authentification expiré
Le jeton d'authentification est valide mais a expiré, nécessitant que le client se ré-authentifie. Par exemple, un jeton JWT avec une date d'expiration passée (revendication exp).
En-tête de l'autorisation manquant ou mal formé
L'en-tête de l'autorisation est requis mais n'est pas fourni ou incorrectement formaté.
Schéma d'authentification non pris en charge
Le serveur ne prend pas en charge la méthode d'authentification fournie par le client. Par exemple : Le client envoie un en-tête d'authentification Basic, mais le serveur ne supporte que les jetons Bearer.
Session invalide ou révocation du jeton
La session de l'utilisateur a été invalidée, ou son jeton a été révoqué. Par exemple : Un utilisateur se déconnecte, mais le même jeton est utilisé pour accéder à une ressource protégée.
Le code d'état HTTP 403 Interdit signifie que le serveur comprend la demande et l'identité du client (si authentifié) mais refuse l'accès en raison de permissions insuffisantes. Cela signale clairement : « Vous n'êtes pas autorisé à faire cela, » assurant des limites d'accès claires et renforçant les politiques de sécurité.
La distinction entre 401 Non autorisé et 403 Interdit réside dans leurs rôles dans les contextes d'authentification et d'autorisation.
L'autorisation est un mécanisme distinct de l'authentification. Alors que l'authentification identifie qui vous êtes, l'autorisation détermine si vous pouvez accéder à des ressources spécifiques et quelles actions vous pouvez y effectuer.
Pour consulter la différence détaillée entre authN et authZ, consultez les articles suivants.
Alors, quels sont les scénarios courants pour utiliser 403 Interdit?
Authentifié mais sans permission
Le client est connecté ou authentifié mais ne dispose pas des permissions ou du rôle requis. Par exemple, un utilisateur avec un rôle « spectateur » essaie de supprimer un fichier, ce qui nécessite des privilèges d'« éditeur ».
Accès restreint à la ressource
L'accès à la ressource est intentionnellement restreint à certains utilisateurs ou groupes. Par exemple : Un document privé partagé avec des utilisateurs spécifiques est consulté par quelqu'un qui n'est pas sur la liste d'accès.
Blocage IP ou géographique
L'adresse IP du client ou sa localisation géographique est bloquée par le serveur. Par exemple : un utilisateur d'une région restreinte essaie d'accéder à un service qui ne fonctionne que dans certains pays.
Actions bloquées par politique
Le client tente une action interdite par les politiques ou règles côté serveur. Par exemple : un utilisateur essaie de modifier une ressource marquée comme « lecture seule ».
Ressources statiques bloquées
Le serveur refuse l'accès à certains fichiers ou répertoires statiques pour des raisons de sécurité.
Exemple : Un utilisateur essaie d'accéder à un fichier .htaccess ou à un fichier de configuration du serveur.
Compte suspendu ou désactivé
Le compte du client est désactivé ou bloqué en raison de violations ou d'un manque d'activité. Par exemple : Un utilisateur avec un compte suspendu essaie de se connecter ou d'accéder à des ressources.
Action nécessitant des permissions élevées
L'action demandée nécessite des privilèges spéciaux (par exemple, administrateur ou superutilisateur). Par exemple : Un utilisateur standard essaie d'accéder à des points de terminaison réservés aux administrateurs.
Exemple de réponse:
Comment puis-je dépanner une erreur 401 non autorisée#
Une erreur 401 indique généralement qu'une authentification est requise et a échoué.
Assurez-vous que l'en-tête Authorization est présent et correctement formaté, et vérifiez que les informations d'identification (clé API, jeton ou mot de passe) sont correctes et non expirées. Entrer un mauvais nom d'utilisateur ou mot de passe est l'une des causes les plus fréquentes d'une erreur 401.
Le serveur peut attendre une méthode d'authentification différente de celle qui est fournie. Cela peut arriver si le client et le serveur ne sont pas alignés sur le protocole d'authentification. Utilisez la méthode correcte (par exemple, Basic, Bearer, clé API) comme spécifié par le serveur et vérifiez la syntaxe correcte dans les en-têtes.
Confirmez que le point de terminaison, les paramètres de requête, et l'hôte sont corrects et assurez-vous que la ressource que vous essayez d'accéder nécessite une authentification.
Décodez et examinez le jeton (par exemple, avec https://logto.io/jwt-decoder) pour sa validité, expiration, et revendications, et assurez-vous que le public (aud) du jeton correspond aux exigences de l'API.
Une erreur 403 interdit signifie généralement que le processus d'autorisation a été complété, mais l'accès a été refusé. Pour dépanner cette erreur, envisagez les conditions suivantes :
Confirmez que votre compte, clé API, ou jeton a les permissions requises pour la ressource. Vérifiez si la ressource est restreinte à des rôles ou des groupes spécifiques.
Confirmez que la ressource demandée existe et que vous y avez accès. Si vous utilisez des API, vérifiez les exigences du point de terminaison dans la documentation.
Examinez le corps de la réponse pour obtenir des détails expliquant la raison de l'erreur 403.
Une seule demande peut-elle renvoyer les codes d'état 401 et 403#
Non, une seule requête HTTP ne peut pas renvoyer les codes d'état 401 Non autorisé et 403 Interdit simultanément car une réponse HTTP ne peut inclure qu'un seul code d'état.
L'utilisation pratique des codes d'erreur 401 et 403 dans l'authentification et l'autorisation#
Dans le développement d'applications modernes, 401 Non autorisé et 403 Interdit sont deux codes d'état HTTP que les développeurs rencontrent fréquemment. Bien qu'ils puissent sembler similaires, leurs significations et cas d'utilisation sont nettement différents. Pour clarifier leurs différences, cet article explore des exemples pratiques de ces codes dans des scénarios comme l'authentification, l'autorisation, la multi-location et l'authentification multi-facteurs (MFA).
Scénario de connexion : Un utilisateur essaie d'accéder à une page protégée sans se connecter ou fournir des informations d'identification valides. Le serveur répond et renvoie une erreur 401 Non autorisé : « Vous devez vous connecter ou fournir des informations d'identification valides pour accéder à cette page. »
Scénario de contrôle d'accès : Le même utilisateur se connecte avec succès mais essaie d'accéder à une page réservée aux administrateurs sans le rôle d'administrateur requis. Le serveur répond et renvoie un 403 Interdit : « Vous êtes connecté, mais vous n'avez pas la permission d'accéder à cette page. »
Scénario multi-locataire : Le même utilisateur se connecte mais appartient à Tenant A et essaie d'accéder à une ressource dans Tenant B, où il n'a pas accès. Le serveur répond et renvoie un 403 Interdit : « Vous êtes authentifié, mais vous n'avez pas la permission d'accéder à cette ressource dans Tenant B. »
Scénario MFA : Un utilisateur essaie de se connecter mais n'a pas terminé l'authentification multi-facteurs (MFA) requise. Le serveur répond et renvoie une erreur 401 Non autorisé : « L'authentification est incomplète. Veuillez compléter la MFA pour continuer. »
Utiliser Logto comme fournisseur d'authentification et d'autorisation#
Logto est principalement un fournisseur d'authentification, offrant des méthodes clés telles que la connexion sans mot de passe, l'email et mot de passe, la MFA, le SSO d'entreprise, et la connexion sociale, le tout basé sur des protocoles open-standard tels que OIDC, OAuth 2.0, et SAML.
