Échec de la signalisation de l'authentification dans une API RESTful

Question

J'écris une petite application qui expose une simple API HTTP REST. Je suis coincé pour essayer de décider comment signaler un échec dû à un manque d'autorisation.

L'application ne dispose pas d'une API pour l'authentification, mais dépend plutôt de la présence d'un cookie contenant un jeton de session obtenu par le client via un autre service. L'application vérifie la session et utilise l'identité obtenue via le processus de vérification pour effectuer une autorisation spécifique à l'application. Il n’existe aucun moyen pour un client de s’authentifier directement auprès de cette application.

Mon problème est que le code de statut HTTP évident pour le rejet de demandes non autorisées, "401 Unauthorized", est spécifié en termes de "WWW-Authenticate". entête. Voir rfc2616 sec 10.4.2 .

  

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.

Je ne peux pas croire que ce soit un problème inhabituel. Est-il courant de simplement surcharger 401 pour inclure des utilisations plus générales? Qu'en est-il des navigateurs qui ouvrent des boîtes de dialogue auth / e (ce que je n'ai d'ailleurs pas vu lors de mes tests, alors peut-être que cela ne se produit pas pour les POST)?

Conclusion: est-il possible d’utiliser 401 dans ce contexte ou existe-t-il une meilleure solution?

Answer 1

Généralement, vous envoyez un message 401 si le client peut s’authentifier et résoudre le problème, mais comme vous ne fournissez pas de moyen d’authentification dans l’API, je vous suggère de renvoyer une erreur 403 (interdite). Cela ne nécessitera pas l'en-tête et indiquera au client qu'il est incapable d'accéder au service.

Answer 2

Retourner quelque chose comme ceci:

HTTP/1.1 401 Unauthorized
Location: https://example.com/auth-app/login