Proteger la información personal y empresarial es más crucial que nunca a medida que la tecnología digital se vuelve cada vez más frecuente. La identidad sirve como el límite de seguridad principal para las aplicaciones empresariales y de consumo. A medida que los ataques cibernéticos y las filtraciones de datos siguen aumentando, la protección de los datos confidenciales se ha convertido en una prioridad clave para las personas y las organizaciones.

Según el informe de investigaciones de filtraciones de datos de Verizon (2024), el 86% de las filtraciones se atribuyen a credenciales robadas, incluidas contraseñas, tokens de OAuth/OpenID Connect y claves de API. Estos tokens se utilizan normalmente para autenticar y autorizar a los usuarios en varios sitios web, permitir que los usuarios permanezcan conectados durante un período prolongado y recuperar información de perfil sobre el usuario que el sitio web puede utilizar para personalizar su experiencia. Las aplicaciones pueden utilizar estos tokens para acceder a recursos protegidos como las API y la información confidencial.

La protección de estos artefactos privilegiados (tokens) se ha convertido en un requisito de misión crítica. A continuación, se presentan las prácticas recomendadas que puedes implementar para proteger tus tokens de OAuth y OpenID Connect.

Breve introducción a los tipos de tokens y aplicaciones de OAuth/OpenID Connect

Primero, repasemos los diferentes tipos de tokens y aplicaciones de OAuth y OpenID Connect.

Tipos de tokens

Los tokens son credenciales digitales seguras que se utilizan para verificar la identidad de un usuario y conceder acceso a recursos protegidos. La carga útil del token suele contener información sobre el perfil del usuario, los permisos y los metadatos, que están firmados criptográficamente para garantizar la autenticidad y la integridad.

ID tokens: Como su nombre indica, los ID tokens se utilizan para identificar al principal, (es decir, el usuario final). Contienen información sobre el usuario y demuestran que el proveedor de OpenID ha autenticado correctamente al usuario. La audiencia de este token es el OpenID Client, es decir, la propia aplicación.

Access tokens: OpenID Connect funciona junto con OAuth 2.0 para fines de autorización. Los access tokens de OAuth 2.0 delegan permisos a la aplicación para llamar a las API de backend en nombre del usuario. La audiencia del token es la API de backend (es decir, el servidor de recursos).

Refresh tokens: Los access tokens y los ID tokens son de corta duración y caducan después de un cierto período. Los refresh tokens son concesiones de larga duración que la aplicación puede utilizar para solicitar un nuevo par de access tokens y ID tokens del servidor de autorización. La audiencia del refresh token es el propio servidor de autorización.

Tipos de aplicaciones

Según la especificación de OAuth, las aplicaciones pueden clasificarse como confidenciales o públicas. La principal diferencia es si la aplicación puede o no guardar de forma segura las credenciales (como un Client ID y un secreto).

Public applications: Estas aplicaciones no pueden almacenar de forma segura los secretos o las credenciales del cliente que proporciona un servidor de autorización. Entre los ejemplos de aplicaciones públicas se incluyen las aplicaciones modernas del lado del cliente basadas en JavaScript que se ejecutan en el navegador (aplicaciones de una sola página) y las aplicaciones nativas instaladas en dispositivos móviles y de escritorio.

Confidential applications: Por otro lado, las aplicaciones confidenciales pueden almacenar y mantener de forma segura la confidencialidad de las credenciales del cliente. Estas aplicaciones se ejecutan en un servidor seguro y, por lo tanto, las credenciales no son accesibles para los usuarios finales. Entre los ejemplos de aplicaciones confidenciales se incluyen las aplicaciones web tradicionales y las aplicaciones de servidor a servidor de backend.

5 prácticas recomendadas para proteger tus tokens

1. Utiliza criptografía asimétrica para la autenticación del cliente

La autenticación del cliente nos permite verificar la identidad de la aplicación cliente para evitar la suplantación del cliente y permitir el acceso seguro a los recursos protegidos. Al igual que las contraseñas se consideran un factor de autenticación de usuario débil, los secretos del cliente son un método de autenticación de cliente débil, ya que el secreto del cliente está contenido en el cuerpo de la solicitud y se basa en un secreto compartido.

A diferencia de los secretos del cliente, las técnicas criptográficas asimétricas, como mTLS o los JSON Web Tokens (JWT) firmados, conocidos como private key JWTs, nunca se transmiten a través de la red, lo que reduce drásticamente el riesgo de fugas de claves y ataques de intermediario. La autenticación del cliente solo se aplica a los clientes confidenciales. Por lo tanto, al crear tu aplicación, considera la posibilidad de utilizar un método de autenticación de cliente robusto, especialmente si manejas información confidencial. Obtén más información sobre los métodos de autenticación de cliente.

2. Adopta PKCE para clientes públicos

