RFC(F) 7235

From RFC.Wiki
Jump to: navigation, search
Groupe de travail sur l'ingénierie Internet (IETF) R. Fielding, Ed.
Demande de commentaires: 7235 Adobe
Obsolètes: 2616 J. Reschke, Ed.
Mises à jour: 2617 greenbytes
Catégorie: Standards Track Juin 2014
ISSN: 2070-1721

         Protocole de transfert hypertexte (HTTP / 1.1): authentification

Abstrait

   Le protocole de transfert hypertexte (HTTP) est une application sans état -
   protocole de niveau pour l'information distribuée, collaborative et hypermédia
   systèmes. Ce document définit le cadre d'authentification HTTP.

Statut de ce mémo

   Il s'agit d'un document Internet Standards Track.

   Ce document est un produit de l'Internet Engineering Task Force
   (IETF). Il représente le consensus de la communauté IETF. Il a
   a reçu un examen public et a été approuvé pour publication par le
   Groupe directeur de l'ingénierie Internet (IESG). Plus d'informations sur
   Les normes Internet sont disponibles dans la section 2 de la RFC 5741.

   Informations sur l'état actuel de ce document, tout errata,
   et comment fournir des commentaires à ce sujet
   http://www.rfc-editor.org/info/rfc7235.

Copyright

   Copyright (c) 2014 IETF Trust et les personnes identifiées comme
   auteurs de documents. Tous les droits sont réservés.

   Ce document est soumis au BCP 78 et aux mentions légales de l'IETF Trust.
   Dispositions relatives aux documents de l'IETF
   (http://trustee.ietf.org/license-info) en vigueur à la date de
   publication de ce document. Veuillez consulter ces documents
   soigneusement, car ils décrivent vos droits et restrictions en ce qui concerne
   à ce document. Les composants de code extraits de ce document doivent
   inclure le texte de la licence BSD simplifiée comme décrit dans la section 4.e de
   les dispositions légales de Trust et sont fournis sans garantie
   décrit dans la licence BSD simplifiée.

   Ce document peut contenir des éléments des documents de l'IETF ou de l'IETF
   Contributions publiées ou rendues publiques avant novembre
   10, 2008. La ou les personnes contrôlant le droit d'auteur sur certains de ces

   matériel peut ne pas avoir accordé à l'IETF Trust le droit d'autoriser
   modifications de ce matériel en dehors du processus de normalisation de l'IETF.
   Sans obtenir une licence adéquate de la ou des personnes contrôlant
   le droit d'auteur sur ces documents, ce document ne peut pas être modifié
   en dehors du processus de normalisation de l'IETF, et les travaux dérivés de celui-ci peuvent
   ne pas être créé en dehors du processus de normalisation de l'IETF, sauf pour formater
   pour publication sous forme de RFC ou pour le traduire dans d'autres langues
   que l'anglais.

Table des matières

   1. Introduction ............................................... ..... 3
      1.1. Conformité et gestion des erreurs ............................. 3
      1.2. Notation de syntaxe ........................................... 3
   2. Cadre d'authentification d'accès ........................... 3
      2.1. Défi et réponse ..................................... 3
      2.2. Espace de protection (domaine) ................................... 5
   3. Définitions des codes d'état ......................................... 6
      3.1. 401 Non autorisé ........................................... 6
      3.2. 407 Authentification proxy requise ....................... 6
   4. Définitions des champs d'en-tête ....................................... 7
      4.1. WWW-Authenticate ........................................... 7
      4.2. Autorisation .............................................. 8
      4.3. Authentification par proxy ....................................... 8
      4.4. Autorisation par procuration ....................................... 9
   5. Considérations IANA ............................................. 9
      5.1. Registre du schéma d'authentification ....................... 9
           5.1.1. Procédure ........................................... 9
           5.1.2. Considérations pour les nouveaux schémas d'authentification ...... 10
      5.2. Enregistrement du code d'état .................................. 11
      5.3. Enregistrement de champ d'en-tête ................................. 11
   6. Considérations relatives à la sécurité ....................................... 12
      6.1. Confidentialité des pouvoirs ........................... 12
      6.2. Informations d'authentification et clients inactifs ....... 12
      6.3. Espaces de protection ......................................... 13
   7. Remerciements ............................................... .14
   8. Références ............................................... ...... 14
      8.1. Références normatives ...................................... 14
      8.2. Références informatives .................................... 14
   Annexe A. Modifications des RFC 2616 et 2617 ....................... 16
   Annexe B. ABNF importé ......................................... 16
   Annexe C. ABNF collecté ....................................... 17
   Index ................................................. ............ 18

1. Introduction

   HTTP fournit un cadre général pour le contrôle d'accès et
   authentification, via un ensemble extensible de défi-réponse
   schémas d'authentification, qui peuvent être utilisés par un serveur pour contester
   demande du client et par un client pour fournir des informations d'authentification.
   Ce document définit l'authentification HTTP / 1.1 en termes de
   architecture définie dans "Hypertext Transfer Protocol (HTTP / 1.1):
   Syntaxe et routage des messages "[RFC7230], y compris le général
   précédemment décrit dans «Authentification HTTP: Basic et
   Digest Access Authentication "[RFC2617] et les champs associés et
   codes d'état précédemment définis dans "Hypertext Transfer Protocol -
   HTTP / 1.1 "[RFC2616].

   Le registre du schéma d'authentification IANA (section 5.1) répertorie
   schémas d'authentification enregistrés et leurs
   spécifications, y compris l'authentification "de base" et "digest"
   schémas précédemment définis par la RFC 2617.

1.1. Conformité et gestion des erreurs

   Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "MAI" et "FACULTATIF" dans ce
   document doivent être interprétés comme décrit dans [RFC2119].

   Les critères de conformité et les considérations concernant le traitement des erreurs sont
   défini dans la section 2.5 de la [RFC7230].

1.2. Notation de syntaxe

   Cette spécification utilise la forme Backus-Naur augmentée (ABNF)
   notation de [RFC5234] avec une extension de liste, définie dans la section 7 de
   [RFC7230], qui permet une définition compacte des éléments séparés par des virgules
   listes utilisant un opérateur '#' (similaire à la façon dont l'opérateur '*' indique
   répétition). L'annexe B décrit les règles importées d'autres
   documents. L'annexe C montre la grammaire collectée avec toutes les listes
   opérateurs étendus à la notation ABNF standard.

2. Cadre d'authentification d'accès

2.1. Défi et réponse

   HTTP fournit un cadre d'authentification simple défi-réponse
   qui peut être utilisé par un serveur pour contester une demande client et par un
   client pour fournir des informations d'authentification. Il utilise un cas-
   jeton insensible comme moyen d'identifier le schéma d'authentification,
   suivi des informations supplémentaires nécessaires pour

   authentification via ce schéma. Ce dernier peut être soit une commu-
   liste de paramètres séparée ou une seule séquence de caractères
   capable de contenir des informations codées en base64.

   Les paramètres d'authentification sont des paires nom = valeur, où le jeton de nom
   est mis en correspondance sans tenir compte de la casse, et chaque nom de paramètre DOIT uniquement
   se produire une fois par défi.

     schéma d'authentification = jeton

     auth-param = token BWS "=" BWS (token / quoted-string)

     token68 = 1 * (ALPHA / DIGIT /
                          "-" / "." / "_" / "~" / "+" / "/") * "="

   La syntaxe token68 autorise les 66 caractères URI non réservés
   ([RFC3986]), ainsi que quelques autres, afin qu'il puisse contenir une base64,
   base64url (alphabet sûr pour les URL et les noms de fichiers), base32 ou base16 (hex)
   encodage, avec ou sans remplissage, mais à l'exclusion des espaces
   ([RFC4648]).

   Un message de réponse 401 (non autorisé) est utilisé par un serveur d'origine pour
   contester l'autorisation d'un agent utilisateur, y compris un
   Champ d'en-tête WWW-Authenticate contenant au moins un défi
   applicable à la ressource demandée.

   Un message de réponse 407 (authentification proxy requise) est utilisé par un
   procuration pour contester l'autorisation d'un client, y compris un
   Champ d'en-tête Proxy-Authenticate contenant au moins un défi
   applicable au proxy de la ressource demandée.

     challenge = schéma d'authentification [1 * SP (token68 / # auth-param)]

      Remarque: de nombreux clients ne parviennent pas à analyser un défi qui contient un
      schéma inconnu. Une solution de contournement à ce problème consiste à répertorier
      les régimes pris en charge (tels que «de base») en premier.

   Un agent utilisateur qui souhaite s'authentifier auprès d'un serveur d'origine
   - généralement, mais pas nécessairement, après avoir reçu un 401 (non autorisé)
   - peut le faire en incluant un champ d'en-tête d'autorisation avec le
   demande.

   Un client qui souhaite s'authentifier avec un proxy - généralement,
   mais pas nécessairement, après avoir reçu un 407 (authentification proxy
   Obligatoire) - peut le faire en incluant un en-tête Proxy-Authorization
   champ avec la demande.

   La valeur du champ Autorisation et le champ Autorisation proxy
   La valeur contient les informations d'identification du client pour le domaine de la ressource
   étant demandé, sur la base d'un défi reçu dans une réponse
   (peut-être à un moment donné dans le passé). Lors de la création de leurs valeurs,
   l'agent utilisateur doit le faire en sélectionnant le défi avec ce qu'il
   considère qu'il s'agit du schéma d'authentification le plus sûr qu'il comprend,
   obtenir les informations d'identification de l'utilisateur, le cas échéant. Transmission de
   les informations d'identification dans les valeurs de champ d'en-tête impliquent une sécurité importante
   considérations relatives à la confidentialité du sous-jacent
   connexion, comme décrit dans la section 6.1.

     informations d'identification = schéma d'authentification [1 * SP (token68 / # auth-param)]

   À la réception d'une demande de ressource protégée qui omet
   informations d'identification, contient des informations d'identification non valides (par exemple, un mauvais mot de passe) ou
   informations d'identification partielles (par exemple, lorsque le schéma d'authentification requiert
   plus d'un aller-retour), un serveur d'origine DEVRAIT envoyer un 401
   Réponse (non autorisée) contenant un champ d'en-tête WWW-Authenticate
   avec au moins un (éventuellement nouveau) défi applicable au
   ressource demandée.

   De même, à la réception d'une demande qui omet les informations d'identification de proxy ou
   contient des informations d'identification de proxy non valides ou partielles, un proxy qui nécessite
   l'authentification DEVRAIT générer un 407 (authentification proxy requise)
   réponse qui contient un champ d'en-tête Proxy-Authenticate avec au moins
   au moins un (éventuellement nouveau) défi applicable au proxy.

   Un serveur qui reçoit des informations d'identification valides qui ne sont pas suffisantes pour
   accéder doit répondre avec le code de statut 403 (interdit)
   (Section 6.5.3 de [RFC7231]).

   HTTP ne limite pas les applications à cette simple réponse-défi
   cadre d'authentification d'accès. Des mécanismes supplémentaires peuvent être
   utilisé, comme l'authentification au niveau du transport ou par message
   encapsulation, et avec des champs d'en-tête supplémentaires spécifiant
   informations d'authentification. Cependant, ces mécanismes supplémentaires sont
   non défini par cette spécification.

2.2. Espace de protection (royaume)

   Le paramètre d'authentification "royaume" est réservé à l'usage de
   les schémas d'authentification qui souhaitent indiquer l'étendue de la protection.

   Un espace de protection est défini par l'URI racine canonique (le schéma
   et les composants d'autorité de l'URI de demande effective; voir section
   5.5 de [RFC7230]) du serveur auquel vous accédez, en combinaison avec
   la valeur du domaine si elle est présente. Ces domaines permettent aux protégés
   ressources sur un serveur à partitionner en un ensemble de protection

   espaces, chacun avec son propre schéma d'authentification et / ou autorisation
   base de données. La valeur de domaine est une chaîne, généralement attribuée par le
   serveur d'origine, qui peut avoir une sémantique supplémentaire spécifique au
   schéma d'authentification. Notez qu'une réponse peut avoir plusieurs
   défis avec le même schéma d'authentification mais avec des domaines différents.

   L'espace de protection détermine le domaine sur lequel les informations d'identification peuvent
   être appliqué automatiquement. Si une demande préalable a été autorisée,
   l'agent utilisateur PEUT réutiliser les mêmes informations d'identification pour toutes les autres demandes
   dans cet espace de protection pendant une période déterminée par le
   schéma d'authentification, paramètres et / ou préférences de l'utilisateur (comme un
   délai d'inactivité configurable). Sauf autorisation expresse du
   schéma d'authentification, un seul espace de protection ne peut pas s'étendre
   en dehors de la portée de son serveur.

   Pour des raisons historiques, un expéditeur NE DOIT générer que la chaîne entre guillemets
   syntaxe. Les destinataires peuvent avoir à prendre en charge à la fois le jeton et
   syntaxe de chaîne entre guillemets pour une interopérabilité maximale avec l'existant
   les clients qui acceptent les deux notations depuis longtemps.

3. Définitions des codes d'état

3.1. 401 non autorisé

   Le code d'état 401 (non autorisé) indique que la demande n'a pas
   été appliqué car il manque des informations 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 comprend des informations d'authentification, le 401
   la réponse indique que l'autorisation a été refusée pour ces
   identifiants. L'agent utilisateur PEUT répéter la demande avec un nouveau ou
   champ d'en-tête d'autorisation remplacé (section 4.2). Si le 401
   réponse contient le même défi que la réponse précédente, et la
   l'agent utilisateur a déjà tenté l'authentification au moins une fois, puis
   l'agent utilisateur DEVRAIT présenter la représentation ci-jointe au
   utilisateur, car il contient généralement des informations de diagnostic pertinentes.

3.2. 407 Authentification proxy requise

   Le code d'état 407 (authentification proxy requise) est similaire à 401
   (Non autorisé), mais cela indique que le client doit
   s'authentifier afin d'utiliser un proxy. Le proxy DOIT envoyer un
   Champ d'en-tête Proxy-Authenticate (Section 4.3) contenant un défi
   applicable à ce proxy pour la ressource cible. Le client PEUT
   répéter la demande avec un en-tête Proxy-Authorization nouveau ou remplacé
   (section 4.4).

4. Définitions des champs d'en-tête

   Cette section définit la syntaxe et la sémantique des champs d'en-tête
   liés au cadre d'authentification HTTP.

4.1. WWW-Authenticate

   Le champ d'en-tête "WWW-Authenticate" indique l'authentification
   schéma (s) et paramètres applicables à la ressource cible.

     WWW-Authenticate = défi 1 #

   Un serveur générant une réponse 401 (non autorisée) DOIT envoyer un
   Champ d'en-tête WWW-Authenticate contenant au moins un défi. UNE
   le serveur PEUT générer un champ d'en-tête WWW-Authenticate dans une autre réponse
   des messages pour indiquer que la fourniture d'informations d'identification (ou
   informations d'identification) peut affecter la réponse.

   Un proxy transmettant une réponse NE DOIT PAS modifier un WWW-Authenticate
   champs dans cette réponse.

   Il est conseillé aux agents utilisateurs de faire particulièrement attention à l'analyse du champ
   valeur, car il peut contenir plus d'un défi, et chaque
   le défi peut contenir une liste d'authentification séparée par des virgules
   paramètres. De plus, le champ d'en-tête lui-même peut apparaître plusieurs fois
   fois.

   Par exemple:

     WWW-Authenticate: Newauth realm = "apps", type = 1,
                       title = "Connectez-vous à \" apps \ "", domaine de base = "simple"

   Ce champ d'en-tête contient deux défis; un pour le "Newauth"
   schéma avec une valeur de domaine "apps" et deux paramètres supplémentaires
   "type" et "title", et un autre pour le schéma "Basic" avec un
   valeur de domaine "simple".

      Remarque: La production de grammaire de défi utilise la syntaxe de liste comme
      bien. Par conséquent, une séquence de virgules, d'espaces et de virgules peut
      soit être considérée comme s'appliquant au défi précédent, soit
      être une entrée vide dans la liste des défis. En pratique, cela
      l'ambiguïté n'affecte pas la sémantique de la valeur du champ d'en-tête
      et est donc inoffensif.

4.2. Autorisation

   Le champ d'en-tête "Autorisation" permet à un agent utilisateur de s'authentifier
   lui-même avec un serveur d'origine - généralement, mais pas nécessairement, après
   recevoir une réponse 401 (non autorisée). Sa valeur consiste en
   informations d'identification contenant les informations d'authentification de l'utilisateur
   agent pour le domaine de la ressource demandée.

     Autorisation = informations d'identification

   Si une demande est authentifiée et un domaine spécifié, le même
   les pouvoirs sont présumés valables pour toutes les autres demandes
   ce domaine (en supposant que le schéma d'authentification lui-même ne
   exiger autrement, telles que des informations d'identification qui varient en
   valeur de défi ou en utilisant des horloges synchronisées).

   Un proxy transmettant une demande NE DOIT PAS modifier les champs d'autorisation
   dans cette demande. Voir la section 3.2 de la [RFC7234] pour plus de détails et
   exigences relatives au traitement du champ Autorisation par
   Caches HTTP.

4.3. Authentification par proxy

   Le champ d'en-tête "Proxy-Authenticate" comprend au moins un
   défi qui indique le ou les schémas et paramètres d'authentification
   applicable au proxy pour cet URI de demande effective (section 5.5
   de [RFC7230]). Un proxy DOIT envoyer au moins un proxy-authentifier
   champ d'en-tête dans chaque réponse 407 (authentification proxy requise)
   qu'il génère.

     Authentification par proxy = défi 1 #

   Contrairement à WWW-Authenticate, le champ d'en-tête Proxy-Authenticate s'applique
   uniquement au prochain client sortant sur la chaîne de réponse. C'est
   car seul le client qui a choisi un proxy donné est susceptible d'avoir
   les informations d'identification nécessaires à l'authentification. Cependant, lorsque plusieurs
   les procurations sont utilisées dans le même domaine administratif, comme
   des mandataires de mise en cache de bureaux et régionaux au sein d'un grand réseau d'entreprise,
   il est courant que les informations d'identification soient générées par l'agent utilisateur et
   passé à travers la hiérarchie jusqu'à consommation. Par conséquent, dans un tel
   configuration, il apparaîtra comme si l'authentification par proxy est en cours
   transmis car chaque proxy enverra le même ensemble de défis.

   Notez que les considérations d'analyse pour WWW-Authenticate s'appliquent à
   ce champ d'en-tête également; voir la section 4.1 pour plus de détails.

4.4. Autorisation par procuration

   Le champ d'en-tête "Proxy-Authorization" permet au client d'identifier
   lui-même (ou son utilisateur) à un proxy qui nécessite une authentification. Ses
   la valeur se compose d'informations d'identification contenant l'authentification
   informations du client pour le proxy et / ou le domaine de la ressource
   demandé.

     Proxy-Authorization = informations d'identification

   Contrairement à l'autorisation, le champ d'en-tête Proxy-Authorization s'applique
   uniquement au prochain proxy entrant qui a demandé une authentification à l'aide de la
   Champ Proxy-Authenticate. Lorsque plusieurs proxys sont utilisés dans une chaîne,
   le champ d'en-tête Proxy-Authorization est consommé par le premier entrant
   proxy qui s'attendait à recevoir des informations d'identification. Un proxy PEUT relayer
   les informations d'identification de la demande du client au proxy suivant si tel est le cas
   le mécanisme par lequel les mandataires authentifient en coopération un
   demande.

5. Considérations IANA

5.1. Registre du schéma d'authentification

   Le schéma d'authentification «HTTP» (Hypertext Transfer Protocol)
   Registre "définit l'espace de noms pour les schémas d'authentification dans
   défis et pouvoirs. Il a été créé et est maintenant
   maintenu à <http://www.iana.org/assignments/http-authschemes>.

5.1.1. Procédure

   Les inscriptions DOIVENT inclure les champs suivants:

   o Nom du schéma d'authentification

   o Pointeur vers le texte de spécification

   o Notes (facultatif)

   Les valeurs à ajouter à cet espace de noms nécessitent une révision IETF (voir
   [RFC5226], section 4.1).

5.1.2. Considérations pour les nouveaux schémas d'authentification

   Il existe certains aspects du cadre d'authentification HTTP qui
   imposer des contraintes sur le fonctionnement des nouveaux schémas d'authentification:

   o L'authentification HTTP est présumée être sans état: tous les
      les informations nécessaires pour authentifier une demande DOIVENT être fournies
      dans la demande, plutôt que de dépendre du serveur se souvenant
      demandes préalables. Authentification basée sur, ou liée à,
      la connexion sous-jacente n'entre pas dans le cadre de cette spécification
      et intrinsèquement défectueux à moins que des mesures ne soient prises pour
      la connexion ne peut être utilisée par aucune autre partie que
      utilisateur authentifié (voir la section 2.3 de la [RFC7230]).

   o Le paramètre d'authentification "royaume" est réservé à la définition
      espaces de protection tels que décrits à la section 2.2. Les nouveaux régimes DOIVENT
      NE PAS l'utiliser d'une manière incompatible avec cette définition.

   o La notation "token68" a été introduite pour la compatibilité avec
      schémas d'authentification existants et ne peuvent être utilisés qu'une seule fois par
      défi ou accréditation. Ainsi, les nouveaux régimes devraient utiliser le
      la syntaxe auth-param à la place, car sinon les futures extensions
      sera impossible.

   o L'analyse des défis et des informations d'identification est définie par
      spécification et ne peut pas être modifié par une nouvelle authentification
      régimes. Lorsque la syntaxe auth-param est utilisée, tous les paramètres doivent
      pour prendre en charge à la fois la syntaxe de jeton et de chaîne entre guillemets et
      les contraintes doivent être définies sur la valeur du champ après l'analyse
      (c'est-à-dire, le traitement des chaînes entre guillemets). Ceci est nécessaire pour que
      les destinataires peuvent utiliser un analyseur générique qui s'applique à tous
      schémas d'authentification.

      Remarque: Le fait que la syntaxe de valeur du paramètre "realm" soit
      limité à la chaîne entre guillemets était un mauvais choix de conception pour ne pas être
      répété pour les nouveaux paramètres.

   o Les définitions des nouveaux régimes devraient définir le traitement des
      paramètres d'extension inconnus. En règle générale, une règle "à ignorer" est
      préférable à une règle "à comprendre", car sinon elle
      être difficile d'introduire de nouveaux paramètres en présence de l'héritage
      destinataires. En outre, il est bon de décrire la politique de
      définir de nouveaux paramètres (tels que «mettre à jour la spécification» ou
      "utiliser ce registre").

   o Les schémas d'authentification doivent documenter s'ils sont utilisables dans
      authentification du serveur d'origine (c'est-à-dire en utilisant WWW-Authenticate),
      et / ou l'authentification par proxy (c'est-à-dire en utilisant l'authentification par proxy).

   o Les informations d'identification portées dans un champ d'en-tête d'autorisation sont
      spécifique à l'agent utilisateur et, par conséquent, ont le même effet sur
      Les caches HTTP en tant que directive de réponse Cache-Control "privée"
      (Section 5.2.2.6 de la [RFC7234]), dans le cadre de la demande de
      qu'ils apparaissent.

      Par conséquent, de nouveaux schémas d'authentification qui choisissent de ne pas porter
      informations d'identification dans le champ d'en-tête Autorisation (par exemple, en utilisant un
      champ d'en-tête défini) devra explicitement interdire la mise en cache, en
      rendre obligatoire l'utilisation des directives de demande Cache-Control
      (par exemple, "sans magasin", section 5.2.1.5 de la [RFC7234]) ou réponse
      (par exemple, "privé").

5.2. Enregistrement du code d'état

   Le "Registre de code d'état HTTP (Hypertext Transfer Protocol)" situé
   à <http://www.iana.org/assignments/http-status-codes> a été
   mis à jour avec les inscriptions ci-dessous:

   + ------- + ------------------------------- + --------- ---- +
   | Valeur | Description | Référence |
   + ------- + ------------------------------- + --------- ---- +
   | 401 | Non autorisé | Section 3.1 |
   | 407 | Authentification proxy requise | Section 3.2 |
   + ------- + ------------------------------- + --------- ---- +

5.3. Enregistrement de champ d'en-tête

   Les champs d'en-tête HTTP sont enregistrés dans les "En-têtes de message"
   registre tenu à
   <http://www.iana.org/assignments/message-headers/>.

   Ce document définit les champs d'en-tête HTTP suivants, donc le
   Le registre "Noms des champs d'en-tête de message permanent" a été mis à jour
   en conséquence (voir [BCP90]).

   + --------------------- + ---------- + ---------- + ----- -------- +
   | Nom du champ d'en-tête | Protocole | Statut | Référence |
   + --------------------- + ---------- + ---------- + ----- -------- +
   | Autorisation | http | standard | Section 4.2 |
   | Authentification par proxy | http | standard | Section 4.3 |
   | Autorisation par procuration | http | standard | Section 4.4 |
   | WWW-Authenticate | http | standard | Section 4.1 |
   + --------------------- + ---------- + ---------- + ----- -------- +

   Le responsable du changement est: "IETF (iesg@ietf.org) - Internet
   Engineering Task Force ".

6. Considérations de sécurité

   Cette section est destinée à informer les développeurs, les fournisseurs d'informations,
   et les utilisateurs de problèmes de sécurité connus spécifiques à l'authentification HTTP.
   Des considérations de sécurité plus générales sont traitées dans la messagerie HTTP
   [RFC7230] et sémantique [RFC7231].

   Tout sur le sujet de l'authentification HTTP est une sécurité
   considération, donc la liste des considérations ci-dessous n'est pas exhaustive.
   En outre, il se limite à des considérations de sécurité concernant
   cadre d'authentification, en général, plutôt que de discuter de tous
   les considérations potentielles pour des schémas d'authentification spécifiques
   (qui devrait être documenté dans les spécifications qui définissent les
   régimes). Diverses organisations conservent des informations d'actualité et
   des liens vers les recherches en cours sur la sécurité des applications Web (par exemple,
   [OWASP]), y compris les pièges courants pour la mise en œuvre et l'utilisation du
   schémas d'authentification trouvés dans la pratique.

6.1. Confidentialité des pouvoirs

   Le cadre d'authentification HTTP ne définit pas un seul mécanisme
   pour maintenir la confidentialité des pouvoirs; à la place, chacun
   le schéma d'authentification définit la façon dont les informations d'identification sont encodées avant
   à la transmission. Bien que cela offre une flexibilité pour le développement
   des futurs schémas d'authentification, il est insuffisant pour la protection
   des systèmes existants qui n'assurent aucune confidentialité par eux-mêmes, ou
   qui ne protègent pas suffisamment contre les attaques par rejeu.
   En outre, si le serveur attend des informations d'identification spécifiques à
   chaque utilisateur individuel, l'échange de ces informations d'identification aura la
   effet d'identifier cet utilisateur même si le contenu
   les informations d'identification restent confidentielles.

   HTTP dépend des propriétés de sécurité du transport sous-jacent
   ou une connexion au niveau de la session pour fournir une transmission confidentielle de
   champs d'en-tête. En d'autres termes, si un serveur limite l'accès à
   utilisateurs authentifiés utilisant ce cadre, le serveur doit s'assurer
   que la connexion est correctement sécurisée conformément à la nature
   du schéma d'authentification utilisé. Par exemple, les services qui dépendent
   sur l'authentification des utilisateurs individuels nécessitent souvent une connexion
   sécurisé avec TLS ("Transport Layer Security", [RFC5246]) avant
   échanger des informations d'identification.

6.2. Informations d'authentification et clients inactifs

   Les clients HTTP et les agents utilisateurs existants conservent généralement l'authentification
   indéfiniment. HTTP ne fournit pas de mécanisme pour le
   serveur d'origine pour demander aux clients de supprimer ces informations d'identification mises en cache,
   puisque le protocole ne sait pas comment les informations d'identification sont obtenues

   ou géré par l'agent utilisateur. Les mécanismes d'expiration ou
   la révocation des informations d'identification peut être spécifiée dans le cadre d'une authentification
   définition du régime.

   Circonstances dans lesquelles la mise en cache des informations d'identification peut interférer avec le
   Le modèle de sécurité de l'application comprend, sans s'y limiter:

   o Clients inactifs depuis longtemps, suite à
      que le serveur peut souhaiter amener le client à ré-inviter le
      utilisateur pour les informations d'identification.

   o Les applications qui incluent une indication de fin de session (comme
      comme un bouton "déconnexion" ou "commit" sur une page) après quoi le serveur
      côté de la demande "sait" qu'il n'y a pas d'autre raison
      pour que le client conserve les informations d'identification.

   Les agents utilisateurs qui mettent en cache les informations d'identification sont encouragés à fournir un
   mécanisme facilement accessible pour rejeter les informations d'identification mises en cache sous
   contrôle utilisateur.

6.3. Espaces de protection

   Schémas d'authentification qui reposent uniquement sur le mécanisme "royaume" pour
   l'établissement d'un espace de protection exposera les informations d'identification à tous
   ressources sur un serveur d'origine. Clients qui ont réussi
   les demandes authentifiées avec une ressource peuvent utiliser les mêmes
   informations d'authentification pour d'autres ressources de même origine
   serveur. Cela permet à une autre ressource de récolter
   informations d'authentification pour d'autres ressources.

   Ceci est particulièrement préoccupant lorsqu'un serveur d'origine héberge des ressources
   pour plusieurs parties sous le même URI racine canonique (section 2.2).
   Les stratégies d'atténuation possibles comprennent la restriction de l'accès direct aux
   informations d’authentification (c.-à-d. ne pas créer le
   Champ d'en-tête de demande d'autorisation disponible) et séparation
   espaces de protection en utilisant un nom d'hôte (ou numéro de port) différent pour
   chaque fête.

7. Remerciements

   Cette spécification reprend la définition du HTTP
   Cadre d'authentification, précédemment défini dans la RFC 2617. Nous remercions
   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
   Lawrence, Paul J. Leach, Ari Luotonen et Lawrence C. Stewart pour
   leur travail sur cette spécification. Voir la section 6 de [RFC2617] pour
   remerciements supplémentaires.

   Voir la section 10 de la [RFC7230] pour les remerciements liés à ce
   révision du document.

8. Références

8.1. Références normatives

   [RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer
              Niveaux d'exigence ", BCP 14, RFC 2119, mars 1997.

   [RFC5234] Crocker, D., Ed. et P. Overell, "BNF augmenté pour la syntaxe
              Spécifications: ABNF ", STD 68, RFC 5234, janvier 2008.

   [RFC7230] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext Transfer
              Protocole (HTTP / 1.1): Syntaxe et routage des messages ",
              RFC 7230, juin 2014.

   [RFC7231] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext Transfer
              Protocole (HTTP / 1.1): sémantique et contenu ", RFC 7231,
              Juin 2014.

   [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., Et J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP / 1.1): Caching",
              RFC 7234, juin 2014.

8.2. Références informatives

   [BCP90] Klyne, G., Nottingham, M. et J. Mogul, "Inscription
              Procédures pour les champs d'en-tête de message ", BCP 90, RFC 3864,
              Septembre 2004.

   [OWASP] van der Stock, A., Ed., "Un guide pour construire un Web sécurisé
              Applications et services Web ", L'application Web ouverte
              Projet de sécurité (OWASP) 2.0.1, juillet 2005,
              <https://www.owasp.org/>.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. et T. Berners-Lee, "Hypertexte
              Protocole de transfert - HTTP / 1.1 ", RFC 2616, juin 1999.

   [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A. et L. Stewart, "HTTP
              Authentification: Authentification d'accès de base et Digest ",
              RFC 2617, juin 1999.

   [RFC3986] Berners-Lee, T., Fielding, R. et L. Masinter, "Uniform
              Identifiant de ressource (URI): syntaxe générique ", STD 66,
              RFC 3986, janvier 2005.

   [RFC4648] Josefsson, S., "Les données Base16, Base32 et Base64
              Encodings ", RFC 4648, octobre 2006.

   [RFC5226] Narten, T. et H. Alvestrand, «Guidelines for Writing an
              Section des considérations IANA dans les RFC ", BCP 26, RFC 5226,
              Mai 2008.

   [RFC5246] Dierks, T. et E. Rescorla, «The Transport Layer Security
              (TLS) Protocol Version 1.2 ", RFC 5246, août 2008.

Annexe A. Modifications des RFC 2616 et 2617

   Le cadre de l'authentification HTTP est maintenant défini par ce
   document, plutôt que RFC 2617.

   Le paramètre "royaume" n'est plus toujours requis sur les défis;
   par conséquent, l'ABNF permet des défis sans aucun paramètre d'authentification.
   (Section 2)

   L'alternative "token68" aux listes de paramètres d'authentification a été ajoutée pour
   cohérence avec les schémas d'authentification hérités tels que "Basic".
   (Section 2)

   Cette spécification introduit le registre du schéma d'authentification,
   ainsi que des considérations pour les nouveaux schémas d'authentification.
   (Section 5.1)

Annexe B. ABNF importé

   Les règles de base suivantes sont incluses par référence, comme défini dans
   Appendice B.1 de [RFC5234]: ALPHA (lettres), CR (retour chariot),
   CRLF (CR LF), CTL (contrôles), DIGIT (décimal 0-9), DQUOTE (double
   devis), HEXDIG (hexadécimal 0-9 / AF / af), LF (saut de ligne), OCTET (tout
   Séquence de données 8 bits), SP (espace) et VCHAR (tout US-ASCII visible
   personnage).

   Les règles ci-dessous sont définies dans [RFC7230]:

     BWS = <BWS, voir [RFC7230], section 3.2.3>
     OWS = <OWS, voir [RFC7230], section 3.2.3>
     quoted-string = <quoted-string, voir [RFC7230], Section 3.2.6>
     token = <token, voir [RFC7230], Section 3.2.6>

Annexe C. ABNF collecté

   Dans l'ABNF collecté ci-dessous, les règles de liste sont développées conformément à la section
   1.2 de [RFC7230].

   Autorisation = informations d'identification

   BWS = <BWS, voir [RFC7230], section 3.2.3>

   OWS = <OWS, voir [RFC7230], section 3.2.3>

   Proxy-Authenticate = * ("," OWS) challenge * (OWS "," [OWS
    défi ] )
   Proxy-Authorization = informations d'identification

   WWW-Authenticate = * ("," OWS) challenge * (OWS "," [OWS challenge
    ])

   auth-param = token BWS "=" BWS (token / quoted-string)
   schéma d'authentification = jeton

   challenge = schéma d'authentification [1 * SP (token68 / [("," / auth-param) * (
    OWS "," [OWS auth-param])])]
   informations d'identification = schéma d'authentification [1 * SP (token68 / [("," / auth-param)
    * (OWS "," [OWS auth-param])]]]]

   quoted-string = <quoted-string, voir [RFC7230], Section 3.2.6>

   token = <token, voir [RFC7230], Section 3.2.6>
   token68 = 1 * (ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/")
    * "="

Indice

4
      401 Non autorisé (code d'état) 6
      407 Authentification proxy requise (code d'état) 6

   UNE
      Champ d'en-tête d'autorisation 8

   C
      URI racine canonique 5

   g
      Grammaire
         auth-param 4
         schéma d'authentification 4
         Autorisation 8
         défi 4
         pouvoirs 5
         Authentification par proxy 8
         Autorisation par procuration 9
         token68 4
         WWW-Authenticate 7

   P
      Espace de protection 5
      Champ d'en-tête Proxy-Authenticate 8
      Champ d'en-tête Proxy-Authorization 9

   R
      Domaine 5

   W
      Champ d'en-tête WWW-Authenticate 7

Adresses des auteurs

   Roy T. Fielding (éditeur)
   Adobe Systems Incorporated
   345 Park Ave
   San Jose, CA 95110
   Etats-Unis

   Courriel: fielding@gbiv.com
   URI: http://roy.gbiv.com/

   Julian F. Reschke (éditeur)
   greenbytes GmbH
   Hafenweg 16
   Muenster, NW 48155
   Allemagne

   Courriel: julian.reschke@greenbytes.de
   URI: http://greenbytes.de/tech/webdav/