Un script de automatización necesita enviar un token de tipo bearer al llamar a una API REST de un controlador a través de HTTPS. ¿Dónde se incluye más comúnmente ese token?
Elige la mejor respuesta.
Respuesta correcta
Los tokens bearer se envían típicamente en el encabezado HTTP Authorization. Los parámetros de consulta o el cuerpo de la solicitud pueden transportar credenciales en algunas API personalizadas, pero el patrón REST normal es un encabezado Authorization como 'Authorization: Bearer <token>'.
En el encabezado HTTP Authorization
RFC 6750 especifica que un token bearer se transmite en el encabezado de solicitud HTTP Authorization utilizando el esquema de autenticación Bearer (por ejemplo, `Authorization: Bearer <token>`). Este encabezado es analizado por el servidor de recursos para validar la identidad y los permisos del cliente antes de procesar la solicitud. Debido a que HTTP es el protocolo de la capa de aplicación utilizado para las API REST, esta es la única ubicación correcta para el token entre las opciones enumeradas.
En la cola de Ethernet
La cola de Ethernet contiene la secuencia de verificación de trama (Frame Check Sequence o FCS), un valor CRC utilizado únicamente para la detección de errores en la Capa 2, no para transportar datos de aplicación. Los tokens, como los tokens bearer, son generados por servicios de autenticación y deben presentarse en la capa HTTP para que el servidor web pueda procesarlos. Colocar un token en la cola lo haría invisible para los protocolos de capas superiores y sería eliminado por la NIC mucho antes de que la aplicación pudiera acceder a él.
En la sección de respuesta de DNS
Las respuestas de DNS transportan registros de recursos (como A, AAAA o TXT) en la sección de respuesta, los cuales sirven para resolver nombres de dominio a direcciones IP u otros datos relacionados con el dominio. La autorización de la API REST es un asunto de la capa de aplicación que ocurre después de que se establece la conexión TCP y se envía la solicitud HTTP, por lo que no tiene relación con el proceso de resolución de DNS. Un token bearer no se puede entregar a través de DNS porque el servidor DNS no reenvía datos de aplicación arbitrarios al extremo HTTP.
En el campo de suma de verificación de TCP
El campo de suma de verificación de TCP es un valor de 16 bits calculado sobre el encabezado TCP, el pseudo-encabezado y la carga útil para garantizar la integridad de los datos durante el transporte. Se recalcula en cada salto y es verificado por el receptor; cualquier modificación en este causaría que el segmento se descartara por estar corrupto. Los tokens bearer no forman parte de los metadatos de la capa de transporte; deben incluirse en la propia solicitud HTTP para que la aplicación pueda autenticar al usuario, y no ocultarse en una suma de verificación que nunca se expone a la capa de aplicación.
Los tokens bearer son una forma de token de acceso utilizada en la autenticación de API REST para probar la identidad del cliente que realiza la solicitud. Estos tokens son generados típicamente por un servidor de autenticación y deben incluirse en cada solicitud de API para autorizar el acceso a recursos protegidos. El encabezado HTTP Authorization es el método estandarizado para transmitir tokens bearer, utilizando la sintaxis 'Authorization: Bearer <token>'. Este encabezado es parte del protocolo HTTP, que las API REST utilizan como su capa de transporte, convirtiéndolo en el lugar lógico y seguro para incluir credenciales de autenticación. La decisión de ubicar los tokens bearer en el encabezado HTTP Authorization sigue el estilo arquitectónico REST y los estándares HTTP. Este enfoque separa los datos de autenticación del cuerpo del mensaje y de los parámetros de URL, reduciendo el riesgo de filtración del token a través de registros (logs) o cachés. Los scripts de automatización de red de Cisco que interactúan con las API REST de los controladores deben adherirse a este estándar para garantizar una autenticación y autorización exitosas. El uso de HTTPS cifra todo el mensaje HTTP, incluidos los encabezados, protegiendo el token bearer contra la intercepción durante la transmisión. Una trampa común en el examen es confundir la ubicación del token bearer con campos de protocolos de capa inferior, como las colas de Ethernet o los campos de suma de verificación de TCP, los cuales no transportan datos de la capa de aplicación. Otro error es asumir que las respuestas de DNS pueden transportar tokens de autenticación, lo cual no pueden hacer ya que DNS no está relacionado con la seguridad de las API REST. En la práctica, colocar tokens fuera del encabezado Authorization conduce a fallas de autenticación y a riesgos potenciales de seguridad. Comprender esta distinción es fundamental para las tareas de automatización de Cisco y para responder las preguntas del examen CCNA sobre los fundamentos de seguridad de las API REST.
Sobre estas preguntas de práctica
Esta es una de las preguntas de práctica originales de 200-301 de Courseiva, escrita para aprender y nunca copiada de exámenes reales ni de dumps.
Traducida del original en inglés con IA y revisada para comprobar el sentido. Los códigos de examen, los comandos y los nombres de productos se mantienen tal como aparecen en el examen.