Gmail App Passwords, IMAP and the API: Three Ways In, and When Each Works
La mayoría de los problemas de conexión con Gmail terminan en el mismo punto: necesitas una contraseña de aplicación, y no puedes crearla hasta que actives la verificación en dos pasos. Aquí es donde encaja entre las tres formas en que un script o cliente puede acceder realmente a un buzón.
Avery Bennett
El problema más común con Gmail no es un problema de Gmail. A un cliente o script se le da la contraseña de la cuenta, la conexión se rechaza y la conclusión obvia es que la contraseña es incorrecta. No lo es. Google dejó de aceptar contraseñas de cuenta desde clientes de correo, y lo que quiere en su lugar es una contraseña de aplicación.
Contraseñas de aplicación y el requisito previo que nadie menciona
Una contraseña de aplicación es una credencial separada, generada dentro de la cuenta, que un solo cliente usa en lugar de la contraseña de inicio de sesión. Tres cosas sobre ella explican casi todas las búsquedas de "no funciona":
- No puedes crear una hasta que la verificación en dos pasos esté activada. Esta es la respuesta a la mayoría de ellas. La opción de generar una contraseña de aplicación simplemente no aparece en una cuenta sin un segundo factor, así que la gente busca una página que aún no existe. Activa la verificación en dos pasos primero y la opción aparecerá.
- Solo se muestra una vez. Se genera, se muestra y no se puede recuperar después. Perderla significa generar otra, no buscarla.
- Se muestra con espacios y se ingresa sin ellos. Dieciséis caracteres en cuatro grupos. Algunos clientes manejan los espacios y otros no, y esto por sí solo explica una buena parte de los fallos con una contraseña que por lo demás es correcta.
Se generan en la sección de seguridad de la cuenta de Google, no dentro de la configuración de Gmail, que es la otra razón por la que la gente no encuentra la página.
Si compraste una cuenta y el anuncio menciona una contraseña de aplicación, esa cadena es lo que va en el cliente. La contraseña de inicio de sesión de la cuenta no funcionará allí, e intentarlo repetidamente es cómo atraes verificaciones adicionales que no querías.
Las tres vías de acceso
Inicio de sesión web
Un navegador, una contraseña, un segundo factor si está configurado. Bien para una persona, mal para un script. El inicio de sesión automatizado a través del flujo web se topa con desafíos, avisos de dispositivo desconocido y a veces verificación por teléfono, porque ese flujo está vigilado precisamente para detectar este patrón. Cuando un script "no puede iniciar sesión" pero las credenciales son correctas, este desajuste suele ser el motivo.
IMAP y SMTP
Los protocolos de correo, hablados por todos los clientes de correo y todas las librerías de correo. Necesita la contraseña de aplicación descrita arriba. Es lo mejor para leer una bandeja de entrada, esperar un mensaje o enviar, sin construir nada.
Ajustes prácticos: IMAP en el puerto 993 con SSL, SMTP en el 587 con STARTTLS, y la dirección completa como nombre de usuario. Ten en cuenta que el acceso IMAP puede estar desactivado por defecto en algunas cuentas y se habilita en la configuración de Gmail, que es un interruptor distinto de la contraseña de aplicación y vale la pena revisarlo cuando la credencial es definitivamente correcta.
La API de Gmail
Una interfaz programática adecuada a través de OAuth2. Registras un proyecto, configuras un cliente OAuth, completas un flujo de consentimiento una vez y recibes tokens que tu programa usa a partir de entonces.
Dos ventajas reales sobre IMAP: los permisos están delimitados, así que un programa puede tener acceso de solo lectura en lugar de control total, y recibes datos de mensajes estructurados en lugar de analizar correo en bruto. Dos costos reales: la configuración es genuinamente más trabajo, y las pantallas de consentimiento tienen sus propias reglas de revisión según lo que pidas.
Úsala para algo que estés construyendo y manteniendo. Para leer un código de una bandeja de entrada, IMAP es la respuesta proporcionada.
Cómo elegir, en una línea cada uno
- Una persona revisando el correo: la web, o cualquier cliente vía IMAP.
- Un script leyendo mensajes: IMAP con una contraseña de aplicación. Menos configuración, funciona en todas partes.
- Software que estás construyendo: la API, por permisos delimitados y datos estructurados.
- Un script manejando la interfaz web: evítalo. La fricción que encuentras es deliberada y no desaparecerá.
Qué significa esto al comprar un buzón
Dos campos en un anuncio se corresponden con lo anterior, y no son lo mismo.
Una contraseña de aplicación incluida significa que el trabajo de verificación en dos pasos y generación ya está hecho y puedes conectar un cliente de inmediato. Una entrega con OAuth2 es la ruta de la API, y allí lo que importa es la completitud: un token de actualización sin el ID de cliente y el secreto contra los que se emitió funcionará hasta que el token de acceso actual expire y luego se detendrá permanentemente. Ese fallo llega mucho después de que cualquier ventana de garantía se cierre, así que la comprobación no es "¿conecta ahora?" sino "¿puedo completar una renovación?".
Vale la pena saber sobre el precio: en todo el catálogo de correo, el acceso por protocolo es uno de los atributos más baratos medidos, mientras que los atributos de verificación como la verificación en dos pasos y la verificación por SMS son los más caros, aproximadamente tres veces el precio medio y cerca de tres veces respectivamente. El acceso es barato; estar verificado no lo es.
Los anuncios de Gmail, con las etiquetas de contraseña de aplicación y OAuth2 filtrables, están en el estante de Gmail.
