En esta página, se abarcan algunas prácticas recomendadas generales para la integración con OAuth 2.0. Considera estas prácticas recomendadas, además de cualquier orientación específica para tu tipo de aplicación y plataforma de desarrollo. Consulta también las recomendaciones para preparar tu app para la producción y las políticas de OAuth 2.0 de Google.
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 secretos como Secret Manager de Google Cloud. No codifiques las credenciales de forma rígida, no las confirmes en un repositorio de código ni las publiques de forma pública.
Administra los tokens de usuario de forma segura
Los tokens de usuario incluyen tokens de actualización y tokens 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 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:
- Para las aplicaciones del servidor que almacenan tokens para muchos usuarios, encripta los tokens en reposo y asegúrate de que tu almacén de datos no sea accesible públicamente a Internet.
- Para 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 los tokens del remitente con DPoP (Demonstrating Proof-of-Possession). Si bien cualquier parte que los intercepte puede usar los tokens del portador estándar, los tokens de DPoP están vinculados de forma criptográfica a un par de claves único que genera y mantiene el cliente.
Cuando se usa DPoP, el cliente presenta una prueba (un token web JSON firmado) al extremo del 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 reproducirlo sin esa clave privada.
DPoP funciona junto con PKCE para proporcionar una protección integral:
- 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 y evita los ataques de repetición si se ve comprometido.
Se recomienda adoptar DPoP si tu aplicación cumple con lo siguiente:
- Funciona como un cliente público (como una aplicación de una sola página o una app instalada) en la que los tokens de actualización pueden ser más susceptibles a la exfiltración.
- Accede a datos altamente sensibles o a APIs de alto valor, en las que el impacto de la filtración de tokens es significativo.
- Debe cumplir con estándares estrictos de cumplimiento o seguridad que exijan tokens restringidos del remitente.
Para obtener instrucciones detalladas sobre cómo crear pruebas de DPoP y solicitar tokens vinculados a DPoP, consulta la documentació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
state parámetro debe ser un valor único y no adivinable generado por 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 del token 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 se pueden invalidar 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, incluida la solicitud al usuario en su próximo acceso o la limpieza de sus datos. Para recibir notificaciones sobre la revocación de tokens, realiza la integración 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, según el principio de seleccionar los permisos más pequeños y limitados posibles.
Siempre solicita permisos en contexto para ayudar a tus 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:
- El usuario se autentica con tu app.
- No se solicitan permisos adicionales. La app proporciona una funcionalidad básica para permitir que el usuario explore y use funciones que no requieren datos ni acceso adicionales.
- El usuario selecciona una función que requiere acceso a datos adicionales.
- 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.
- Si el usuario rechaza la solicitud, la app inhabilita la función y le proporciona contexto adicional para volver a solicitar acceso.
Controla el consentimiento para varios permisos
Cuando se solicitan varios permisos a la vez, es posible que los usuarios no otorguen todos los permisos de OAuth que solicitaron. Tu app debe controlar el rechazo de permisos inhabilitando la funcionalidad pertinente.
Si la funcionalidad básica de tu app requiere varios permisos, explícaselo al usuario antes de solicitar el consentimiento.
Solo puedes volver a solicitarle 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 contexto pertinente y justificación antes de solicitar permisos de OAuth.
Debes minimizar la cantidad de permisos que solicita tu app a la vez. En su lugar, usa la autorización incremental para solicitar permisos en el contexto de las funciones.
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 a 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, usa las bibliotecas de OAuth recomendadas o Acceso con Google para tu plataforma.
Creación y configuración manual de clientes de OAuth
Para evitar el abuso, los clientes de OAuth no se pueden crear ni modificar de forma programática. Debes usar la consola de Google Cloud para reconocer explícitamente 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 usen
Audita periódicamente tus clientes de OAuth 2.0 y borra de forma proactiva los que ya no requiera tu aplicación o que hayan quedado obsoletos. Dejar configurados los clientes que no se usan representa un riesgo de seguridad potencial, ya que el cliente se puede usar de forma inadecuada si alguna vez se ven comprometidas tus credenciales de cliente.
Para mitigar aún más los riesgos de los clientes que no se usan, los clientes de OAuth 2.0 que hayan estado inactivos durante seis meses se borran automáticamente.
La práctica recomendada es no esperar la eliminación automática, sino quitar de forma proactiva los clientes que no se usen. Esta práctica minimiza la superficie de ataque de tu aplicación y garantiza una buena higiene de seguridad.