¿Qué es un token de portador? Uso, riesgos y mejores prácticas

La API de scraping sin raspar utiliza una clave de API de cuenta en el encabezado x-api-token en lugar de la autenticación OAuth Bearer, lo que ilustra que el tipo de credencial y el esquema de presentación HTTP son elecciones de diseño separadas.

¿Qué es un token de portador?

Un token de portador es un token de seguridad cuya autoridad se basa en la posesión. La palabra “portador” significa que la parte que lleva el token puede presentarlo a un recurso protegido. A diferencia de un diseño de prueba de posesión, un flujo básico de portador no requiere que el llamador demuestre control sobre una clave criptográfica separada para cada solicitud.

RFC 6750 define el uso de tokens de portador OAuth 2.0.Describe cómo los clientes envían tokens de acceso a los servidores de recursos, cómo los servidores devuelven desafíos de autenticación y errores, y qué amenazas de seguridad deben abordar las implementaciones.

Los tokens de portador son comunes en las APIs HTTP porque la interacción del cliente es sencilla. El servidor de autorización emite un token de acceso, el cliente lo almacena y el cliente lo envía con las solicitudes de API. La simplicidad transfiere la responsabilidad a la seguridad del transporte, el manejo del token, la validación, el diseño del alcance y la respuesta a incidentes.

Cómo funciona el encabezado de autorización

La presentación HTTP preferida utiliza el Authorization encabezado de solicitud con el Bearer esquema:

Authorization: Bearer REDACTED

El nombre del esquema es insensible a mayúsculas y minúsculas bajo el análisis de autenticación HTTP, pero los clientes deben usar la capitalización convencional. El valor del token es opaco para el cliente a menos que el perfil del token le dé al cliente una razón explícita para inspeccionarlo. Los clientes no deben tomar decisiones de autorización decodificando el contenido del token de acceso; el servidor de recursos es el punto de aplicación.

La solicitud debe usar HTTPS, y el cliente debe validar el certificado del servidor de acuerdo con su modelo de confianza de plataforma. El encabezado aún puede filtrarse a través de registros de aplicación, agentes de rastreo, proxies de depuración, informes de fallos o extensiones del navegador, por lo que cada capa que observa solicitudes necesita reglas de redacción.

Token de portador, token de acceso y OAuth

Un token de acceso es una credencial que representa autorización para acceder a un recurso. Bearer describe cómo se utiliza ese token. OAuth es el marco a través del cual un cliente puede obtener un token de acceso bajo una concesión. Estos términos están relacionados pero no son intercambiables.

Los tokens de acceso OAuth suelen ser tokens de portador, pero otro perfil puede vincular un token a una clave sostenida por el cliente. Un sistema no OAuth también puede inventar un token de estilo portador, aunque usar el esquema estándar sin seguir la seguridad y la semántica de error asociadas crea confusión.

Un código de autorización no es un token de acceso portador para las APIs de recursos. Es una credencial intermedia de corta duración intercambiada en el punto final de token del servidor de autorización. Un token de actualización tampoco se envía a servidores de recursos ordinarios; se utiliza con el servidor de autorización para continuar una concesión existente.

Token de portador vs clave de API vs JWT

Un JWT puede ser un token de portador, pero no todo JWT es un token de acceso y no todo token de portador es un JWT. Un JWT firmado prueba que un emisor aprobado protegió las afirmaciones de alteración; no prueba que el presentador sea el titular previsto a menos que el perfil añada el enlace del remitente.

Tokens de portador opacos y autoconstruidos

Tokens opacos

Un token opaco es un valor impredecible cuyo significado está sostenido por la infraestructura de autorización. El servidor de recursos puede llamar a un endpoint de introspección, usar un almacén de tokens compartido o confiar en una puerta de enlace que resuelva el token. La búsqueda central puede reflejar la revocación y los cambios de política rápidamente, pero añade disponibilidad, latencia y decisiones de almacenamiento en caché.

Tokens autoconstruidos

Un token autoconstruido lleva afirmaciones que un servidor de recursos puede validar localmente. JWT es una representación común. El servidor verifica la firma o el código de autenticación de mensajes bajo un perfil estricto y luego verifica el emisor, el público, el tiempo, el tipo de token, el alcance y cualquier afirmación de confirmación requerida.

RFC 8725 proporciona las mejores prácticas actuales de seguridad para JWT.Advierte contra la confusión de algoritmos, validación débil, confusión entre JWT y confiar ciegamente en las afirmaciones recibidas. Un servidor de recursos debe configurar los algoritmos permitidos y los perfiles de token esperados en lugar de aceptar lo que solicita el encabezado del token.

Qué debe validar un servidor de recursos

• Integridad o estado activo del token. Valide la firma bajo un algoritmo permitido o resuelva el token opaco a través del sistema de autorización confiable.
• Emisor. Acepte tokens solo del servidor de autorización configurado para este recurso.
• Público. Confirme que el token fue emitido para esta API o conjunto de recursos.
• Vida útil. Haga cumplir la expiración y cualquier condición de no antes con una pequeña tolerancia de reloj documentada.
• Perfil y tipo de token. Impedir que un token de ID, código de autorización o token de otro contexto de protocolo sea aceptado como un token de acceso a la API.
• Alcance o afirmaciones de autorización. Confirme que el token permite la operación solicitada.
• Política a nivel de recurso. Verifique el inquilino, la propiedad, el rol, el estado del objeto y otras reglas de dominio incluso cuando el token tiene un alcance amplio.

