Aller au contenu principal

RFC 7235 - HTTP/1.1: Authentification (Authentication)

  • Statut: Proposed Standard
  • Publié: June 2014
  • Stream: IETF
  • Remplace: RFC2616, RFC2617
  • Remplacé par: RFC9110
  • Errata: Pas d'errata

Informations sur le document​

  • Numéro RFC: 7235
  • Titre: Hypertext Transfer Protocol (HTTP/1.1): Authentication
  • Titre (Français): Protocole de transfert hypertexte (HTTP/1.1): Authentification
  • Date de publication: Juin 2014
  • Auteurs: R. Fielding (Adobe), J. Reschke (greenbytes)
  • Remplace le document: RFC 2616, RFC 2617 (partiellement)
  • Statut: Standards Track (Piste des normes)

Résumé​

HTTP fournit un framework d'authentification défi-réponse simple, où les serveurs peuvent défier les requêtes des clients et les clients peuvent fournir des informations d'authentification. Ce document définit le mécanisme général du framework d'authentification HTTP, y compris les codes de statut 401, 407 et les champs d'en-tête associés.

Concepts fondamentaux​

Flux d'authentification HTTP​

1. Le client demande une ressource protégée
   → GET /admin HTTP/1.1

2. Le serveur renvoie un défi
   ← HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Basic realm="Admin Area"

3. Le client fournit des identifiants
   → GET /admin HTTP/1.1
     Authorization: Basic dXNlcjpwYXNzd29yZA==

4. Le serveur vérifie et répond
   ← HTTP/1.1 200 OK
     [Contenu protégé...]

Schémas d'authentification (Authentication Schemes)​

HTTP prend en charge plusieurs schémas d'authentification:

  • Basic: Authentification de base (RFC 7617)
  • Bearer: Jeton Bearer (RFC 6750)
  • Digest: Authentification Digest (RFC 7616)
  • OAuth: Authentification OAuth (RFC 6749)

401 Unauthorized​

Indique que la requête ne contient pas d'informations d'authentification valides.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WallyWorld"
Content-Type: text/html
Content-Length: 0

Important: Le nom "Unauthorized" de 401 signifie en fait Unauthenticated (Non authentifié).

407 Proxy Authentication Required​

Indique que le client doit d'abord s'authentifier auprès du proxy.

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Proxy Access"

En-tête WWW-Authenticate​

Le serveur utilise cet en-tête pour définir un défi d'authentification.

Syntaxe de base​

WWW-Authenticate: &lt;scheme> realm="&lt;realm>" [, <param>=&lt;value>]*

Exemples​

Défi unique:

WWW-Authenticate: Basic realm="Admin Area"

Défis multiples (le client peut choisir):

WWW-Authenticate: Bearer realm="API", Basic realm="API"

Avec paramètres supplémentaires:

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

Paramètre realm​

realm (domaine) définit la portée de l'espace protégé:

WWW-Authenticate: Basic realm="Zone d'administration"
  • Généralement affiché dans la boîte de dialogue d'authentification du navigateur
  • Aide les utilisateurs à comprendre quels identifiants sont nécessaires
  • Les ressources avec le même realm partagent les identifiants

En-tête Authorization​

Le client utilise cet en-tête pour fournir des informations d'authentification.

Syntaxe de base​

Authorization: &lt;scheme> &lt;credentials>

Exemples​

Authentification Basic:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Jeton Bearer:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Authentification Digest:

Authorization: Digest username="user",
    realm="[email protected]",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    uri="/dir/index.html",
    response="6629fae49393a05397450978507c4ef1"

Proxy-Authenticate et Proxy-Authorization​

Utilisés pour l'authentification proxy, fonctionnent de manière similaire à WWW-Authenticate et Authorization.

Flux d'authentification proxy​

1. Requête du client
   → GET http://example.com/ HTTP/1.1

2. Le proxy demande l'authentification
   ← HTTP/1.1 407 Proxy Authentication Required
     Proxy-Authenticate: Basic realm="Proxy"

3. Le client fournit des identifiants
   → GET http://example.com/ HTTP/1.1
     Proxy-Authorization: Basic cHJveHk6cGFzc3dvcmQ=

4. Le proxy transfère la requête
   [Proxy] → GET / HTTP/1.1
            Host: example.com

Authentification Basic (RFC 7617)​

Le schéma d'authentification le plus simple mais le moins sécurisé.

Encoder les identifiants​

// 1. Combiner nom d'utilisateur et mot de passe
const credentials = "username:password";

// 2. Encodage Base64
const encoded = btoa(credentials);
// Résultat: "dXNlcm5hbWU6cGFzc3dvcmQ="

// 3. Construire l'en-tête Authorization
const auth = `Basic ${encoded}`;

Exemple complet​

GET /admin HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Avertissement de sécurité​

Danger: L'authentification Basic transmet les identifiants encodés en Base64, ce n'est pas du chiffrement!

dXNlcm5hbWU6cGFzc3dvcmQ= 
  ↓ Décodage Base64
username:password

HTTPS doit être utilisé:

✗ http://example.com + Basic Auth = Transmission en clair
✓ https://example.com + Basic Auth = Transmission chiffrée

Authentification Bearer Token (RFC 6750)​

Un schéma d'authentification couramment utilisé pour les API Web modernes.

Scénarios d'utilisation​

Généralement utilisé avec OAuth 2.0:

1. L'utilisateur se connecte, obtient un jeton d'accès
   ← { "access_token": "eyJhbG...", "token_type": "Bearer" }

2. Utiliser le jeton pour accéder à l'API
   → GET /api/user HTTP/1.1
     Authorization: Bearer eyJhbG...

Exemple​

GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Réponse d'erreur​

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="API",
                  error="invalid_token",
                  error_description="The access token expired"