El auge de las aplicaciones móviles y basadas en la web probablemente ha provocado un aumento de los clientes públicos. Dado que la autenticación del cliente no se puede utilizar con aplicaciones de cliente públicas, Proof Key for Code Exchange (PKCE) garantiza que solo el cliente original que inició la solicitud de autorización pueda intercambiar el código por tokens.

PKCE garantiza que un atacante no pueda canjear un código de autorización robado en el token endpoint del servidor de autorización. Si bien PKCE se diseñó inicialmente para clientes públicos, OAuth 2.1 recomienda PKCE para clientes confidenciales, además de la autenticación del cliente, ya que ofrece protección adicional contra la inyección de código de autorización y los ataques de interceptación. Obtén más información sobre PKCE con el flujo de código de autorización.

3. Implementa la prueba de posesión

La prueba de posesión es un método para restringir el uso de access tokens de OAuth a un cliente autorizado (aplicación basada en navegador). Se puede lograr de dos maneras: enlace de tokens basado en mTLS a nivel de transporte o enlace de tokens basado en DPoP a nivel de aplicación. Dadas las desafíos de escalabilidad, implementabilidad y usabilidad de mTLS, demostrar la prueba de posesión (DPoP) es la forma recomendada de implementar la prueba de posesión. DPoP representa una mejora significativa en la seguridad de OAuth 2.0, ya que evita que los atacantes roben y reproduzcan tokens. Obtén más información sobre OAuth 2.0 DPoP.

4. Considera tu proceso de gestión del ciclo de vida de los tokens 

Si se ven comprometidos, los tokens de larga duración brindan una ventana de oportunidad más amplia para actividades maliciosas que pueden resultar en un acceso no autorizado. Por lo tanto, recomendamos asignar a los access tokens vidas cortas y actualizarlos continuamente según sea necesario.

Para mitigar los riesgos asociados con la filtración de refresh tokens, considera la posibilidad de la rotación de refresh tokens, que ayuda a rotar el refresh token de forma segura después de cada uso. La rotación de refresh tokens puede ayudar a detectar la reutilización de un refresh token, tras lo cual el servidor de autorización puede invalidar el refresh token y todos los access tokens emitidos desde que se autenticó al usuario. Esto protege a la aplicación del compromiso de tokens y los ataques de reproducción. Obtén más información sobre la rotación de refresh tokens.

También es esencial revocar todos los tokens cuando un usuario cierra sesión en una aplicación. Cuando se revoca un token, se vuelve inmediatamente no válido, lo que impide cualquier uso posterior de ese token para acceder a recursos protegidos. La revocación de tokens puede ocurrir cuando el usuario inicia un cierre de sesión o cuando ocurre un evento inesperado, lo que eleva el perfil de riesgo del usuario. Con la revocación global de tokens, los proveedores externos de seguridad y credenciales pueden solicitar que un servidor de autorización revoque todos los tokens existentes de un usuario. Esta acción requiere que el usuario se vuelva a autenticar antes de que se emitan nuevos tokens. Obtén más información sobre la revocación global de tokens y el Cierre de sesión universal.

5. Aplica el principio del privilegio mínimo

Las aplicaciones OAuth/OpenID Connect deben diseñarse e implementarse utilizando el principio del privilegio mínimo para mejorar la postura de seguridad de la aplicación y minimizar los riesgos potenciales. Se pueden aprovechar las políticas específicas de la aplicación para garantizar que solo las personas adecuadas puedan acceder a una aplicación específica desde una ubicación, tipo de dispositivo, perfil de riesgo, etc. particulares.

Se pueden utilizar OAuth scopes para conceder permisos específicos en un access token. Los scopes deben ser lo más granulares posible para evitar que las aplicaciones soliciten permisos excesivos. Para los casos de uso que requieren un acceso granular que cambia dinámicamente, recomendamos modelarlos a partir del marco de OAuth. Esto ayuda a evitar que los tokens se inflen con scopes excesivos e información relacionada con las reclamaciones. Obtén más información sobre las políticas de inicio de sesión de la aplicación, los derechos y la autorización granular.

Si bien este blog destaca algunos aspectos críticos de la mejora de la seguridad de tus tokens, el grupo de trabajo de OAuth ha estado desarrollando una lista exhaustiva de prácticas recomendadas de seguridad. Revisa las especificaciones oficiales periódicamente para asegurarte de que tus aplicaciones cumplen con las últimas tendencias de seguridad y los estándares de identidad.

¿Tiene preguntas sobre esta publicación de blog? Contáctenos en eng_blogs@okta.com.

Explore más blogs de ingeniería de Okta para ampliar sus conocimientos. de Okta para ampliar sus conocimientos.

¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visita nuestra página de empleos.

Desbloquee el potencial de la gestión de identidades moderna y sofisticada para su organización. Contact Sales para obtener más información.

Continúe con su recorrido de identidad