LinkedIn
Instagram
WhatsApp
Telegrama
Calendario de Google
Únase a la comunidad SlackGoogle OAuth Verificación Credenciales de la API de Gmail
Paso a paso: crea credenciales OAuth de la API de Gmail, pasa la verificación de la aplicación de Google y la revisión de Nivel 2 de CASA, o envíalo hoy mismo con la clave OAuth ya certificada de Unipile y certifica la tuya más tarde.
Omitir la configuración de Google Cloud por completo.La clave OAuth certificada de Unipile lo gestiona. const response = await fetch('https://api.unipile.com/api/v1/hosted/cuentas', { method: POST, cabeceras: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': aplicación/json }, body: JSON.stringify({ tipo: 'GOOGLE', nombre: 'usuario-123', expiraEn: '2026-12-31' })}); const { url } = await respuesta.json();// Redirecciona a tu usuario a `url` - hecho.En qué consiste realmente la verificación de Google OAuth
La verificación de Google OAuth es el proceso de aprobación formal mediante el cual Google confirma que tu aplicación gestiona los datos de los usuarios de conformidad con sus políticas. Hasta que tu aplicación supere esta revisión, se considerará no verificada, lo que significa que los usuarios verán una pantalla de advertencia y que tendrás un límite máximo de 100 usuarios de prueba. La revisión es obligatoria siempre que tu aplicación solicite ámbitos de la API de Gmail sensibles o restringidos a usuarios externos (no internos).
Los telescopios sensibles: qué son
Los ámbitos sensibles permiten que tu aplicación lea o modifique datos del usuario más allá de la información básica del perfil. En el caso de Gmail, estos incluyen:
gmail.lectura- leer todos los mensajesgmail.enviar- enviar correo electrónico en nombre del usuariogmail.modificar- leer, redactar, archivarmail.google.com- acceso completo (restringido)
Los ámbitos sensibles requieren una evaluación de seguridad de Google. Los ámbitos restringidos (como el acceso completo a IMAP) requieren además una auditoría CASA de nivel 2. Consulte la referencia completa de ámbitos en nuestro Guía de ámbitos de la API de Gmail.
¿Por qué la API de Gmail siempre lo activa?
A diferencia de un flujo básico de inicio de sesión de Google (que solo solicita datos del perfil), la API de Gmail siempre solicita ámbitos que otorgan acceso al contenido del buzón de un usuario. Google considera por definición cualquier permiso a nivel de buzón como sensible.
Esto significa que cualquier desarrollador que desee utilizar la API de Gmail para usuarios externos debe pasar por el proceso de verificación de aplicaciones de Google OAuth; no existe ninguna versión de la API de Gmail que permita eludir este requisito para su uso en producción.
¿No sabes si necesitas credenciales de OAuth o una simple clave API? Lee nuestra Clave API de Gmail vs. OAuth: Guía.
Diferencia clave: La verificación de Google OAuth no es un evento único. Si agregas nuevos ámbitos a una aplicación ya verificada, debes enviar la aplicación para una revisión adicional que cubra esos ámbitos. Planifica tu estrategia de ámbitos antes de comenzar el proceso; esto te ahorrará semanas.
Semanas de verificación.
Utilice Llave de Unipile y empezar ahora.
No pierdas clientes esperando la revisión de Google. Conecta cuentas de Gmail en 5 minutos con nuestras credenciales de desarrollador preverificadas.
Cómo obtener credenciales de la API de Gmail: paso a paso
Obtener las credenciales OAuth de la API de Gmail requiere seis pasos distintos en la Consola de Google Cloud. Aquí está la secuencia completa: desde crear su proyecto hasta tener un client_id y secreto_cliente.
- Crear un proyecto de Google Cloud - tu contenedor aislado de facturación y API.
- Habilitar la API de Gmail - activa la API en la Biblioteca de API para tu proyecto.
- Configurar la pantalla de consentimiento de OAuth - elige el tipo de aplicación (externa vs. interna), completa el nombre de la aplicación, el correo electrónico de soporte y los dominios autorizados.
- Añadir ámbitos - selecciona los ámbitos de Gmail que tu aplicación necesita; esto determina si se requiere una revisión de seguridad.
- Crear un ID de cliente OAuth - elige el tipo de aplicación (Web, Escritorio o iOS/Android) y registra tus URI de redirección.
- Enviar para verificación - si tu aplicación es externa y usa ámbitos sensibles, envíala a través del portal de verificación de Google.
Ir a console.cloud.google.com, haz clic en el selector de proyectos en la barra de navegación superior y selecciona "Nuevo proyecto". Asígnale un nombre que refleje tu producto; aparecerá en la pantalla de consentimiento de OAuth que ven los usuarios.
Activa la facturación en el proyecto aunque preveas que no superarás los límites de uso gratuito. Muchas API (incluido Gmail) exigen que se asigne una cuenta de facturación antes de poder activarlas, incluso con un uso de $0.
Consola de Google Cloud: crea un nuevo proyecto a través del selector de proyectos en la barra de navegación superior.
En la consola de Google Cloud, navega a "APIs y servicios" > "Biblioteca". Busca "Gmail API" y haz clic en "Habilitar". También es probable que quieras habilitar la API de Google People si necesitas datos de contactos junto con el correo electrónico.
Después de habilitar, la API de Gmail aparece en tu panel "APIs habilitadas". Las llamadas a la API sin credenciales válidas devolverán un 403 accesoNoConfigurado error incluso en esta etapa: las credenciales vienen a continuación.
Biblioteca de API de Google: busca "API de Gmail" y haz clic en Habilitar para activarla para tu proyecto.
Ve a "APIs y servicios" > "Pantalla de consentimiento de OAuth". Elige tu tipo de usuario:
- Interno - solo usuarios dentro de tu organización de Google Workspace. No se requiere verificación.
- Externo - cualquier cuenta de Google. Se requiere verificación para ámbitos sensibles/restringidos más allá de 100 usuarios de prueba.
Pantalla de consentimiento de OAuth: elige Interno (solo Workspace) o Externo (cualquier cuenta de Google) como tipo de usuario.
Rellena el Nombre de la aplicación, el Correo electrónico de soporte al usuario y el correo electrónico de contacto del desarrollador. Estos campos aparecen en la pantalla de consentimiento que ven los usuarios al autorizar tu aplicación. Añade tu dominio autorizado (el dominio de la URL de tu página principal y de la política de privacidad).
Para un recorrido detallado de cada campo, el límite de 100 usuarios y la elección entre Interno y Externo, consulte nuestro Guía de configuración de la pantalla de consentimiento.
Información de la aplicación: ingrese el nombre de la aplicación, el logo y el correo electrónico de soporte exactamente como deben aparecer en la pantalla de consentimiento.
Dominio de la aplicación: proporcione URL activas para su página principal, política de privacidad y términos de servicio. El equipo de revisión de Google revisa esto.
Dominios autorizados: agregue el dominio raíz de su aplicación. Solo las URI de este dominio se pueden usar como URI de redirección.
Información de contacto del desarrollador: Google utiliza este correo electrónico para notificarle sobre cambios en el estado de verificación de su aplicación.
Consejo: La sección "Dominio de la aplicación" acepta varios enlaces (Página de inicio, Política de privacidad, Términos de servicio). El equipo de verificación de Google comprobará que estas URL estén activas y reflejen los alcances que está solicitando. Una URL de política de privacidad faltante o rota es una de las razones más comunes por las que se rechazan las verificaciones.
En la configuración de la pantalla de consentimiento, haz clic en "Añadir o quitar ámbitos". Usa el filtro para encontrar los ámbitos de Gmail. El ámbito que elijas tiene un impacto directo en tu ruta de verificación:
gmail.enviarogmail.lectura- sensible, requiere evaluación de seguridad.gmail.modificaromail.google.com- restringido, requiere CASA Nivel 2 adicional.openid email profilesolo - no se necesita verificación (inicio de sesión básico).
Agregar o Quitar alcances: selecciona los alcances de Gmail que tu aplicación requiere. La selección de alcances determina directamente tu ruta de verificación.
Selecciona el alcance del plan cuidadosamente. Añadir un alcance restringido más tarde implica reenviar la aplicación completa para una revisión adicional de Nivel 2 de CASA. Para la referencia completa del alcance y qué APIs desbloquea cada alcance, consulta Guía de ámbitos de la API de Gmail.
Ve a "APIs y servicios" > "Credenciales" > "Crear credenciales" > "ID de cliente de OAuth". Selecciona el tipo de aplicación:
- Aplicación web - para aplicaciones del lado del servidor. Registra tus URIs de redireccionamiento (p. ej.
https://yourapp.com/oauth/callback). - Aplicación de escritorio - para aplicaciones instaladas. Usa redirección loopback.
- iOS / Android - aplicaciones móviles, usan esquemas URI personalizados.
Panel de credenciales: seleccione "ID de cliente OAuth" para generar el client_id y client_secret que su aplicación necesita.
Después de la creación, descarga el archivo de credenciales JSON. Contiene tus client_id, secreto_cliente, y URIs de redireccionamiento registrados. Almacénalo de forma segura: nunca lo incluyas en el control de versiones.
Para una inmersión profunda en la diferencia entre este tipo de credencial y una clave API simple, consulta nuestra Clave de API de Gmail vs. credenciales de OAuth: guía.
Tokens de acceso y tokens de actualización: cuando un usuario completa el flujo de OAuth, recibes un token_de_acceso (válido ~1 hora) y un token de actualización (de larga duración, almacenado en el lado del servidor). Tu servidor utiliza el token de actualización para obtener nuevos tokens de acceso sin volver a solicitar la autenticación al usuario. Solicita siempre access_type=offline y consentimiento en la primera autorización para recibir el token de actualización. Almacene los tokens de actualización cifrados en reposo.
Para una visión más amplia de cómo OAuth encaja en la arquitectura de la API de correo electrónico, incluyendo estrategias de sincronización y diferencias entre proveedores, consulta nuestro Guía de la API de correo electrónico de OAuth.
Usa la clave de UnipileLa advertencia "Esta aplicación no está verificada", el límite de 100 usuarios y las exenciones
Antes de que tu aplicación pase la verificación de aplicaciones de Google OAuth, cada usuario que intente autorizarla verá una pantalla de advertencia. Google también impone un límite estricto de 100 usuarios en las aplicaciones externas no verificadas. Esto es exactamente lo que significa y cuándo no se aplica.
La pantalla dice: "Esta aplicación no está verificada. Esta aplicación no ha sido verificada por Google. Puede estar solicitando acceso a información confidencial. Obtenga más información sobre los riesgos". Los usuarios deben hacer clic en "Avanzado" y luego en "Ir a [Nombre de la aplicación] (no seguro)" para continuar. La mayoría de los usuarios no técnicos se detendrán aquí; este es el costo real de omitir o retrasar la verificación.
Cuando la verificación de la aplicación de Google OAuth NO es necesaria
Solo uso interno
Si configuras tu pantalla de consentimiento de OAuth en "Interno" y tu aplicación solo atiende a usuarios dentro de tu propia organización de Google Workspace, no se requiere ninguna verificación, independientemente de los ámbitos que solicites. Este es el camino más rápido para las herramientas internas.
Modo de prueba (menos de 100 usuarios)
Una aplicación externa no verificada puede tener hasta 100 usuarios de prueba añadidos a través de la Consola de Google Cloud. Esos usuarios específicos pueden autorizar la aplicación sin ver un bloqueo total; ven la advertencia pero pueden continuar. Útil para desarrollo y beta privada con un equipo pequeño.
Alcances básicos solamente
Si tu aplicación solo solicita ámbitos no sensibles (openid, email, profile - inicio de sesión básico de Google), no se necesita verificación, incluso para usuarios externos de cualquier escala. La verificación se activa específicamente por ámbitos sensibles y restringidos.
Marco importante: La intención del límite de 100 usuarios y la pantalla de advertencia es proteger a los usuarios mientras una aplicación está siendo revisada. La respuesta correcta al alcanzar el límite es enviar tu aplicación para la verificación de la aplicación Google OAuth, no crear múltiples proyectos de Google Cloud para distribuir a los usuarios entre ellos. Google prohíbe explícitamente ese enfoque y puede resultar en la suspensión de tu cuenta de desarrollador. El camino compatible es verificar tu aplicación o utilizar una plataforma que ya proporcione una clave OAuth verificada, como Unipile.
Verificación de aplicaciones de Google: cronograma y costo en 2026
La verificación de aplicaciones de Google no es un proceso único; tiene tres vías distintas según los alcances que solicite tu aplicación. Cada vía tiene su propio plazo y costo. Esto es lo que puedes esperar en 2026.
Si tu aplicación solo utiliza ámbitos no confidenciales (inicio de sesión básico de Google), Google aún puede requerir la verificación de marca para confirmar la identidad de tu aplicación y el dominio de su página principal. Este es un proceso que generalmente toma de 2 a 3 días hábiles y no tiene costo adicional a tu tiempo.
Necesitarás verificar la propiedad del dominio a través de Google Search Console y asegurarte de que tu pantalla de consentimiento de OAuth describa con precisión tu aplicación.
Las aplicaciones que solicitan ámbitos sensibles de Gmail deben pasar por la evaluación completa de seguridad de Google. El equipo de Google revisa las prácticas de manejo de datos de su aplicación, su política de privacidad y la justificación de cada ámbito que solicita.
El tiempo de entrega típico es 2-4 semanas Cuando su envío esté completo. Los envíos incompletos (política de privacidad faltante, justificaciones vagas del alcance, dominios autorizados no coincidentes) reiniciarán el reloj. Google puede solicitar una demostración o documentación adicional durante este período.
Aplicaciones que solicitan alcances restringidos - principalmente https://mail.google.com/ (acceso completo a nivel IMAP) - debe completar un Evaluación de seguridad CASA Nivel 2 Además de la propia revisión de Google. CASA (Evaluación de Seguridad de Aplicaciones en la Nube) es una auditoría de seguridad independiente realizada por un laboratorio aprobado por Google.
En 2026 Google ofrece una Ruta de autoservicio CASA Nivel 2 a través de laboratorios aprobados, típicamente costando $540-$1.000 (tasas de laboratorio para escaneo automatizado). Esta es una mejora significativa sobre el sistema heredado. La evaluación de seguridad anterior, manual y requerida previamente por Google para la misma clase de alcance, costaba $15 000-$75 000 y tomó meses; esa vía heredada todavía se aplica a algunas aplicaciones "grandfathered" y casos extremos empresariales. Al presupuestar, confirme con su laboratorio elegido qué vía se aplica a su aplicación.
Cronología total incluyendo la propia revisión de Google después de CASA: 4-12 semanas de la primera presentación a la aprobación.
Resumen de costos: Verificación de aplicaciones de Google OAuth en 2026
| Pista de verificación | Ámbito de nivel | Cronología | Coste |
|---|---|---|---|
| Verificación de marca | No sensible (openid, email, profile) | 2-3 días hábiles | Gratis |
| Evaluación de seguridad | Sensible (gmail.send, gmail.readonly, gmail.modify) | 2-4 semanas | Gratis |
| CASA Nivel 2 (autoservicio, 2026) | Restringido (mail.google.com) | 4-8 semanas | ~$540-$1.000 |
| CASA Nivel 2 (manual heredado, pre-2025) | Restringido (mail.google.com) | 8-12 semanas | $15k-$75k |
Fuentes: Políticas de Google OAuth 2.0 (developers.google.com) y Google Cloud - Verificación de aplicaciones OAuth: descripción general (support.google.com). Los precios del autoservicio de CASA Nivel 2 se basan en las tarifas de laboratorio aprobadas a partir del primer trimestre de 2026 y pueden variar en función del laboratorio y del número de aplicaciones evaluadas. La vía tradicional $15k-$75k se aplicaba a las aplicaciones que se sometieron al anterior programa obligatorio de evaluación de seguridad de proveedores de Google antes de que estuviera disponible la opción de autoservicio de CASA.
Evita la esperaErrores comunes de Google OAuth con los que te encontrarás
Cuando administras tu propio proyecto de Google Cloud, aparecen repetidamente varios errores durante el desarrollo y después de la puesta en marcha. Aquí tienes una referencia rápida de los seis más comunes.
La URI de redirección en tu solicitud no coincide exactamente con una registrada en la Consola de Google Cloud (el protocolo, la barra final y el puerto son importantes).
El administrador de Google Workspace del usuario ha bloqueado las aplicaciones OAuth de terceros o ha restringido los ámbitos específicos que tu aplicación está solicitando.
Tu app usa ámbitos sensibles o restringidos pero no ha completado el proceso de verificación de Google, por lo que Google bloquea el consentimiento para nuevos usuarios.
El token de actualización ha expirado o ha sido revocado (el usuario cambió la contraseña, revocó el acceso o el token ha estado inactivo durante 6 meses). El usuario debe volver a autenticarse.
La pantalla de consentimiento está mal configurada en Google Cloud Console: tipo de usuario incorrecto (interno vs. externo), usuarios de prueba faltantes o la aplicación aún está en estado de borrador.
Una cadena de ámbito contiene un error tipográfico, o la API correspondiente (por ejemplo, la API de Gmail) no se ha habilitado en la Google Cloud Console para tu proyecto.
¿Necesitas el diagnóstico completo? Cada uno de estos errores tiene una solución específica. Consulta nuestra guía completa para Errores comunes de Google OAuth y la API de Gmail y cómo solucionarlos.
Cuando OAuth es manejado por Unipile, un intermediario técnico independiente que actúa en nombre de cada usuario autenticado, estos errores se gestionan en la capa de API. Unipile ya tiene la certificación CASA Nivel 2, por lo que los obstáculos de verificación se manejan una vez, no una vez por proyecto.
Semanas de verificación.
Utilice Llave de Unipile y empezar ahora.
No pierdas clientes esperando la revisión de Google. Conecta cuentas de Gmail en 5 minutos con nuestras credenciales de desarrollador preverificadas.
Google OAuth, Simplificado: DIY vs. gestionado - ¿lanzar ahora o esperar semanas?
Si tu aplicación necesita acceso a Gmail para usuarios externos, te enfrentas a dos caminos: ejecutar tu propio proyecto de Google Cloud a través del proceso completo de verificación de aplicaciones de Google OAuth (6-12 semanas), o construir sobre una plataforma que ya tiene una clave OAuth certificada de Nivel 2 CASA (1-2 días). Así es como se desarrolla cada camino y por qué no son mutuamente excluyentes.
La lectura estratégica: La ruta DIY tiene sentido a largo plazo si deseas la propiedad total de tu marca OAuth y la pantalla de consentimiento. La ruta administrada (Unipile) tiene sentido cuando necesitas lanzar ahora, evitar el límite de 100 usuarios o diferir el costo de CASA Nivel 2. Estas rutas no son mutuamente excluyentes: puedes crear en Unipile hoy y ejecutar tu propia certificación en paralelo, luego cambiar a tus propias credenciales (Bring Your Own Credentials) cuando tu aplicación sea verificada.
Si tu caso de uso es solo para Workspace (herramientas internas, automatización de RR. HH., sin consentimiento por usuario), la alternativa de servidor a servidor es una cuenta de servicio con Delegación en todo el dominio. Consulta nuestra Cuenta de servicio de Gmail y guía DWD.
Nota de cumplimiento: Unipile es un intermediario técnico independiente, no afiliado, respaldado o patrocinado por Google. El cliente OAuth de Google de Unipile está certificado como CASA Nivel 2, lo que permite a sus usuarios autorizar el acceso a Gmail sin ver una advertencia de "aplicación no verificada". Esto no es una solución alternativa para la revisión de seguridad de Google: la revisión aún se aplica si usted crea su propia aplicación de Google Cloud; Unipile ya la ha superado para las conexiones que intermedia en su nombre. Los usuarios pueden revocar el acceso en cualquier momento a través de la página de permisos de su Cuenta de Google.
Prueba ahora en Unipile's clave certificada, certificar en paralelo, cambiar cuando esté listo
No tienes que elegir entre enviar rápido y poseer tus credenciales de Google. Unipile actúa como un intermediario técnico independiente: su cliente de Google OAuth ya está certificado por CASA Tier 2, por lo que tus usuarios nunca verán la advertencia de aplicación no verificada y no hay un límite de 100 usuarios. Ejecuta tu propia verificación de aplicaciones de Google en paralelo, luego cambia a tus propias credenciales (Bring Your Own Credentials) en cualquier momento. Aquí está el proceso de 3 pasos.
Prueba en la clave certificada: envío en minutos
Crea una cuenta gratuita de Unipile y genera una clave API. Usa el endpoint de autenticación alojado para generar una URL de un solo enlace para cada usuario. Redirige a tu usuario a esa URL: la pantalla de consentimiento OAuth de Google de Unipile (ya certificada como CASA Nivel 2) se encarga de la autorización. Tu usuario nunca verá una advertencia de "aplicación no verificada".
Cuando la autorización se completa, Unipile envía un webhook a tu servidor con el ID de la cuenta vinculada. A partir de ese momento, tu aplicación puede leer, enviar y sincronizar Gmail a través de la API unificada de Unipile. sin crear un solo proyecto de Google Cloud.
// Paso 1: generar una URL de autenticación de un enlace para su usuario
const res = await fetch('https://api.unipile.com/api/v1/hosted/cuentas', {
method: POST,
cabeceras: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Content-Type': aplicación/json
},
body: JSON.stringify({
tipo: 'GOOGLE',
nombre: 'usuario-456', // tu ID de usuario interno
expiraEn: '2027-01-01',
notify_url: 'https://tuapp.com/webhooks/unipile'
})
});
const { url } = await res.json();
// Redirige al usuario a `url`: la pantalla de consentimiento certificado de Unipile se encarga del resto.Ejecuta tu propia verificación de Google OAuth en paralelo
Mientras tu producto está activo y los usuarios están en uso, configura tu propio proyecto de Google Cloud y envía tu aplicación para la verificación de la aplicación de Google OAuth. Sigue la configuración de credenciales de 5 pasos anterior. Si tu aplicación utiliza ámbitos restringidos, inicia tu evaluación de autoservicio de Nivel 2 de CASA a través de un laboratorio aprobado por Google.
Hay sin urgencia a este paso mientras estás en la clave certificada de Unipile: tus usuarios no están bloqueados, no ven ninguna advertencia y no hay límite de usuarios. Ejecuta el proceso al ritmo que mejor se adapte a tu equipo: típicamente de 2 a 4 semanas para ámbitos sensibles, de 4 a 12 semanas si se necesita CASA Tier 2.
Para obtener orientación sobre la selección del alcance, consulte nuestra Guía de ámbitos de la API de Gmail - elegir alcances mínimos puede moverte de la vía restringida (requerida por la CASA) a la vía sensible (revisión gratuita), ahorrando tiempo y costes.
Cambiar a sus propias credenciales (BYOC): un cambio de configuración
Una vez que tu aplicación de Google Cloud esté verificada y tengas tu propio client_id y secreto_cliente, configura Unipile para utilizar tus propias credenciales de OAuth para nuevas conexiones de cuenta. Este es el modelo Bring Your Own Credentials (BYOC): Unipile continúa actuando como un intermediario técnico independiente procesando solicitudes en nombre de cada usuario autenticado, ahora usando tus credenciales verificadas en lugar de la clave compartida.
Las cuentas vinculadas existentes permanecen activas. El cambio solo afecta a las nuevas autorizaciones. Tus usuarios ven el nombre de tu aplicación verificada en la pantalla de consentimiento, reemplazando la pantalla con la marca Unipile. Elegiste cuándo invertir en la verificación, no desde el primer día, cuando necesitabas lanzar.
Microsoft es diferente: por qué Azure no necesita una revisión al estilo CASA
Si su aplicación necesita acceder tanto a Gmail como a Outlook, la carga de verificación es asimétrica. La verificación de aplicaciones de Google OAuth, incluida una posible auditoría de Nivel 2 de CASA, se aplica solo a Google. El enfoque de Microsoft Azure para el registro de aplicaciones y el consentimiento de OAuth es arquitectónicamente diferente y no requiere una auditoría de seguridad externa equivalente.
Cualquier aplicación que solicite ámbitos de Gmail sensibles o restringidos de usuarios externos debe pasar la evaluación de seguridad de Google. Los ámbitos restringidos requieren además CASA Nivel 2.
- Advertencia de aplicación no verificada que se muestra a los usuarios
- Límite estricto de 100 usuarios hasta ser verificado
- Se requiere CASA Nivel 2 para ámbitos restringidos (autoservicio ~$540-$1k)
- Se requiere una nueva revisión cuando se agregan alcances sensibles nuevos
- Cronograma: 2-12+ semanas dependiendo del nivel de alcance
Azure Active Directory (ahora Microsoft Entra ID) utiliza un modelo de consentimiento de administrador para ámbitos de alta privilegio. No existe un requisito de auditoría externo estilo CASA para los ámbitos estándar de acceso al correo.
- No hay advertencia de aplicación no verificada para flujos estándar
- No hay tope de usuario durante el desarrollo
- No existe auditoría de seguridad externa obligatoria
- Se requiere consentimiento del administrador para permisos en todo el inquilino en inquilinos empresariales
- Microsoft 365 cubre tanto Outlook personal como Exchange Online empresarial a través del mismo flujo OAuth
Implicación práctica para aplicaciones multigalicia: si está creando un producto que lee correos electrónicos de cuentas de Gmail y Outlook, el cronograma de verificación de su aplicación de Google OAuth rige su fecha de lanzamiento, no el de Microsoft. Este es uno de los argumentos más sólidos para usar la API unificada de Unipile: ambos proveedores se manejan a través de una única integración, y la clave certificada de Unipile cubre el requisito de Nivel 2 de CASA de Google de inmediato, eliminándolo por completo de su ruta crítica.
Para una inmersión profunda en el lado de Microsoft de esta ecuación, incluyendo el registro de aplicaciones de Azure, los flujos de consentimiento y el acceso a la API de Microsoft Graph, consulte nuestra Guía OAuth de Microsoft Graph.
Cómo Unipile maneja tus datos
Unipile es un intermediario técnico independiente. Las siguientes tres notas explican exactamente cómo fluyen los datos, qué almacena Unipile y cuáles son sus responsabilidades como cliente, en el contexto del acceso a la API de Google OAuth y Gmail.
Qué almacena Unipile y qué no
Unipile no mantiene un archivo paralelo ni una copia independiente de los datos de Gmail de sus usuarios. Cuando su aplicación solicita datos de correo electrónico a través de la API de Unipile, Unipile los recupera de los servidores de Google. en nombre del usuario autenticado y lo devuelve a tu aplicación. Los datos están estrictamente limitados a la sesión del usuario autenticado y a los permisos que otorgó durante el flujo de OAuth. Unipile no conserva el contenido de los mensajes más allá de lo necesario para cumplir con la respuesta de la API.
Intermediario técnico independiente - No es un socio de Google
Unipile opera como un intermediario técnico independiente, actuando en nombre de cada usuario autenticado que ha otorgado acceso a través de la pantalla de consentimiento de OAuth. Unipile es no afiliado con, avalado por, ni patrocinado por Google. - Unipile no comparte credenciales entre usuarios: cada cuenta vinculada utiliza sus propios tokens OAuth, con el ámbito de la autorización de ese usuario. Su aplicación accede a los datos de Gmail solo para los usuarios que han completado explícitamente el flujo OAuth y han otorgado los permisos solicitados.
Los límites de velocidad de Google aplican, las decisiones de uso son suyas
Unipile transmite los límites de tasa y las restricciones de cuota de la API de Gmail de Google a su aplicación. La API de Gmail aplica cuotas por usuario (por ejemplo, 250 unidades de cuota por segundo por usuario, 1.000.000.000 unidades de cuota por día por proyecto). Unipile expone estos límites pero no los anula. Las decisiones sobre la cadencia de solicitudes, el volumen de datos y el alcance del consentimiento del usuario siguen siendo una decisión del lado del cliente. Eres responsable de garantizar que el uso de los datos de Gmail por parte de tu aplicación cumpla con los Términos de Servicio de la API de Google y con las expectativas de tus usuarios según lo divulgado en tu política de privacidad.
Para una visión completa de las capacidades de la API de correo electrónico, incluyendo envío, lectura y sincronización a través de Gmail, Outlook e IMAP, consulte nuestra Guía de la API de correo electrónico.
Construir con UnipilePreguntas frecuentes de Google OAuth para desarrolladores
Respuestas a las preguntas más comunes sobre la verificación de aplicaciones de Google OAuth, credenciales de la API de Gmail y OAuth administrado a través de Unipile.
Tu aplicación necesita la verificación de la aplicación de Google OAuth si está configurada para Externo tipo de usuario en la pantalla de consentimiento de OAuth y solicita ámbitos de Gmail sensibles o restringidos de usuarios fuera de su propia organización de Google Workspace. Si tu aplicación solo solicita ámbitos básicos (openid, email, perfil) o está configurado como Interno, no se requiere verificación. Cualquier ámbito que otorgue acceso al buzón de un usuario, como gmail.lectura, gmail.enviar, gmail.modificaro mail.google.com, es sensible o restringida y activa el requisito.
La línea de tiempo depende del nivel de alcance que utilice tu aplicación. Verificación de marca (ámbitos no sensibles): 2-3 días hábiles. Revisión de alcance sensible (gmail.enviar, gmail.lectura, gmail.modificartípicamente 2-4 semanas cuando su envío esté completo. CASA Nivel 2 + ámbitos sensibles/restringidos (mail.google.com): 4-12 semanas en total. Las presentaciones incompletas, como la falta de política de privacidad, justificaciones de alcance imprecisas o dominios autorizados que no coinciden, reinician el reloj.
Evaluación de seguridad propia de Google (para ámbitos sensibles como gmail.enviar y gmail.lectura) es gratis. La verificación de marca también es gratuita. Si tu aplicación utiliza ámbitos restringidos (mail.google.com), necesita una auditoría CASA Nivel 2 por un laboratorio aprobado por Google. El camino de autoservicio CASA Nivel 2 para 2026 cuesta aproximadamente De $540 a $1.000 en honorarios de laboratorio. La evaluación manual anterior, que requería el mismo alcance de clase, costaba De $15 000 a $75 000 y esa pista heredada todavía se aplica a algunos casos extremos y aplicaciones exentas.
No puedes omitir la verificación de la aplicación de Google para una aplicación de producción que atiende a usuarios externos con ámbitos sensibles de Gmail. El límite de 100 usuarios y la advertencia de aplicación no verificada se aplican hasta que tu aplicación sea verificada. Las alternativas que cumplen son: configurar tu aplicación en Interno (si solo sirve para los usuarios de tu propio Workspace), usa Clave OAuth certificada CASA Tier 2 de Unipile mientras su propia verificación se ejecuta en paralelo, o solicite solo alcances no confidenciales que no activen la verificación. La creación de varios proyectos de Google Cloud para distribuir usuarios entre ellos está prohibida por las políticas de Google y puede resultar en la suspensión de la cuenta.
Ver El punto final de la API de Gmail administrado de Unipile.La advertencia de la aplicación no verificada de la API de Gmail aparece cuando tu pantalla de consentimiento de OAuth está configurada como Externa y tu aplicación solicita ámbitos de Gmail sensibles o restringidos pero aún no ha completado el proceso de verificación de Google. Se muestra a todos los usuarios fuera de tu lista de 100 usuarios de prueba. Para resolverlo: envía tu aplicación para Verificación de la aplicación de Google OAuth a través de la Consola de Google Cloud, o cree sobre la clave OAuth pre-verificada y certificada como CASA Nivel 2 de Unipile. Los usuarios que se conectan a través del flujo de autenticación alojado de Unipile nunca ven esta advertencia.
CASA Nivel 2 (Evaluación de seguridad de aplicaciones en la nube) es una auditoría de seguridad independiente requerida por Google para las aplicaciones que solicitan ámbitos restringidos, principalmente https://mail.google.com/, que otorga acceso completo a Gmail a nivel IMAP. Es realizado por un laboratorio aprobado por Google. En 2026 habrá una ruta de autoservicio disponible aproximadamente De $540 a $1.000. Solo necesitas CASA Tier 2 si tu aplicación solicita el mail.google.com alcance de usuarios externos. Si solo usas alcances sensibles (gmail.enviar, gmail.lectura, gmail.modificar), CASA Nivel 2 no es necesario. Se aplica la evaluación de seguridad gratuita estándar de Google.
A Clave de API de Gmail es para solicitudes públicas no específicas del usuario y no otorga acceso al buzón de ningún usuario. Credenciales de OAuth de la API de Gmail (client_id + secreto_clientese utilizan para obtener autorización por usuario para acceder a sus datos de Gmail en su nombre. Para cualquier función que lea, envíe o modifique el correo electrónico de un usuario, necesitará credenciales de OAuth, no una clave de API. Para una comparación detallada, consulte nuestro Clave API de Gmail vs. OAuth: Guía.
¿Todavía tienes preguntas sobre la verificación de aplicaciones de Google OAuth o el OAuth de Gmail administrado? Nuestro equipo está aquí para ayudarte.
Hable con un experto
ES 
EN 
FR 
DE 
IT 
BR 
NL 
PL 
TR