Una firma válida es solo un chequeo. Prueba que el token fue protegido por una clave confiable bajo el algoritmo aceptado. No prueba que el token esté dirigido a esta API, sea actual, tenga la autoridad requerida o pueda acceder a este registro específico.

Riesgos de seguridad del token de portador

El riesgo central es la divulgación del token. Un token de portador copiado puede ser utilizado hasta que expire, sea revocado o sea rechazado por otro control de política. La exposición puede suceder a través de URLs, registros de aplicación, capturas de pantalla de soporte, almacenamiento del navegador, encabezados de referencia, trazas de proxy, control de versiones o dispositivos cliente comprometidos.

Las URLs son particularmente peligrosas. Las cadenas de consulta aparecen en los registros de acceso de servidores web, el historial del navegador, sistemas de análisis y enlaces copiados. RFC 6750 define un método de cuerpo codificado en forma bajo condiciones restringidas y documenta el uso de consulta URI para compatibilidad, pero los nuevos clientes deben usar el encabezado de autorización.

La inyección de scripts entre sitios puede exponer tokens accesibles por el navegador. Mantener un token de portador de larga duración en el almacenamiento local lo hace disponible para scripts maliciosos ejecutándose en el mismo origen. Las arquitecturas del navegador deben minimizar la exposición de tokens a JavaScript, usar tiempos de vida de acceso cortos, hacer cumplir una política de seguridad de contenido fuerte y considerar un patrón de backend para frontend cuando sea apropiado.

Almacenamiento de tokens por tipo de cliente

Un servicio de backend almacena tokens en memoria del lado del servidor o en un almacén de credenciales protegido aprobado y limita el acceso a la identidad de carga de trabajo que los necesita. Los tokens no deben escribirse en cachés de disco, volcado de entorno o registros generales sin una razón revisada y un modelo de protección.

Una aplicación instalada utiliza almacenamiento seguro del sistema operativo donde está disponible. Un cliente de navegador tiene un entorno más expuesto y debe mantener la duración del token y el acceso del script tan pequeño como sea práctico. Una cookie de sesión no es automáticamente más segura; los diseños de cookies necesitan controles de Secure, HttpOnly, SameSite, prevención de falsificación de solicitud entre sitios y política de sesión del lado del servidor.

Ninguna elección de almacenamiento soluciona un token sobrepoderado. Mantenga los alcances estrechos, los públicos específicos, las vidas útiles cortas y los recursos protegidos por autorización del lado del servidor.

Alternativas restringidas por el remitente

Un token restringido por el remitente requiere que el presentador demuestre la posesión de una clave separada, reduciendo el valor de una cadena de token robada. Demostrar Prueba de Posesión, o DPoP, vincula los tokens de OAuth a una clave de aplicación a través de pruebas firmadas adjuntas a las solicitudes.

RFC 9449 define OAuth DPoP.Mutual TLS es otro enfoque que restringe al remitente para entornos de cliente confidenciales adecuados. Estos diseños añaden generación de claves, almacenamiento, detección de reproducción y requisitos de interoperabilidad, por lo que deben ser seleccionados bajo un modelo de amenaza claro.

Expiración, revocación e introspección

Los tokens de acceso de corta duración limitan cuánto tiempo un token divulgado permanece útil. El cliente puede obtener nuevo acceso a través de una sesión autorizada o un proceso de token de actualización. La credencial de actualización merece una protección más fuerte porque puede extender el acceso más allá de la vida útil de un token de acceso.

Los tokens opacos pueden reflejar revocación a través de la introspección o búsqueda central. Los tokens autoconstruidos a menudo son aceptados hasta la expiración, a menos que el servidor de recursos verifique un estado de revocación o sesión. El diseño adecuado equilibra los cambios de política inmediatos, la latencia, la disponibilidad, el almacenamiento en caché y el riesgo.

Los semánticos de cierre de sesión deben ser definidos. Terminar una sesión local del cliente, revocar un token de actualización, revocar un token de acceso y terminar una sesión del servidor de autorización son operaciones diferentes. Una interfaz de usuario debe describir lo que realmente invalida.

Casos de uso comunes de tokens de portador

Lista de Verificación de Token Bearer

1. Enviar tokens solo a través de HTTPS. Validar el servidor previsto y mantener los tokens fuera de las URLs.
2. Usar el encabezado de Autorización. Seguir el esquema documentado de la API y no inventar un lugar alternativo.
3. Emitir autoridad restringida. Limitar audiencia, alcance, duración, inquilino y permisos de recurso.
4. Validar el perfil completo del token. La firma por sí sola no es suficiente.
5. Redactar antes de la exportación de observabilidad. Cubrir encabezados, trazas, excepciones, volcado de solicitudes y herramientas de soporte.
6. Proteger el almacenamiento para el tipo de cliente. Los clientes públicos y confidenciales tienen diferentes capacidades.
7. Planificar la revocación y la respuesta ante incidentes. Saber qué tokens, permisos y sesiones se pueden desactivar y qué tan rápido los servidores de recursos observan el cambio.

Conclusión

Un token bearer es poderoso porque hace que las llamadas API autorizadas sean simples: presenta el token y el servidor de recursos evalúa su autoridad. La misma propiedad hace que la divulgación sea grave. Los sistemas de token bearer seguros usan TLS, el encabezado de Autorización, validación estricta del perfil de token, audiencias y alcances restringidos, vidas cortas, almacenamiento protegido, redacción agresiva y controles de revocación. Cuando el riesgo de robo requiere una garantía más fuerte, los tokens restringidos por el remitente añaden prueba vinculada a una clave mantenida por el cliente.