Aller au contenu principal

RFC 2617 - Authentification HTTP : Authentification d'accès de base et par condensé

Date de publication : Juin 1999
Statut : Norme Internet
Auteurs : J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart
Rend obsolète : RFC 2069
Rendu obsolète par : RFC 7235, RFC 7615, RFC 7616, RFC 7617


Résumé (Abstract)

« HTTP/1.0 » comprend la spécification d'un schéma d'authentification d'accès de base (Basic Access Authentication Scheme). Ce schéma n'est pas considéré comme une méthode sécurisée d'authentification des utilisateurs (sauf s'il est utilisé conjointement avec un système sécurisé externe tel que SSL), car le nom d'utilisateur et le mot de passe sont transmis sur le réseau en texte clair.

Ce document fournit également la spécification du cadre d'authentification (Authentication Framework) HTTP, du schéma d'authentification de base original et d'un schéma basé sur des hachages cryptographiques, appelé « Authentification d'accès par condensé » (Digest Access Authentication). Il est donc également destiné à servir de remplacement pour le RFC 2069. Certains éléments optionnels spécifiés par le RFC 2069 ont été supprimés de cette spécification en raison de problèmes découverts depuis sa publication ; d'autres nouveaux éléments ont été ajoutés pour la compatibilité, ces nouveaux éléments ont été rendus optionnels, mais sont fortement recommandés.

Comme l'authentification de base (Basic), l'authentification d'accès par condensé (Digest Access Authentication) vérifie que les deux parties à une communication connaissent un secret partagé (un mot de passe) ; contrairement à l'authentification de base, cette vérification peut être effectuée sans envoyer le mot de passe en clair, ce qui constitue la plus grande faiblesse de l'authentification de base. Comme pour la plupart des autres protocoles d'authentification, les principales sources de risques se trouvent généralement non pas dans le protocole de base lui-même, mais dans les politiques et procédures entourant son utilisation.


Statut de ce mémo (Status of this Memo)

Ce document spécifie un protocole de norme Internet pour la communauté Internet et demande des discussions et des suggestions pour son amélioration. Veuillez vous référer à l'édition actuelle des « Normes officielles des protocoles Internet » (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution de ce mémo est illimitée.


Table des matières (Table of Contents)


Concepts fondamentaux

Deux schémas d'authentification

1. Authentification de base (Basic Authentication)

  • Principe : Nom d'utilisateur et mot de passe envoyés encodés en Base64
  • Format : Authorization: Basic base64(username:password)
  • Sécurité : ⚠️ Transmission en texte clair, non sécurisé (sauf utilisation de HTTPS)
  • Cas d'usage : Applications simples, systèmes internes, combiné avec HTTPS

2. Authentification par condensé (Digest Authentication)

  • Principe : Utilise le hachage MD5, le mot de passe n'est pas transmis en clair
  • Format : Inclut nonce, realm, qop et d'autres paramètres
  • Sécurité : ✅ Plus sûr que l'authentification de base, mais HTTPS toujours recommandé
  • Cas d'usage : Authentification HTTP nécessitant une sécurité accrue

Flux d'authentification

Client                                  Serveur
| |
|------- 1. Requête ressource -------->|
| protégée |
| |
|<------ 2. 401 + WWW-Authenticate ----|
| (défi) |
| |
|------- 3. En-tête Authorization ---->|
| (identifiants) |
| |
|<------ 4. 200 OK + ressource --------|
| |

Codes d'état HTTP

  • 401 Unauthorized : Authentification requise
  • 407 Proxy Authentication Required : Authentification proxy requise

En-têtes HTTP clés

  • WWW-Authenticate : Défi envoyé par le serveur
  • Authorization : Identifiants envoyés par le client
  • Authentication-Info : Informations d'authentification optionnelles
  • Proxy-Authenticate : Défi du serveur proxy
  • Proxy-Authorization : Identifiants envoyés au proxy

Exemples

Exemple d'authentification de base

Réponse du serveur :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WallyWorld"

Requête du client :

GET /private/index.html HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Exemple d'authentification par condensé

Réponse du serveur :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

Requête du client :

GET /dir/index.html HTTP/1.1
Authorization: Digest username="Mufasa",
realm="[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

Ressources associées

  • Texte officiel : RFC 2617 (TXT)
  • Page officielle : RFC 2617 DataTracker
  • Rend obsolète : RFC 2069
  • Rendu obsolète par :
    • RFC 7235 (HTTP/1.1 Authentication)
    • RFC 7615 (HTTP Authentication-Info)
    • RFC 7616 (HTTP Digest Access Authentication)
    • RFC 7617 (HTTP Basic Authentication)

Avertissement de sécurité ⚠️

  1. L'authentification de base n'est pas sécurisée : doit être utilisée avec HTTPS
  2. L'authentification par condensé a des limitations : bien que meilleure que l'authentification de base, HTTPS reste recommandé
  3. Alternatives modernes : considérer l'utilisation d'OAuth 2.0, JWT ou d'autres mécanismes d'authentification modernes
  4. Stockage des mots de passe : les serveurs devraient stocker les mots de passe en utilisant des hachages salés

Avis important : Le RFC 2617 a été rendu obsolète par les RFC 7235, 7616, 7617 et d'autres. Les applications modernes devraient se référer à ces normes mises à jour, ou utiliser des frameworks d'authentification modernes tels qu'OAuth 2.0.