--- id: CP-194 slug: oauth-2-delegacion-acceso-tokens lang: es title: OAuth 2.0 y los tokens de acceso description: 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. canonical_url: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ markdown_url: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, «OAuth 2.0 y los tokens de acceso», Cyberpedia, 2026. https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ (CC BY 4.0) wing: 3 theme: control_access reflex: cr-026 schema: G3 updated: "2026-11-03" translations: es: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ fr: https://startbrain.io/cyberpedia/fr/articles/oauth-2-delegation-acces-jetons/ en: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ de: https://startbrain.io/cyberpedia/de/articles/oauth-2-delegierter-zugriff-token/ it: https://startbrain.io/cyberpedia/it/articles/oauth-2-delega-accesso-token/ sources: - "n": 1 title: Investigate and remediate risky OAuth apps publisher: Microsoft url: https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Access tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens accessed: "2026-11-03" - "n": 4 title: Refresh tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens accessed: "2026-11-03" - "n": 5 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 6 title: OAuth2 - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html accessed: "2026-11-03" --- # OAuth 2.0 y los tokens de acceso 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 titular [1]. 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ífica [1]. Esa página se llama 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ínea [1]. - Lo que quiere el atacante: que usted conceda acceso a una aplicación maliciosa, por ejemplo tras un enlace recibido mediante un phishing dirigido [2]. - 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ón [1]. ## 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 esa [1]. 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 edificio [3]. Como abre el acceso, es sensible y supone un riesgo si no está bien protegido [3]. 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 media [3]. ### ¿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 acceso [4]. 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 Microsoft [4]. 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ón [5]. El token de actualización agrava el riesgo: si se roba, el atacante obtiene nuevos tokens de acceso sin molestar al usuario [2]. ### ¿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ón [1]. 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 administrador [4]. Los efectos varían según el tipo de token y el cambio realizado [4]. ## Cómo funciona 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 token [6]. 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 corta [6]. 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 propietario [6]. 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 fuga [6]. La aplicación, por su parte, debe tratar el token como una cadena opaca: solo la API destinataria debe leer su contenido [3]. ## Qué hace usted 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 concedidos [1]. - 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ósito [1]. - 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 sensibles [2]. - 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 real [2]. - 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 segura [1]. - Rechace una aplicación que no reconozca. MITRE ATT&CK recomienda formar a los usuarios para que no autoricen aplicaciones de terceros desconocidas [2]. - Un administrador puede investigar las aplicaciones sospechosas y retirarlas [2]. ## Las trampas ### 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 acceso [2]. 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 Google [1]. 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 Yahoo [2]. ### El token que dura Una vez concedido el token, la aplicación puede obtener un acceso potencialmente duradero a las funciones de la cuenta [2]. 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 contactos [5]. 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 usuario [4]. ### 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 servicios [2]. 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 atacante [2]. ### 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 falta [1]. 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 sospechosas [2]. 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. ## Fuentes 1. 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) 2. MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise». https://attack.mitre.org/techniques/T1528/ (consultado el 3 de noviembre de 2026) 3. 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) 4. 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) 5. 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) 6. OWASP, «OAuth2 - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html (consultado el 3 de noviembre de 2026) --- Fuente original: Cyberpedia, la enciclopedia pública de ciberseguridad e IA publicada por Brain. Versión canónica: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ Puede reutilizar este texto libremente bajo la licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), siempre que cite «Brain, Cyberpedia» con un enlace a la dirección anterior.