Prácticas recomendadas

Administra las credenciales de cliente de forma segura

Las credenciales de cliente de OAuth identifican la identidad de tu app y deben manejarse con cuidado. Solo almacena estas credenciales en un almacenamiento seguro, por ejemplo, con un administrador de Secrets, como Secret Manager de Google Cloud. No codifiques las credenciales, no las confirmes en un repositorio de código ni las publiques de forma general.

Controla los tokens de usuario de forma segura

Los tokens de usuario incluyen los tokens de actualización y de acceso que usa tu aplicación. Almacena los tokens de forma segura en reposo y nunca los transmitas en texto sin formato. Usa un sistema de almacenamiento seguro que sea adecuado para tu plataforma, como Keystore en Android, Keychain Services en iOS y macOS, o Credential Locker en Windows.

Revoca los tokens en cuanto ya no sean necesarios y bórralos de forma permanente de tus sistemas.

Además, considera estas prácticas recomendadas para tu plataforma:

• En el caso de las aplicaciones del servidor que almacenan tokens para muchos usuarios, encripta los tokens en reposo y asegúrate de que no se pueda acceder públicamente a tu almacén de datos desde Internet.
• En el caso de las apps para computadoras, se recomienda usar el protocolo de clave de prueba para el intercambio de código (PKCE) para obtener códigos de autorización que se puedan intercambiar por tokens de acceso.

Restringe los tokens del remitente con DPoP

Para proteger tu aplicación contra el robo de tokens y los ataques de repetición, considera restringir el remitente de tus tokens con DPoP (demostración de prueba de posesión). Mientras que cualquier parte que intercepte los tokens de portador estándar puede usarlos, los tokens de DPoP están vinculados criptográficamente a un par de claves único que genera y conserva el cliente.

Cuando se usa DPoP, el cliente presenta una prueba (un token web JSON firmado) al extremo de token cuando solicita o actualiza tokens. Esta prueba demuestra que el cliente posee la clave privada que corresponde a la clave pública vinculada al token. Si se filtra un token de actualización vinculado a DPoP, un atacante no puede volver a reproducirlo sin esa clave privada.

DPoP funciona junto con PKCE para proporcionar una protección integral:

• La PKCE protege el código de autorización durante el flujo de redireccionamiento inicial.
• DPoP protege el token de actualización de larga duración, lo que evita ataques de reproducción si se ve comprometido.

Se recomienda adoptar DPoP si tu aplicación cumple con las siguientes condiciones:

• Funciona como una aplicación instalada o de escritorio (o una aplicación de una sola página vinculada con un servidor de backend para frontend) en la que los tokens de actualización pueden ser más susceptibles a la robo de datos.
• Accede a datos altamente sensibles o APIs de alto valor, en los que el impacto de la filtración de tokens es significativo.
• Necesita cumplir con estándares estrictos de cumplimiento o seguridad que exijan tokens restringidos por el remitente.

Para obtener instrucciones detalladas sobre cómo crear pruebas de DPoP y solicitar tokens vinculados a DPoP, consulta la Guía de adopción de DPoP.

Usa el parámetro state

Antes de controlar una respuesta de OAuth 2.0, confirma que el state recibido de Google coincida con el state enviado en tu solicitud de autorización. El parámetro state debe ser un valor único y no adivinable que genere tu aplicación.

El uso del parámetro state ayuda a garantizar que el usuario, y no una secuencia de comandos maliciosa, realice la solicitud y reduce el riesgo de ataques de falsificación de solicitudes entre sitios (CSRF).

Controla la revocación y el vencimiento de los tokens de actualización

Si tu app solicitó un token de actualización para el acceso sin conexión, también debes controlar su invalidación o vencimiento. Los tokens podrían invalidarse por diferentes motivos, por ejemplo, podrían haber vencido o el usuario o un proceso automatizado podrían haber revocado el acceso de tus apps. En este caso, considera cuidadosamente cómo debe responder tu aplicación, lo que incluye solicitarle al usuario que acceda la próxima vez o que limpie sus datos. Para recibir notificaciones sobre la revocación de tokens, intégrate con el servicio de Protección integral de la cuenta.

