OAuth 2.0 y los tokens de acceso
Cómo OAuth 2.0 da a una aplicación un acceso limitado a su cuenta sin su contraseña, y cómo leer la pantalla de consentimiento.
En 30 segundos
- Dónde ocurre
- Muchas aplicaciones de terceros instaladas por los usuarios piden permiso para acceder a sus datos y para iniciar sesión en su nombre en otras aplicaciones en línea1.
- Lo que quiere el atacante
- Que usted conceda acceso a una aplicación maliciosa, por ejemplo tras un enlace recibido mediante un phishing dirigido2.
- El reflejo
- Antes de pulsar «Aceptar», comprobar que los permisos solicitados corresponden al propósito de la aplicación y rechazarlos si no es así1.
- Si ya lo ha hecho
- Un administrador puede prohibir o revocar la aplicación1.
De qué se trata
OAuth es un estándar abierto de autenticación y autorización basado en tokens. Permite que un servicio de terceros utilice la información de una cuenta sin exponer la contraseña de su titular1.
Pensemos en una aplicación que analiza su agenda para aconsejarle sobre su organización. Necesita acceder a la agenda, pero en lugar de recibir sus credenciales, obtiene un token, creado cuando usted da su consentimiento en una página específica1. Esa página se llama pantalla de consentimiento.
Preguntas directas
¿Qué ocurre cuando acepto una pantalla de consentimiento?
La aplicación recibe un token de acceso que autoriza compartir información concreta de la cuenta, y solo esa1. La contraseña permanece en el proveedor de la cuenta.
¿Qué es un token de acceso?
Es una credencial concebida para la autorización: da acceso a recursos concretos en nombre de un usuario ya autenticado. Microsoft lo compara con las llaves que abren puertas concretas de un edificio3. Como abre el acceso, es sensible y supone un riesgo si no está bien protegido3.
Su vida útil es limitada. En la plataforma de identidad de Microsoft, el valor por defecto se elige al azar entre 60 y 90 minutos, es decir, 75 minutos de media3.
¿Qué es un token de actualización?
Un token de actualización sirve para obtener un nuevo par de tokens cuando caduca el token de acceso. El cliente lo recibe al mismo tiempo que el token de acceso4. Dura más: por defecto 24 horas para las aplicaciones de una sola página y para las que usan el flujo de autenticación con código de un solo uso enviado por correo electrónico, y 90 días en todos los demás escenarios, en la plataforma de Microsoft4. Así, la aplicación puede seguir trabajando en segundo plano sin pedirle su acuerdo en cada caducidad.
¿Por qué interesan estos tokens a los atacantes?
Un token robado permite actuar con los derechos de la cuenta. MITRE ATT&CK describe a atacantes que usan tokens robados en lugar de las credenciales de inicio de sesión5. El token de actualización agrava el riesgo: si se roba, el atacante obtiene nuevos tokens de acceso sin molestar al usuario2.
¿Se puede retirar el acceso a una aplicación?
Sí. En el plano de la administración, una aplicación puede prohibirse o revocarse desde la página de aplicaciones OAuth, y una regla puede automatizar la revocación1. En el plano de los tokens, el servicio puede revocar un token de actualización antes de su caducidad, por ejemplo tras un cambio de contraseña o una acción del usuario o del administrador4. Los efectos varían según el tipo de token y el cambio realizado4.
1Cómo funciona1 min
Intervienen tres actores. El cliente es la aplicación que solicita el acceso. El servidor de autorización emite los tokens después de autenticar al propietario de los datos y de obtener su consentimiento. El servidor de recursos aloja los datos y acepta las solicitudes acompañadas de un token6.
El token de acceso sustituye a las distintas credenciales (nombre de usuario y contraseña, por ejemplo) por un único elemento que entiende el servidor de recursos. Por eso puede tener una duración corta6. El token de actualización permite obtener uno nuevo, con derechos idénticos o más limitados: un token de acceso puede tener una duración más corta y menos permisos que los concedidos por el propietario6.
El token más habitual es el token portador: quien lo posee puede usarlo. Por ello, OWASP recomienda limitarlo, preferiblemente, a un solo servidor de recursos, para reducir el daño en caso de fuga6. La aplicación, por su parte, debe tratar el token como una cadena opaca: solo la API destinataria debe leer su contenido3.
2Qué hace usted1 min
Ante una pantalla de consentimiento, bastan unas pocas comprobaciones.
- Lea la solicitud antes de aceptarla. Los usuarios suelen pulsar «Aceptar» sin examinar los detalles, incluidos los permisos concedidos1.
- Compare los permisos con el propósito de la aplicación. Una aplicación solo debería pedir permisos relacionados con su finalidad; Microsoft pone el ejemplo de una aplicación de reloj con acceso completo a todos los buzones, lo que no corresponde a su propósito1.
- Desconfíe de los permisos más amplios. MITRE ATT&CK señala que el acceso sin conexión y el acceso a la lectura de correos deben despertar más sospechas, porque los atacantes pueden usar las API de los servicios en línea para buscar en ellos credenciales y comunicaciones sensibles2.
- Mire la dirección de redirección. Si está mal escrita o forma una serie de palabras complicada alrededor de un servicio esperado, el sitio probablemente intenta imitar un servicio real2.
- Prefiera las aplicaciones habituales. Cuanto más extendida está una aplicación, en la organización y en línea, más probable es que sea segura1.
- Rechace una aplicación que no reconozca. MITRE ATT&CK recomienda formar a los usuarios para que no autoricen aplicaciones de terceros desconocidas2.
- Un administrador puede investigar las aplicaciones sospechosas y retirarlas2.
3Las trampas2 min
La falsa pantalla de consentimiento
El atacante registra una aplicación en el servidor de autorización y después envía un enlace de phishing dirigido para que la víctima le conceda el acceso2. Un ejemplo dado por Microsoft: una página de consentimiento puede parecer legítima a un usuario medio, aunque «Google APIs Explorer» no tiene ningún motivo para pedir permisos a la propia Google. La aplicación puede ser, pues, un intento de phishing sin relación con Google1.
Los nombres tranquilizadores son frecuentes. MITRE ATT&CK señala que el grupo APT28 utilizó aplicaciones maliciosas que se hacían pasar por «Google Defender», «Google Email Protection» y «Google Scanner» ante usuarios de Gmail, y por «Delivery Service» y «McAfee Email Protection» ante usuarios de Yahoo2.
El token que dura
Una vez concedido el token, la aplicación puede obtener un acceso potencialmente duradero a las funciones de la cuenta2. Con un token de actualización que permite el acceso en segundo plano, un atacante puede, por ejemplo, buscar en los correos y enumerar los contactos5. Cambiar la contraseña no siempre resuelve el problema: según la tabla de Microsoft, algunos tokens siguen activos tras un cambio de contraseña por parte del usuario4.
El token robado sin pedirle nada
El robo de tokens no pasa siempre por un consentimiento. MITRE ATT&CK cita también tokens robados en entornos de contenedores o en cadenas de desarrollo, donde sirven para autenticarse ante otros servicios2. Se describe que el programa Kali365 obtuvo tokens de acceso y de actualización OAuth engañando a víctimas para que validaran solicitudes de autorización de dispositivo iniciadas por el atacante2.
La aplicación olvidada
Una aplicación autorizada un día sigue conectada mientras nadie la retire. Microsoft recomienda localizar las aplicaciones cuya fecha de última autorización no es reciente: puede que ya no hagan falta1. MITRE ATT&CK pide a los administradores una auditoría de todas las aplicaciones OAuth y de los permisos concedidos, seguida de auditorías periódicas, con investigación y retirada de las aplicaciones sospechosas2. Para el empleado, esto se traduce en un gesto sencillo: repasar de vez en cuando la lista de aplicaciones conectadas a su cuenta y comunicar las que no reconozca.
Ficha
- Identificador
- CP-194
- Ala
- 3. Protocolos y defensa
- Competencia Brain
- Controlar los accesos (control_access)
- Reflejo Brain
- cr-026
- Esquema
- G3 · Corte anatómico
- Idiomas
- de, en, es, fr
- Fuentes
- 6 fuentes verificadas el 3 de noviembre de 2026
Fuentes6 fuentes
- Microsoft, «Investigate and remediate risky OAuth apps». https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise». https://attack.mitre.org/techniques/T1528/ (consultado el 3 de noviembre de 2026)
- Microsoft, «Access tokens in the Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (consultado el 3 de noviembre de 2026)
- Microsoft, «Refresh tokens in the Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise». https://attack.mitre.org/techniques/T1550/001/ (consultado el 3 de noviembre de 2026)
- OWASP, «OAuth2 - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html (consultado el 3 de noviembre de 2026)
Citar este artículo
Brain, «OAuth 2.0 y los tokens de acceso», Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp194_es_2026,
author = {Brain},
title = {OAuth 2.0 y los tokens de acceso},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/},
note = {CC BY 4.0}
}