Authentification Digest (RFC 7616)​

Plus sécurisée que Basic, mais plus complexe.

Caractéristiques​

  • Ne transmet pas directement le mot de passe
  • Utilise un mécanisme défi-réponse
  • Empêche les attaques par rejeu (via nonce)

Flux simplifié​

1. Le serveur envoie un défi (avec nonce)
   ← WWW-Authenticate: Digest realm="...", nonce="..."

2. Le client calcule la réponse
   response = MD5(
       MD5(username:realm:password) :
       nonce :
       MD5(method:uri)
   )

3. Le client envoie la réponse
   → Authorization: Digest username="...", response="..."

Scénarios d'application pratiques​

Scénario 1: Connexion d'application Web​

Formulaire traditionnel + Session (recommandé):

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=user&password=pass

→ HTTP/1.1 302 Found
  Set-Cookie: sessionid=abc123; HttpOnly; Secure

Ne pas utiliser HTTP Basic Auth (sauf via HTTPS).

Scénario 2: Authentification API​

Bearer Token (recommandé):

GET /api/users HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Scénario 3: Protection de l'interface d'administration​

Basic Auth + HTTPS (scénarios simples):

GET /admin HTTP/1.1
Host: secure.example.com
Authorization: Basic YWRtaW46c2VjcmV0

Scénario 4: Authentification entre microservices​

TLS mutuel + Bearer Token:

GET /internal/service HTTP/1.1
Host: internal.example.com
Authorization: Bearer service-token-123

Authentification vs. Autorisation​

Différence​

Authentification (Authentication): "Qui êtes-vous?"

Authorization: Bearer [jeton d'identité]

Autorisation (Authorization): "Que pouvez-vous faire?"

Permissions contenues dans le jeton:
{
  "user_id": "123",
  "roles": ["admin", "editor"],
  "permissions": ["read", "write", "delete"]
}

Codes de statut HTTP​

  • 401 Unauthorized: Échec de l'authentification ou absence d'authentification
  • 403 Forbidden: Authentification réussie, mais pas de permission
L'utilisateur A tente d'accéder à une ressource d'administrateur:
→ Non connecté → 401 Unauthorized
→ Connecté (utilisateur normal) → 403 Forbidden
→ Connecté (administrateur) → 200 OK

Meilleures pratiques​

Côté serveur​

  1. Toujours utiliser HTTPS

    ✓ https://api.example.com
    ✗ http://api.example.com

  2. Fournir un realm clair

    WWW-Authenticate: Bearer realm="My API v1"

  3. Prendre en charge plusieurs schémas d'authentification

    WWW-Authenticate: Bearer realm="API", Basic realm="API"

  4. Limiter les tentatives échouées

    • Implémenter la limitation de débit
    • Enregistrer les tentatives d'authentification échouées
    • Envisager le verrouillage temporaire de compte

  5. Stocker les identifiants en toute sécurité

    • Mots de passe avec hachage fort (bcrypt, Argon2)
    • Jetons avec générateur aléatoire sécurisé

Côté client​

  1. Stocker les jetons en toute sécurité

    // ✓ Recommandé
    sessionStorage.setItem('token', token);

    // ✗ Éviter (risque XSS)
    localStorage.setItem('token', token);

  2. Gérer les réponses 401

    if (response.status === 401) {
        // Effacer le jeton local
        // Rediriger vers la page de connexion
    }

  3. Actualisation du jeton

    // Actualiser automatiquement le jeton avant l'expiration
    if (tokenExpiresIn &lt; 5 * 60) {
        refreshToken();
    }

Considérations de sécurité​

1. Attaques de l'homme du milieu​

Risque: Transmission non chiffrée des identifiants

Défense: Utiliser HTTPS

✗ HTTP + Basic: Identifiants en clair volés
✓ HTTPS + Basic: Transmission chiffrée, sécurisé

2. Attaques par rejeu​

Risque: Un attaquant intercepte et rejoue les requêtes d'authentification

Défense:

  • Utiliser des jetons à courte durée
  • Implémenter un mécanisme nonce
  • Lier le jeton à un client spécifique

3. Fuite d'identifiants​

Risque: Les identifiants sont enregistrés ou divulgués

Défense:

  • Ne pas transmettre d'identifiants dans l'URL
  • Utiliser des jetons d'accès à courte durée
  • Implémenter un mécanisme de jeton de rafraîchissement
✗ https://api.example.com/data?token=abc123
✓ Authorization: Bearer abc123

4. Attaques XSS​

Risque: Des scripts malveillants volent les jetons

Défense:

  • Utiliser des cookies HttpOnly
  • Implémenter des politiques CSP
  • Valider et nettoyer les entrées

Résumé​

L'authentification HTTP fournit un framework flexible:

  • Confiance: Implémenter avec précision les protocoles d'authentification, garantir la sécurité
  • Clarté: Exprimer clairement les exigences d'authentification, faciliter la mise en œuvre côté client
  • Élégance: Concevoir élégamment les flux d'authentification, améliorer l'expérience utilisateur

Principes fondamentaux:

  1. Toujours utiliser HTTPS
  2. Choisir le schéma d'authentification approprié pour le scénario
  3. Implémenter une stratégie de défense en profondeur
  4. Faire tourner régulièrement les identifiants

Recommandations modernes:

  • Applications Web: OAuth 2.0 + OpenID Connect
  • API: Bearer Token (JWT)
  • Scénarios simples: Basic + HTTPS
  • Éviter: Digest (obsolète et complexe)

Documents associés:

  • RFC 7617: Authentification Basic
  • RFC 7616: Authentification Digest
  • RFC 6750: Bearer Token
  • RFC 6749: OAuth 2.0

Retour à la série HTTP/1.1