web-dev-qa-db-fra.com

Autorisation dans l'API HTTP RESTful, 401 WWW-Authenticate

Je crée un service RESTful pour fournir des données à une application Web. J'ai deux questions liées à ce sujet.

1. Comment traiter les demandes non autorisées?

J'ai l'intention de répondre aux demandes avec les codes suivants:

  • La ressource est-elle ouverte et trouvée? 200 OK
  • Avez-vous besoin d'être authentifié pour accéder aux ressources? 401 Non autorisé
  • Vous n'avez pas accès à une catégorie de ressources? 403 Interdit
  • Avez-vous accès à une catégorie de ressources, mais pas à cette ressource spécifique? 404 Introuvable pour empêcher les personnes de connaître l'existence d'une ressource à laquelle elles n'ont pas accès.
  • La ressource n'existe-t-elle pas? 404 Introuvable

Est-ce une façon recommandée pour un service RESTful de se comporter?

2. Quel en-tête WWW-Authenticate les réponses 401 devraient-elles fournir?

J'ai lu sur Wikipedia (probablement pas la ressource la plus précise, mais cela fonctionne pour moi) qu'une réponse 401 doit inclut un en-tête WWW-Authenticate; cela indiquait ce que cette valeur signifie et ce qu'elle devrait être.

J'ai trouvé plusieurs SO questions et sujets de forum à propos de cet en-tête et ils semblent tous concerner OAuth. Nous vous suggérons de ne pas utiliser les codes d'état 401 ou de dire que vous pouvez simplement inventer quelque chose.

Quelle est la valeur correcte que cet en-tête doit contenir?

34
Aidiakapi

Pour répondre à vos questions:

Comment traiter les demandes non autorisées?

La façon dont vous l'avez décrite est à peu près la méthode recommandée pour un service RESTful. Autant que je sache, il n’ya absolument rien de mal à cela.

Quel en-tête WWW-Authenticate devrait fournir 401 réponses?

En général, l'en-tête WWW-Authenticate indique au client le type d'authentification que le serveur acceptera. Si le client effectue une demande non autorisée, ce qui signifie qu'il envoie une demande avec un en-tête Authorization manquant ou non valide, le serveur utilisera WWW-Authenticate pour indiquer au client le schéma d'authentification qu'il acceptera (par exemple, Basic, Digest ou OAuth) et pour quel .

Imaginez que cela ressemble à une sorte de question d’identification ou de défi de la part du serveur, c’est-à-dire quelque chose comme "Qui êtes-vous?" ou "Prouvez qui vous êtes en fournissant des informations d'identification de la manière suivante!".

Par exemple: WWW-Authenticate: Basic realm="My App"

Ici, le serveur indique au client qu’il utilise un schéma d’authentification nommé Basic. Le royaume n'est rien de plus qu'une chaîne identifiant un espace protégé sur le serveur.

21
benjiman

Sur la base de mes recherches (googler), j’ai décidé d’envoyer: Newauth realm = "use login token".

Le site Web http://greenbytes.de/tech/tc/httpauth/#unknown présente des cas de test pour différentes méthodes d'authentification et je n'ai trouvé aucun élément décrivant 'get auth token' et je pense donc qu'il 'Newauth'.

Également important pour moi: cela ne crée pas d'invite de connexion côté client.

0
sigi