Un ingénieur s'authentifie avec succès auprès d'un contrôleur et reçoit un token. Quelle est la raison habituelle d'inclure ce token dans les requêtes API ultérieures ?
Choisissez la meilleure réponse.
Bonne réponse
Le token prouve que le client s'est déjà authentifié et est autorisé à continuer à interagir avec l'API pendant la durée de vie de ce token ou de cette session. Il est généralement envoyé dans un en-tête HTTP tel que Authorization. Il ne remplace pas le besoin de routage IP ou de résolution DNS.
Pour identifier et autoriser le client sans renvoyer à chaque fois les informations d'identification de connexion complètes
L'authentification API basée sur les tokens permet au client de s'authentifier une seule fois pour obtenir un token (souvent un JWT) qui sert de preuve d'identité pour les requêtes suivantes, de sorte que le client n'a pas besoin de renvoyer son nom d'utilisateur, son mot de passe ou d'autres informations d'identification principales à chaque appel. Le contrôleur valide la signature et les revendications (claims) du token, et peut autoriser l'accès en fonction des portées (scopes) ou des rôles intégrés dans le token, fournissant ainsi à la fois l'identité et l'autorisation d'une manière sans état (stateless) et efficace.
Pour convertir des requêtes HTTP en traps SNMP
Les tokens sont des informations d'identification opaques présentées dans les en-têtes HTTP (par exemple, Authorization: Bearer) pour prouver l'authentification lors d'appels d'API REST ; ils n'effectuent aucune traduction de protocole. La conversion de requêtes HTTP en traps SNMP nécessiterait un intermédiaire qui interprète l'appel d'API REST et le mappe à des opérations SNMP (comme SET/GET) pour ensuite envoyer des traps à un système de gestion, ce qui est totalement indépendant de la mécanique des tokens.
Pour élire le contrôleur actif dans le cluster
L'authentification API basée sur les tokens est utilisée pour valider l'identité du client API et autoriser son accès aux ressources du contrôleur, et non pour participer aux élections de cluster de contrôleurs. L'élection du contrôleur repose généralement sur un protocole distinct (par exemple, Raft ou un algorithme propriétaire basé sur les pulsations/heartbeat) qui détermine quel nœud devient actif, et les tokens ne jouent aucun rôle dans ce processus.
Pour compresser les charges utiles (payloads) JSON avant le transport
La compression JSON est généralement prise en charge par des mécanismes de codage de contenu (par exemple, gzip ou deflate) négociés via des en-têtes HTTP tels que Content-Encoding ou Accept-Encoding, qui opèrent au niveau de la couche HTTP indépendamment de l'authentification. Les tokens sont uniquement utilisés pour authentifier et autoriser la requête API ; ils ne modifient pas le codage de la charge utile (payload) et ne réduisent pas sa taille, la compression étant une optimisation de transport sur laquelle le serveur et le client s'accordent séparément.
L'authentification basée sur les tokens est un mécanisme de sécurité dans lequel, après une connexion réussie, le client reçoit un token représentant sa session authentifiée. Ce token est ensuite inclus dans les requêtes API ultérieures pour prouver l'identité et l'autorisation du client sans réenvoyer d'informations d'identification sensibles telles que des noms d'utilisateur et des mots de passe. Cette approche est courante dans les API RESTful utilisées dans les contrôleurs réseau Cisco et les plateformes d'automatisation, où une communication sécurisée et efficace est essentielle. La décision d'utiliser des tokens dans les requêtes API repose sur la nécessité de maintenir l'état de la session de manière sécurisée et efficace. Les tokens sont généralement envoyés dans les en-têtes HTTP, tels que l'en-tête Authorization, et ont une durée de vie limitée afin de réduire les risques de sécurité. Lorsque le token expire, le client doit se réauthentifier pour obtenir un nouveau token. Cette méthode réduit la surface d'attaque en minimisant l'exposition des informations d'identification et en rationalisant les appels API répétés, ce qui est indispensable pour gérer les équipements et contrôleurs Cisco par programmation. Un piège d'examen fréquent consiste à confondre l'objectif des tokens avec des fonctions réseau sans rapport, telles que la conversion en traps SNMP, l'élection du contrôleur ou la compression des données. Les tokens gèrent strictement l'authentification et l'autorisation. Dans les environnements réseau Cisco pratiques, les tokens facilitent l'accès sécurisé aux API mais n'influencent pas les décisions de routage, les rôles des contrôleurs ou le formatage des charges utiles (payloads). Comprendre cette distinction permet d'éviter les erreurs tant dans les scénarios d'examen que dans les tâches d'automatisation réseau du monde réel.
À 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.