Un script d'automatisation doit envoyer un bearer token lors de l'appel d'une API REST de contrôleur via HTTPS. Où ce jeton est-il le plus couramment inclus ?
Choisissez la meilleure réponse.
Bonne réponse
Les bearer tokens sont généralement envoyés dans l'en-tête HTTP Authorization. Les paramètres de requête ou les corps de requête peuvent transporter des identifiants dans certaines API personnalisées, mais le modèle REST standard est un en-tête Authorization tel que 'Authorization: Bearer <token>'.
Dans l'en-tête HTTP Authorization
La norme RFC 6750 spécifie qu'un bearer token est transmis dans l'en-tête de requête HTTP Authorization en utilisant le schéma d'authentification Bearer (par exemple, `Authorization: Bearer <token>`). Cet en-tête est analysé par le serveur de ressources pour valider l'identité et les permissions du client avant de traiter la requête. Étant donné que HTTP est le protocole de couche application utilisé pour les API REST, c'est le seul emplacement correct pour le jeton parmi les options listées.
Dans le trailer Ethernet
Le trailer Ethernet contient la séquence de contrôle de trame (FCS), une valeur CRC utilisée uniquement pour la détection d'erreurs à la couche 2, et non pour transporter des données d'application. Les jetons tels que les bearer tokens sont générés par des services d'authentification et doivent être présentés dans la couche HTTP afin que le serveur web puisse les traiter. Placer un jeton dans le trailer le rendrait invisible pour les protocoles de couches supérieures et il serait supprimé par la carte réseau (NIC) bien avant que l'application ne puisse y accéder.
Dans la section de réponse DNS
Les réponses DNS transportent des enregistrements de ressources (comme A, AAAA ou TXT) dans la section de réponse, qui servent à résoudre des noms de domaine en adresses IP ou en autres données liées au domaine. L'autorisation d'API REST est une préoccupation de couche application qui se produit après l'établissement de la connexion TCP et l'envoi de la requête HTTP, elle n'a donc aucun rapport avec le processus de résolution DNS. Un bearer token ne peut pas être délivré via le DNS car le serveur DNS ne transmet pas de données d'application arbitraires vers l'endpoint HTTP.
Dans le champ de checksum TCP
Le champ de checksum TCP est une valeur de 16 bits calculée sur l'en-tête TCP, le pseudo-en-tête et la charge utile (payload) pour garantir l'intégrité des données pendant le transport. Il est recalculé à chaque saut et vérifié par le récepteur, et toute modification de celui-ci entraînerait le rejet du segment comme corrompu. Les bearer tokens ne font pas partie des métadonnées de la couche transport ; ils doivent être inclus dans la requête HTTP elle-même afin que l'application puisse authentifier l'utilisateur, et non être enfouis dans un checksum qui n'est jamais exposé à la couche application.
Les bearer tokens sont une forme de jeton d'accès utilisé dans l'authentification d'API REST pour prouver l'identité du client effectuant la requête. Ces jetons sont généralement générés par un serveur d'authentification et doivent être inclus dans chaque requête API pour autoriser l'accès aux ressources protégées. L'en-tête HTTP Authorization est la méthode standardisée pour transmettre les bearer tokens, en utilisant la syntaxe 'Authorization: Bearer <token>'. Cet en-tête fait partie du protocole HTTP, que les API REST utilisent comme couche de transport, ce qui en fait l'endroit logique et sécurisé pour inclure les identifiants d'authentification. La décision de placer les bearer tokens dans l'en-tête HTTP Authorization suit le style architectural REST et les standards HTTP. Cette approche sépare les données d'authentification du corps du message et des paramètres d'URL, réduisant le risque de fuite de jeton par le biais des journaux (logs) ou des caches. Les scripts d'automatisation réseau Cisco qui interagissent avec les API REST des contrôleurs doivent respecter ce standard pour garantir une authentification et une autorisation réussies. L'utilisation de HTTPS chiffre l'ensemble du message HTTP, y compris les en-têtes, protégeant ainsi le bearer token contre l'interception pendant la transmission. Un piège d'examen courant consiste à confondre l'emplacement du bearer token avec les champs de protocoles de couches inférieures comme les trailers Ethernet ou les champs de checksum TCP, qui ne transportent pas de données de couche application. Une autre erreur consiste à supposer que les réponses DNS peuvent transporter des jetons d'authentification, ce qu'elles ne peuvent pas faire puisque le DNS n'a aucun rapport avec la sécurité des API REST. En pratique, placer les jetons en dehors de l'en-tête Authorization entraîne un échec d'authentification et des risques de sécurité potentiels. Comprendre cette distinction est essentiel pour les tâches d'automatisation Cisco et pour réussir les questions de l'examen CCNA sur les principes fondamentaux de la sécurité des API REST.
À propos de ces questions d'entraînement
Cette question fait partie des questions d'entraînement 200-301 originales de Courseiva, rédigées pour apprendre et jamais copiées d'examens réels ou de dumps.
Traduite de l'original anglais avec l'IA et vérifiée pour le sens. Les codes d'examen, les commandes et les noms de produits sont conservés tels qu'ils apparaissent à l'examen.