37. Authentification HTTP et autorisation métier

Comprendre le mécanisme

WWW-Authenticate décrit un challenge selon un schéma d’authentification. Le client et le serveur doivent partager le contrat du schéma et le contexte auquel l’identité s’applique. Une réponse signalant l’absence d’authentification ne se confond pas avec un refus d’action pour un acteur déjà identifié. Des règles de non-divulgation peuvent aussi influencer la réponse publique. Dans tous les cas, les événements internes restent corrélables sans exposer les secrets.

Raisonner et vérifier

Un encodage de credentials n’est pas un chiffrement ; le canal sécurisé et la validation restent nécessaires. Un bearer token accorde une capacité à son détenteur selon le profil prévu : le transport, le stockage, la durée et la validation du jeton font partie du modèle. Un client authentifié doit encore prouver la permission sur l’objet et l’opération demandés. Testez identité absente, jeton invalide et permission insuffisante séparément.

Challenge

WWW-Authenticate porte un challenge selon un schéma. Le champ décrit un mécanisme d’authentification. WWW-Authenticate annonce un challenge selon le schéma utilisé. Le client et le serveur doivent partager ce contrat ; un texte arbitraire ne met pas en œuvre un protocole d’authentification complet.

Bearer validé

Un bearer token doit être validé. Le nom du schéma ne vérifie pas la valeur. Recevoir Authorization: Bearer indique seulement une valeur présentée. Vérifiez preuve ou introspection, profil, durée et retrait selon le mécanisme avant de construire une identité utilisable par le métier.

Permission

Une identité valide ne donne pas tous les droits. L’autorisation porte sur l’objet et l’opération. Un utilisateur reconnu peut rester interdit sur une réservation. Contrôlez l’action sur cet objet après authentification, avec test propriétaire et tiers ; la connexion ne suffit pas à prouver cette relation.

Basic et base64

Base64 est un encodage. L’encodage est réversible sans secret. La représentation base64 du schéma Basic est réversible sans secret. Elle ne chiffre pas lab:public ; le canal doit protéger les credentials et leurs copies doivent être exclues des traces ordinaires.

Transport

Le canal doit protéger les credentials sensibles. La signature ne protège pas contre toute interception et réutilisation. Utilisez un canal authentifié et chiffré selon le contrat. Une politique de header correcte ne répare pas une transmission vers une mauvaise destination ou une validation TLS désactivée.

Catégories de refus

Une politique peut distinguer identité absente et droit insuffisant. Le contrat public doit aussi tenir compte de la non-divulgation. Distinguez dans la politique identité absente ou invalide et permission insuffisante. Le choix de réponse publique doit rester cohérent sans divulguer inutilement l’existence de ressources confidentielles.

Profil partagé

Le schéma et son profil doivent être partagés. Les règles de validation doivent être explicites. Bearer ne dit pas si le token est JWT ou opaque ni quelle audience est attendue. Documentez la validation convenue avec l’émetteur et refusez les profils qui ressemblent seulement au bon format.

Logs

Les journaux doivent éviter les credentials bruts. Le diagnostic peut utiliser des catégories et corrélations. Retirez Authorization et cookies des événements ordinaires. Une trace de diagnostic qui conserve la valeur entière peut fournir à son lecteur la même capacité que le porteur légitime.

Redirections

Un client doit éviter de transmettre ses secrets à toute redirection. La destination et le périmètre doivent être contrôlés. Réévaluez credentials lors d’un changement de destination du client HTTP. Vérifiez les règles de la bibliothèque et les sauts admis ; un secret ne doit pas suivre librement toute URL retournée.

Tests distincts

Les tests doivent distinguer token invalide et permission insuffisante. Authentification et autorisation sont deux décisions. Utilisez un token invalide pour l’authentification et un token valide d’un tiers pour l’autorisation. Ces cas isolent deux propriétés différentes et évitent qu’un rejet précoce masque une règle d’objet absente.

Atelier guidé : lire, expliquer et vérifier le code

Authorization: Basic bGFiOnB1YmxpYw==

Fixture publique : lab:public ; aucune requête réelle n’est envoyée.

La valeur Basic encode les credentials publics de laboratoire, sans les chiffrer. Décodez-la localement puis expliquez pourquoi HTTPS et minimisation des traces restent nécessaires. Aucun appel réel n’est requis pour comprendre la différence entre représentation du header, protection du canal et décision de permission.

Le schéma et l’encodage ne protègent pas seuls le secret sur le canal. Il n’y a pas cette clé de chiffrement. Le canal reste une protection nécessaire. Le serveur doit valider identité et permissions.

Travail pratique : Écrivez une matrice de réponses pour API publique, API authentifiée et action réservée au propriétaire.

Critères de correction : Testez le challenge et les messages publics sans enregistrer le token. Vérifiez que le refus de droit ne relance pas inutilement une authentification et qu’aucune mutation ne précède la décision d’autorisation.