Usa la autorización incremental

Usa la autorización incremental para solicitar los permisos de OAuth adecuados cuando tu aplicación necesite la funcionalidad.

No debes solicitar acceso a los datos cuando el usuario se autentica por primera vez, a menos que sea esencial para la funcionalidad principal de tu app. En su lugar, solicita solo los permisos específicos que se necesitan para una tarea, siguiendo el principio de seleccionar los permisos más pequeños y limitados posibles.

Solicita siempre permisos en contexto para ayudar a los usuarios a comprender por qué tu app solicita acceso y cómo se usarán los datos.

Por ejemplo, tu aplicación puede seguir este modelo:

1. El usuario se autentica con tu app.
   1. No se solicitan permisos adicionales. La app proporciona funciones básicas para que el usuario explore y use funciones que no requieren datos ni acceso adicionales.
2. El usuario selecciona una función que requiere acceso a datos adicionales.
   1. Tu aplicación realiza una solicitud de autorización para este permiso de OAuth específico que se requiere para esta función. Si esta función requiere varios permisos, sigue las prácticas recomendadas para varios permisos.
   2. Si el usuario rechaza la solicitud, la app inhabilita la función y le proporciona al usuario contexto adicional para volver a solicitar acceso.

Controla el consentimiento para varios permisos

Cuando solicitas varios permisos a la vez, es posible que los usuarios no otorguen todos los permisos de OAuth que solicitaste. Tu app debe controlar el rechazo de los permisos inhabilitando la funcionalidad correspondiente.

Si la funcionalidad básica de tu app requiere varios permisos, explícaselo al usuario antes de solicitarle su consentimiento.

Solo puedes volver a solicitarle el permiso al usuario una vez que haya indicado claramente su intención de usar la función específica que requiere el permiso. Tu app debe proporcionar al usuario el contexto y la justificación pertinentes antes de solicitar permisos de OAuth.

Debes minimizar la cantidad de permisos que tu app solicita a la vez. En su lugar, utiliza la autorización incremental para solicitar permisos en el contexto de las funciones y características.

Usa navegadores seguros

En la Web, las solicitudes de autorización de OAuth 2.0 solo se deben realizar desde navegadores web con todas las funciones. En otras plataformas, asegúrate de seleccionar el tipo de cliente de OAuth correcto y de integrar OAuth según corresponda para tu plataforma. No redirecciones la solicitud a través de entornos de navegación incorporados, incluidas las vistas web en plataformas para dispositivos móviles, como WebView en Android o WKWebView en iOS. En su lugar, utiliza las bibliotecas de OAuth recomendadas o Acceso con Google para tu plataforma.

Creación y configuración manuales de clientes de OAuth

Para evitar abusos, los clientes de OAuth no se pueden crear ni modificar de forma programática. Debes usar la consola de Google Cloud para aceptar de forma explícita las Condiciones del Servicio, configurar tu cliente de OAuth y prepararte para la verificación de OAuth.

Para los flujos de trabajo automatizados, considera usar cuentas de servicio en su lugar.

Quita los clientes de OAuth que no se usaron

Audita con regularidad tus clientes de OAuth 2.0 y borra de forma proactiva los que ya no sean necesarios para tu aplicación o que se hayan vuelto obsoletos. Dejar configurados los clientes sin usar representa un riesgo de seguridad potencial, ya que se puede hacer un uso inadecuado del cliente si alguna vez se vulneran sus credenciales.

Para mitigar aún más los riesgos de los clientes sin usar, los clientes de OAuth 2.0 que hayan estado inactivos durante seis meses se borran automáticamente.

La práctica recomendada es no esperar a que se borren automáticamente, sino quitar de forma proactiva los clientes que no se usan. Esta práctica minimiza la superficie de ataque de tu aplicación y garantiza una buena higiene de seguridad.