LinkedIn
Instagram
WhatsApp
Telegrama
Calendario de Google
Únase a la comunidad SlackOAuth Email API: Autenticar buzones de correo de usuario El Camino Correcto
Deja de almacenar contraseñas. Una API de correo electrónico OAuth permite a tu aplicación acceder a las bandejas de entrada de los usuarios de forma segura, utilizando tokens revocables y con alcance limitado de Gmail, Outlook y proveedores IMAP. Esta guía cubre todos los flujos de OAuth, todos los ámbitos, todos los errores comunes y cómo lanzar en 5 minutos con una capa de autenticación unificada alojada.
// Conecta cualquier buzón de usuario a través de OAuth - 1 llamada a la API
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'TU_CLAVE_API',
'Content-Type': aplicación/json
},
body: JSON.stringify({
tipo: 'GOOGLE', // o MICROSOFT, IMAP
nombre: 'usuario_123'
})
}
);
const { url } = await respuesta.json();
// Redirigir al usuario a la URL - OAuth gestionado por Unipile
¿Qué es una API de correo electrónico OAuth?
En API de correo electrónico OAuth es una interfaz programática que otorga a tu aplicación acceso a los buzones de correo de los usuarios mediante tokens OAuth 2.0, sin necesidad de manejar o almacenar nunca la contraseña del usuario. En lugar de pedir credenciales a los usuarios, los rediriges a través de la pantalla de consentimiento del proveedor, recibes un token de acceso de corta duración y lo utilizas para leer, enviar o sincronizar correos electrónicos en su nombre. La distinción es importante: se trata de acceder buzones de propiedad del usuario (Gmail, Outlook, correo personal), no enviar correos electrónicos transaccionales a través de servicios de retransmisión SMTP como SendGrid.
En API de correo electrónico OAuth es una combinación de un flujo de autorización OAuth 2.0 (para autenticar a un usuario y obtener acceso delegado) y una API de correo electrónico (para leer, enviar, buscar o sincronizar el buzón de ese usuario). La capa OAuth genera un token de acceso criptográficamente firmado, revocable y con alcance limitado. La API de correo electrónico consume ese token para interactuar con Gmail, Outlook o cualquier buzón compatible con IMAP, todo sin conocer nunca la contraseña del usuario.
- Almacena contraseñas en texto plano o cifradas en tu base de datos
- Acceso completo al buzón, sin control de alcance
- Bloqueado por Google/Microsoft desde 2026
- Responsabilidad del RGPD/SOC2 en el almacenamiento de credenciales
- Almacenamiento de contraseñas cero: solo tokens de corta duración
- Alcances granulares: solo lectura, solo envío o completos
- Revocable en cualquier momento por el usuario
- Cumple con GDPR, SOC2
Por qué OAuth reemplazó el acceso al correo electrónico basado en contraseñas
El uso de IMAP con nombre de usuario y contraseña solía ser la forma estándar de acceder al correo electrónico del usuario mediante programación. Esa época ha terminado. Google dejó de usar la autenticación básica para Gmail en 2022, y Microsoft completó el cierre de la autenticación básica para Exchange Online en octubre de 2022, con la última revisión para los protocolos restantes en 2026. Si tu aplicación todavía depende del acceso IMAP basado en contraseñas, ya está rota o se romperá pronto.
Los tokens OAuth tienen una vida corta (típicamente 1 hora) y están limitados en su alcance. Incluso si se filtran, no pueden utilizarse para iniciar sesión como el usuario, cambiar su contraseña o acceder a otros servicios. Nunca se tocan las credenciales del usuario.
Microsoft completó su retiro de la autenticación básica para Exchange Online y el IMAP heredado en 2026. Cualquier aplicación que todavía use nombre de usuario + contraseña para acceder a los buzones de Outlook o Microsoft 365 recibirá errores 401 Unauthorized.
Almacenar contraseñas de usuario, incluso cifradas, crea una responsabilidad de cumplimiento. El principio de minimización de datos del RGPD exige que no recopiles lo que no necesitas. Los auditores de SOC2 marcan el almacenamiento de credenciales.
Crítico Las Contraseñas de Aplicaciones de Google y los protocolos heredados de Microsoft ya no son suficientes para aplicaciones de producción. Si estás creando un producto que accede a los buzones de correo de los usuarios, un API de correo electrónico OAuth no es opcional, es la única vía compatible a seguir en 2026.
Cómo funciona OAuth para las API de correo electrónico (paso a paso)
El flujo de código de autorización es el flujo estándar de OAuth 2.0 para aplicaciones del lado del servidor que necesitan acceder al correo electrónico del usuario. Entenderlo de principio a fin te ayuda a implementarlo correctamente, depurar fallos de tokens y explicar el flujo a tu equipo de seguridad.
Construyes una URL con tu client_id, a uri_redireccionamiento, la solicitada alcance, al azar estado parámetro (protección CSRF), y tipo_respuesta=código. El usuario es enviado a la pantalla de consentimiento de Google o Microsoft.
La pantalla de consentimiento muestra el nombre de tu aplicación, su logotipo y los permisos exactos que solicitaste. El usuario aprueba (otorga el consentimiento) o rechaza. Solicitar demasiados ámbitos en este paso es la causa más común de rechazo del consentimiento.
Después del consentimiento, el proveedor redirige a tu uri_redireccionamiento con una vida corta código parámetro (válido por ~10 minutos). Verifica estado el parámetro coincide con lo que enviaste para prevenir ataques CSRF.
POST de servidor a servidor al punto final del token con tu client_id, secreto_cliente, la códigoy grant_type=authorization_code. Recibes una token_de_acceso y (si solicitaste acceso sin conexión) un token de actualización.
Pasa el token de acceso en el Autorización: Bearer encabezado en cada solicitud de API. Cuando expire (normalmente después de 1 hora), use el token de actualización para obtener un nuevo token de acceso sin interacción del usuario.
Tokens de acceso frente a tokens de actualización: ciclo de vida
Válido por 1 hora (Google) o 1 hora (Microsoft). Se pasa en la cabecera Authorization en cada llamada a la API. Cuando expira, tu llamada a la API de correo electrónico OAuth devuelve un error 401, la señal para actualizar.
Válido hasta su revocación (Google) o 90 días de inactividad (Microsoft). Nunca se envía a puntos finales de API; solo se utiliza de servidor a servidor para obtener nuevos tokens de acceso. Debe estar cifrado en reposo.
Crea un flujo OAuth unificado en minutos
Evita la complejidad de la autorización por proveedor. Una llamada a la API de Unipile reemplaza tres integraciones OAuth.
Flujos de OAuth por Proveedor: Google y Microsoft
Google y Microsoft implementan OAuth 2.0 de manera diferente: diferentes puntos de conexión de autorización, diferentes alcances, diferentes puntos de conexión de tokens y diferentes procesos de verificación. IMAP es el respaldo basado en credenciales para proveedores sin OAuth estandarizado. Aquí tienes lo que necesitas saber para cada caso.
La implementación OAuth de Google utiliza el flujo de código de autorización estándar. El endpoint de token es https://oauth2.googleapis.com/token. La complejidad crítica es Google CASA (Cloud Application Security Assessment): una vez que tu aplicación supera los 100 usuarios, debes pasar una revisión de seguridad. Para ámbitos sensibles como gmail.modificar o gmail.lectura, la Verificación de la Aplicación es requerida antes de su uso en producción. Para una completa Inmersión profunda en la integración de la API de Gmail, consulte nuestra guía dedicada. Los detalles de implementación se encuentran en la Documentación de Google OAuth de Unipile.
Código de autorización de # para acceder a Gmail + tokens de actualización
rizo -X POST https://oauth2.googleapis.com/token \
-d "código=AUTH_CODE" \
-d "client_id=TU_CLIENT_ID" \
-d "client_secret=TU_CLIENT_SECRET" \
-d "redirect_uri=https://tutuapp.com/callback" \
-d "tipo_concesión=código_autorización"
Respuesta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
Microsoft utiliza su Plataforma de Identidad (anteriormente Azure AD v2). El punto final del token es https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. La verificación del editor es necesaria antes de que tu aplicación de API de correo OAuth pueda solicitar ámbitos de correo confidenciales en producción. Microsoft ha desaprobado la autenticación básica para todos los protocolos de Exchange Online; OAuth es obligatorio. Consulta nuestra Guía completa de correo electrónico de Microsoft Graph para más detalles, y el Documentación de Unipile Microsoft OAuth para referencia de implementación.
Código de intercambio # para tokens OAuth de Microsoft
rizo -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "código=AUTH_CODE" \
-d "client_id=TU_CLIENT_ID" \
-d "client_secret=TU_CLIENT_SECRET" \
-d "redirect_uri=https://tutuapp.com/callback" \
-d "tipo_concesión=código_autorización" \
-d "scope=https://graph.microsoft.com/Mail.Read offline_access"
Respuesta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP no es un proveedor OAuth: es un protocolo que se autentica con nombre de usuario/contraseña, o contraseñas de aplicaciones (como una contraseña de aplicación de Google o una contraseña generada por iCloud). Es la opción de reserva para servidores de correo personalizados, dominios corporativos que no están en Microsoft 365 y cualquier proveedor sin un flujo OAuth estandarizado. XOAUTH2 existió como una extensión SASL de IMAP para un pequeño número de proveedores, pero ha sido en gran medida abandonada; Yahoo descontinuó su implementación propia en 2022. Para la mayoría de las implementaciones de IMAP, Unipile se autentica directamente con las credenciales. Ver el completo Guía de integración IMAP para la configuración del servidor y los detalles de autenticación.
import base64, imaplib
#: Generar una cadena XOAUTH2 a partir del token de acceso de OAuth
def build_xoauth2(correo_electronico_usuario, token_de_acceso):
auth_str = f"usuario={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
#: Conexión mediante IMAP con XOAUTH2
conección = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = build_xoauth2("user@yahoo.com", clave_de_acceso)
conexión.autenticar("XOAUTH2", lambda x: auth_str)La complejidad oculta de OAuth multi-proveedor
Implementar una API de correo electrónico OAuth para un proveedor lleva unos días. Implementarla correctamente para Gmail, Outlook e IMAP, con gestión de tokens de nivel de producción, manejo de errores y cumplimiento, suele llevar de 4 a 8 semanas de tiempo de ingeniería. Aquí se explica por qué.
Google Cloud Console, Azure Portal y Yahoo Developer Network son 3 paneles completamente diferentes con una experiencia de usuario diferente, flujos de registro de aplicaciones diferentes y requisitos de verificación diferentes. Cualquier rotación de credenciales afecta a los 3.
Alcances confidenciales de Gmail (incluyendo gmail.lectura) tienen un límite de 100 usuarios hasta que se supere una evaluación de nivel 2 de CASA. Esto implica un laboratorio autorizado por CASA, una prueba de penetración y una revisión formal de seguridad; suele durar entre 6 y 12 semanas y cuesta entre 10 000 y 25 000 dólares.
Microsoft requiere la Verificación del Editor para las aplicaciones que solicitan ámbitos de correo confidenciales. Sin ella, los usuarios verán una advertencia roja de "editor no verificado" en la pantalla de consentimiento. El proceso de verificación requiere una cuenta activa de Microsoft Partner Network con un dominio verificado.
Los tokens de actualización de Google expiran después de 6 meses de inactividad (o inmediatamente si el usuario los revoca). Los tokens de Microsoft expiran después de 90 días de inactividad. Los tokens XOAUTH2 de Yahoo/IMAP tienen duraciones específicas del proveedor. Su capa de administración de tokens debe manejar los 3 de manera diferente.
Google, Microsoft y Yahoo muestran pantallas de consentimiento de forma diferente: distinta marca, distintas descripciones del alcance, distintos patrones de interfaz de usuario. Tus usuarios ven 3 flujos diferentes dependiendo de su proveedor de correo electrónico, creando una experiencia de usuario inconsistente y mayores tasas de abandono.
Los puntos finales de OAuth cambian. Los nombres de los alcances se descartan. Se agregan nuevos requisitos de seguridad. Cada proveedor anuncia cambios disruptivos en diferentes plazos. Alguien en tu equipo debe seguir 3 blogs de proveedores, 3 registros de cambios y 3 calendarios de cumplimiento, indefinidamente.
Omite la complejidad de OAuth por completo
Autenticación alojada, gestión de alcances, manejo de refresco. Unipile se encarga de todo para que puedas centrarte en tu producto.
Arquitectura de la API de correo electrónico OAuth: 3 enfoques comparados
Hay 3 arquitecturas para construir una capa de API de correo electrónico OAuth. Cada una tiene un costo de implementación, una carga de mantenimiento y un perfil de seguridad fundamentalmente diferentes. La elección correcta depende de si la conectividad de correo electrónico es su producto principal o una función que está implementando junto con su producto principal.
| Dimensión | OAuth Directo del Proveedor (x3) | Pasarela OAuth autohospedada | OAuth Unificado Alojado (Unipile) Recomendado |
|---|---|---|---|
| Tiempo hasta el primer buzón enlazado | 3-7 días (por proveedor) | 2-4 semanas | 5 minutos |
| Flujos de OAuth para implementar | 3 flujos separados | 3 flujos + lógica de enrutamiento | 1 enlace de host |
| Reseña de Google CASA | Tú te encargas (6-12 semanas, $10k+) | Tú te encargas | Manejado por Unipile |
| Verificación de Microsoft Publisher | Tú te encargas | Tú te encargas | Manejado por Unipile |
| Gestión de actualización de tokens | 3 estrategias para construir | Personalizado por proveedor | Automático, transparente |
| API de lectura/envío de correo electrónico | 3 API diferentes | Capa de abstracción requerida | 1 API REST unificada |
| Webhook en correos nuevos | Empujar/tirar por proveedor | A medida | Eventos unificados de webhook |
| Cumplimiento de SOC2 / RGPD | Su responsabilidad | Su responsabilidad | Unipile tiene certificación SOC2 |
| Mantenimiento continuo | Alto (3 registros de cambios de proveedor) | Alta | Cero - manejado por Unipile |
| Mejor para | Productos nativos de correo electrónico de un solo proveedor | Equipos grandes con infraestructura dedicada | Cualquier equipo que envíe rápido |
Construir vs. Comprar: API de correo electrónico OAuth alojada en 5 minutos
En lugar de construir 3 flujos OAuth separados, Unipile proporciona un enlace de autenticación alojado que se encarga de Google OAuth, Microsoft Identity e IMAP OAuth por usted. Su aplicación genera un enlace, redirige al usuario y recibe un webhook cuando la cuenta de correo está vinculada. La API de correo electrónico OAuth es inmediatamente utilizable: sin configuración en la consola, sin revisión de CASA, sin lógica de actualización de tokens que construir.
Paso 1: Generar un enlace de autenticación alojado
Una llamada a la API para crear una sesión de autenticación alojada. Especifique el tipo de proveedor y un nombre para la cuenta. Unipile devuelve una URL para redirigir a su usuario a la pantalla de consentimiento de OAuth.
// Conectar usuario de Gmail a través de la API de correo electrónico OAuth alojada por Unipile
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'TU_LLAVE_API_DE_UNIPILE',
'Content-Type': aplicación/json
},
body: JSON.stringify({
tipo: 'GOOGLE',
nombre: 'usuario_alice_123',
success_redirect_url: 'https://tappcom.com/conectado',
url_de_redireccionamiento_en_caso_de_fallo 'https://tuapp.com/error'
})
}
);
const { url, objeto } = await respuesta.json();
// Redirige al usuario a la URL - Unipile maneja el consentimiento OAuth
window.location.href = url;Paso 2: Conectar a un usuario de Outlook
El mismo punto final, el mismo patrón. Cambiar tipo a MICROSOFT. En el portal de Azure, no hay verificación de editor que gestionar de su lado.
import solicita
#: Conectar a un usuario de Outlook mediante la API de correo electrónico OAuth de Unipile
response = solicitudes.Correo electrónico:(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
encabezados={"Clave API X": "TU_CLAVE_API_DE_UNIPILE"},
json={
"tipo": "MICROSOFT",
"nombre": "usuario_bob_456",
"url_redireccion_exito": "https://tuapp.com/conectado"
}
)
auth_url = response.json()["url"]
# Redirección a auth_url: flujo de identidades de Microsoft gestionado por UnipilePaso 3: Recibir el webhook en account.connected
Después del consentimiento de OAuth, Unipile envía un webhook a tu endpoint. La carga útil del evento incluye el nuevo account_id - que almacenas y utilizas para todos los subsiguientes leer correo electrónico API y API para enviar correo electrónico llamadas.
Evento de webhook: Cuando un usuario completa OAuth, Unipile envía una cuenta.conectada evento a tu URL de webhook. La carga útil contiene account_id (guardar esto), el provider (GOOGLE / MICROSOFT / IMAP), y la dirección de correo electrónico vinculada. Este es el único estado que necesita persistir: Unipile administra todos los tokens OAuth internamente.
Olvida la implementación de OAuth de 8 semanas. Conecta buzones en minutos.
La API de correo electrónico OAuth alojada de Unipile maneja Google CASA, Verificación de Publicador de Microsoft, XOAUTH2 y la actualización de tokens para todos los proveedores. Tus usuarios vinculan su buzón a través de un único flujo alojado: obtienes una API unificada para leer, enviar y sincronizar.
Gestión de Tokens OAuth: Actualizar, Revocar, Rotar
La gestión de tokens es la parte más exigente operacionalmente de la construcción de una API de correo electrónico OAuth. Los tokens de acceso caducan, los tokens de actualización son revocados por los usuarios y tu sistema debe manejar todo esto con gracia, o correr el riesgo de que tus usuarios pierdan acceso a sus buzones de correo de forma silenciosa.
Mejores prácticas para el almacenamiento de tokens
- Cifra los tokens de actualización en reposo usando AES-256 o un KMS en la nube (AWS KMS, GCP Cloud KMS, Azure Key Vault). Nunca los almacenes en texto plano en tu base de datos.
- Nunca registres tokens de acceso ni tokens de actualización. Los sistemas de registro estructurado como Datadog o Splunk deben tener los campos de tokens enmascarados o redactados.
- Almacene los tokens en un almacén de secretos dedicado (Vault, AWS Secrets Manager) en lugar de en la base de datos principal de su aplicación, para minimizar el radio de explosión si la base de datos se ve comprometida.
- Implementar rotación de tokens: cuando recibas un nuevo token de actualización en una llamada de actualización (algunos proveedores emiten nuevos tokens de actualización en cada uso), invalida el anterior inmediatamente.
Manejo de fallos de actualización con gracia
Cuando un token de actualización expira o es revocado, su llamada de actualización devuelve un error 400 o 401. Su API de correo electrónico OAuth debe detectar esto y activar un flujo de reautenticación para el usuario, no fallar silenciosamente. El peor resultado es un usuario que cree que se están leyendo correos electrónicos, pero el token ha sido revocado durante semanas. Construya una comprobación explícita del estado de la cuenta y alerte a los usuarios cuando sea necesaria la reautenticación.
Ámbitos de OAuth: qué solicitar (y qué no)
La minimización de ámbitos es tanto una práctica recomendada de seguridad como una estrategia de optimización del consentimiento. Solicitar más ámbitos de los necesarios hace que los usuarios duden (o rechacen) en la pantalla de consentimiento y desencadena un escrutinio elevado durante las revisiones de Google CASA y Microsoft Publisher.
| Alcance | Proveedor | Caso de uso | Sensibilidad | ¿Reseña de CASA? |
|---|---|---|---|---|
| gmail.lectura | Gmail | Leer todos los correos electrónicos y metadatos | Alta | Sí - Nivel 2 |
| gmail.enviar | Gmail | Enviar correo electrónico como el usuario | Alta | Sí - Nivel 2 |
| gmail.modificar | Gmail | Leer, enviar, eliminar, etiquetar | Alta | Sí - Nivel 2 |
| gmail.etiquetas | Gmail | Leer y administrar etiquetas solamente | Bajo | No |
| Mail.Read | Outlook | Leer todo el correo | Mediano | Verificación del editor |
| Mail.Enviar | Outlook | Enviar correo como usuario | Mediano | Verificación del editor |
| Mail.ReadWrite | Outlook | Leer, enviar, eliminar, gestión de carpetas | Alta | Verificación del editor |
| acceso_sin_conexión | Outlook | Obtener tokens de actualización | Bajo | No |
| correo-r | IMAP (Yahoo) | Leer correo electrónico vía IMAP/XOAUTH2 | Mediano | Revisión de desarrollador de Yahoo |
Tokens actualizados y rotados para ti
Deja de escribir código de ciclo de vida de tokens. Conecta un buzón una vez, Unipile mantiene el acceso activo en todos los proveedores.
Cumplimiento: SOC2, GDPR, CASA
Una API de correo electrónico OAuth que administra buzones de usuario se encuentra en la intersección del cumplimiento de seguridad y privacidad. Aquí están los cuatro marcos que la mayoría de los compradores empresariales preguntarán y lo que el modelo de token de OAuth significa para cada uno.
Los auditores SOC2 analizan el manejo de tokens como parte de los criterios de Disponibilidad y Confidencialidad. Los tokens OAuth deben estar encriptados en reposo (AES-256 o KMS), registrados en el acceso y sujetos a una política de rotación formal. Almacenar tokens de actualización en texto plano es un hallazgo automático. El uso de una API de correo electrónico OAuth alojada como Unipile (que cuenta con certificación SOC2) traslada esta responsabilidad.
Bajo el RGPD, tu aplicación es un procesador de datos cuando accede al contenido del correo electrónico del usuario. Necesitas un Acuerdo de Procesamiento de Datos (APD) con el proveedor de tu infraestructura de API de correo electrónico OAuth. La revocabilidad de OAuth satisface directamente el Artículo 17 (derecho al olvido): cuando un usuario revoca, tu acceso finaliza inmediatamente. Documenta tu base legal para acceder a los datos del correo electrónico (típicamente el consentimiento a través del flujo OAuth).
Una vez que tu aplicación de la API de correo electrónico de Gmail OAuth supere los 100 usuarios con ámbitos sensibles, Google bloqueará la incorporación de nuevos usuarios hasta que superes el Nivel 2 de CASA. Esto requiere una prueba de penetración realizada por un laboratorio autorizado por CASA, un cuestionario de seguridad y un informe de evaluación formal que se debe enviar a Google. Plazo: entre 8 y 16 semanas. Coste: entre 10 000 y 25 000 TWD. Las aplicaciones verificadas obtienen la insignia "Verificado por Google" en su pantalla de consentimiento.
API de correo electrónico OAuth: Modelos de precios y costos
Las APIs de proveedores "gratuitas" de Google y Microsoft ocultan costos reales significativos. Aquí hay un modelo de costos realista para implementar una API de correo electrónico OAuth a escala, que cubre la ruta directa del proveedor frente a las APIs unificadas.
Las API de Google y Microsoft son técnicamente gratuitas a nivel de llamadas a la API. Sin embargo: el nivel 2 de Google CASA tiene un coste de entre 10 000 y 25 000 TP4T, además de requerir más de tres meses de trabajo de ingeniería. La verificación de editores de Microsoft exige una cuenta de Partner Network y la verificación legal del dominio. El tiempo de ingeniería necesario para desarrollar tres flujos, la gestión de tokens y la gestión de errores es de entre 6 y 10 semanas. El mantenimiento anual es de entre 2 y 4 semanas al año por proveedor.
La API de correo electrónico OAuth de Unipile incluye el cumplimiento de todos los proveedores (CASA, Verificación de editor), gestión de tokens y una API de correo electrónico unificada bajo una única suscripción. Para los equipos que envían conectividad de correo electrónico como una característica (no como un producto), el cálculo del retorno de la inversión es sencillo: semanas de tiempo de ingeniería ahorradas frente a un costo mensual de la API. Ver la comparar proveedores de API de correo electrónico guía para un desglose completo de costos.
Errores comunes al implementar el correo electrónico de OAuth
Estos son los errores más comunes que cometen los desarrolladores al crear una API de correo electrónico OAuth por primera vez, y qué hacer en su lugar.
Google invalida los tokens de actualización si el usuario no ha usado tu aplicación durante 6 meses. Tu llamada de actualización de token devuelve concesión_inválida. : Corregir: implementar una "verificación de estado del token" periódica que realice una llamada ligera a la API de Gmail para cada cuenta vinculada al menos una vez cada 30 días para evitar la caducidad por inactividad.
Solicitando gmail.modificar cuando solo necesitas gmail.lectura infla tu pantalla de consentimiento y causa que los usuarios abandonen el flujo OAuth. También escala tu requisito de nivel de CASA. Siempre solicita el alcance mínimo necesario. Puedes solicitar alcances adicionales de forma incremental más tarde.
El límite de 100 usuarios para el ámbito sensible de Gmail es el obstáculo de crecimiento más común para las implementaciones de API de correo electrónico OAuth. Planifique la revisión de CASA antes de alcanzar los 50 usuarios: la revisión toma de 8 a 16 semanas y su crecimiento de usuarios se verá bloqueado mientras esté pendiente.
El registro detallado de solicitudes que captura las cabeceras de autorización registrará sus tokens de acceso en texto plano. Implemente middleware de limpieza de registros que enmascare Portador [TOKEN] patrones antes de que los registros se escriban en cualquier almacenamiento persistente.
Algunos servidores de correo electrónico corporativos funcionan con configuraciones IMAP personalizadas que no admiten OAuth. Su API de correo electrónico OAuth debe tener una ruta de reserva en caso de que los proveedores sean solo IMAP. Implemente esto en su flujo de conexión de cuenta desde el primer día, o excluirá a un segmento significativo de usuarios B2B. Consulte nuestro Integración IMAP guía para el patrón de reserva completo.
Construir en lugar de unir proveedores
Obtenga una integración de correo electrónico OAuth funcional hoy mismo. Nivel gratuito, sin tarjeta de crédito, ámbitos completos de Gmail y Microsoft disponibles.
Preguntas frecuentes
Las preguntas más comunes que hacen los desarrolladores al crear una integración de API de correo electrónico OAuth, respondidas con precisión.
https://oauth2.googleapis.com/token, ámbitos en el gmail.* Espacio de nombres. En Outlook (Outlook.com, Microsoft 365 y Exchange Online): Plataforma de identidad de Microsoft, punto de conexión de tokens https://login.microsoftonline.com/common/oauth2/v2.0/token, ámbitos bajo https://graph.microsoft.com/. Para IMAP: IMAP no es un proveedor de OAuth. Utiliza credenciales de nombre de usuario/contraseña o contraseña de aplicación. XOAUTH2 existió como una extensión SASL para un pequeño número de proveedores, pero ha sido en gran medida obsoleto.grant_type=refresh_token. Para Google: POST a https://oauth2.googleapis.com/token. Para Microsoft: POST a https://login.microsoftonline.com/common/oauth2/v2.0/token. Si recibes concesión_inválida, el token de actualización ha expirado o ha sido revocado - solicita al usuario que se reautentique.gmail.lectura leer, gmail.enviar enviar, gmail.modificar para lectura/escritura/eliminación completa. Para Outlook: Mail.Read leer, Mail.Enviar enviar, Mail.ReadWrite para acceso completo - plus acceso_sin_conexión para obtener tokens de actualización. Siempre solicite el alcance mínimo que requiere su caso de uso. Ver Página de la API de correo electrónico para recomendaciones de alcance específicas del caso de uso.gmail.etiquetas (no sujeto a CASA), inicie el proceso de CASA antes de alcanzar los 50 usuarios (toma de 8 a 16 semanas), o utilice una API de correo electrónico OAuth alojada como Unipile, cuya infraestructura ya ha pasado la revisión de CASA, eliminando este requisito para su aplicación por completo./api/v1/hosted/accounts/link. Pasas a tipo (GOOGLE, MICROSOFT, o IMAP) y Unipile genera una URL de autenticación alojada. El usuario completa el consentimiento de OAuth en la infraestructura de Unipile, que ha pasado la verificación CASA de Google y la verificación de editor de Microsoft. Después del consentimiento, Unipile envía un webhook con account_id. Toda la gestión y actualización de tokens se maneja internamente.concesión_inválida. Tu API de correo de OAuth debe capturar esto, marcar la cuenta vinculada como desconectada y notificar al usuario con un enlace de reautenticación. Con Unipile, un webhook de revocación se dispara automáticamente para que tu sistema sea notificado en tiempo real, sin necesidad de sondeo.
ES 
EN 
FR 
DE 
IT 
BR 
NL 
PL 
TR