OAuth es bueno, pero Google y Microsoft lo convierten en una puerta de control

OAuth es una mejora de seguridad

Abandonar Basic Authentication, las contraseñas de larga duración y las credenciales con privilegios amplios fue la decisión correcta. OAuth permite permisos limitados, tokens de acceso breves, conexiones revocables y un mejor control de lo que una aplicación puede hacer realmente.

El estándar es abierto. Explica cómo una aplicación puede solicitar y obtener acceso en nombre de un usuario. Por sí mismo no exige que los desarrolladores presenten documentos empresariales, pruebas organizativas, vídeos de demostración o una solicitud de admisión al operador de una plataforma. Esa capa adicional procede de las reglas del ecosistema.

Un estándar abierto también puede convertirse en una puerta cerrada

SMTP e IMAP surgieron en una internet construida alrededor de la interoperabilidad. Un proveedor podía operar un servidor de correo, un desarrollador crear un cliente y ambos comunicarse mediante estándares documentados.

OAuth no destruye esa apertura. Pero cuando el acceso al buzón depende además de la aprobación del propietario de la plataforma, cambia la pregunta decisiva: ¿autoriza el usuario la aplicación o deciden Google o Microsoft si esa aplicación puede llegar a autorizarse?

Una revisión de seguridad pide a una aplicación demostrar que trata los datos del usuario de forma segura y limitada a su finalidad. El control de admisión exige en cambio reiteradamente a su editor justificar por qué puede existir la aplicación en el ecosistema. Este artículo sostiene que la distinción importa, sin dejar de reconocer la sensibilidad de los datos del buzón.

Microsoft 365: el consentimiento suele detenerse en el límite del tenant

La barrera de Microsoft descrita aquí no suele ser una revisión de vídeo al estilo de Google. Es la interacción entre Microsoft Entra ID, la verificación del editor, el consentimiento del administrador y las políticas de cada tenant de Microsoft 365.

Microsoft recomienda limitar el consentimiento del usuario a editores verificados y permisos seleccionados clasificados como de bajo riesgo. Los administradores pueden restringirlo más o desactivarlo. Un usuario puede querer expresamente una integración de buzón y aun así recibir el aviso de que se necesita aprobación del administrador.

La verificación del editor también puede ser decisiva en aplicaciones multiinquilino recientes. Entre otros requisitos, el editor necesita una cuenta verificada de Microsoft AI Cloud Partner Program vinculada al registro de la aplicación. Es una señal de confianza comprensible, pero también liga la posibilidad de utilizar la autorización abierta a los procedimientos comerciales y de socios de Microsoft.

Google y Gmail: revisar ámbitos puede convertirse en un cuello de botella del producto

El proceso de Gmail está más centralizado. Las clasificaciones de políticas descritas al publicarse identifican gmail.send como sensible y gmail.readonly como restringido. Las aplicaciones públicas que necesitan esos permisos pueden requerir pruebas de marca y dominio, una justificación precisa del ámbito y un vídeo de demostración, según su uso.

El vídeo debe mostrar todo el flujo OAuth, la pantalla exacta de consentimiento y las funciones que utilizan cada ámbito solicitado. Si se rechaza la justificación o, a juicio del revisor, la presentación no coincide con la aplicación, pueden seguir nuevas preguntas, grabaciones o presentaciones.

El artículo publicado cita estimaciones no vinculantes de Google de dos a tres días laborables para verificar la marca, diez días laborables para ámbitos sensibles y hasta seis semanas para ámbitos restringidos. Almacenar o transmitir datos restringidos de Gmail en un servidor puede exigir además una evaluación de seguridad repetida anualmente. Son descripciones de políticas y estimaciones asociadas a la publicación original, no una nueva promesa sobre el plazo de aprobación.

El límite de 100 usuarios tiene consecuencias prácticas

En modo de pruebas, el acceso se limita a un máximo de 100 usuarios de prueba indicados expresamente, cuyas autorizaciones caducan tras siete días en las condiciones descritas en la guía de Google enlazada. Las aplicaciones no verificadas también pueden encontrar un límite de 100 usuarios nuevos durante toda su vida.

Si se rechaza un ámbito sensible o restringido, los usuarios ya no pueden acceder a ese ámbito no aprobado. Por tanto, un límite o una denegación no es solo una advertencia administrativa: puede detener la función del producto que un usuario intenta habilitar.

Por qué Hassolux necesita estos permisos

Hassolux es una plataforma de trabajo para empresas de construcción y servicios que reúne proyectos, documentos, facturas y comunicación en un flujo trazable. Un usuario autorizado activa deliberadamente su conexión opcional al buzón.

En Microsoft 365, el acceso delegado Mail.Read y Mail.Send permite leer mensajes entrantes en nombre del usuario que ha iniciado sesión y enviar correos con documentos solicitados expresamente por él. En Gmail, gmail.readonly recupera mensajes seleccionados y adjuntos PDF/XML, mientras que gmail.send se utiliza por separado para el correo saliente iniciado por el usuario.

Hassolux busca solo en el período seleccionado por el usuario, lee remitente, asunto y hora de recepción e importa adjuntos PDF o XML compatibles para procesar facturas. No mueve, marca, modifica ni elimina mensajes de Gmail. El envío es independiente y solo ocurre tras una acción concreta del usuario. La conexión puede eliminarse y, además, revocarse en el proveedor.

Solicitar un ámbito menor puede resultar técnicamente contradictorio aquí. Un permiso limitado a metadatos no proporciona el contenido de los mensajes ni los adjuntos de facturas; la aplicación no puede importar un documento que no tiene permitido leer. Para esta función visible, se solicita gmail.readonly como el permiso más limitado de Google que proporciona el acceso necesario, no como recopilación preventiva de derechos más amplios.

Nuestra experiencia: demostraciones repetidas y, aun así, rechazo

En Hassolux, la verificación de Google implicó más que implementar la integración. Produjimos repetidamente vídeos de demostración, esperamos ciclos de revisión, respondimos correos de estado y explicamos por qué era necesario el ámbito. Rechazarlo elimina más que un permiso abstracto de API: elimina la función para la que un usuario quiere conectar su propio buzón.

Los datos sensibles del correo justifican requisitos de seguridad exigentes. Aun así, una revisión debe distinguir la recopilación excesiva de un permiso mínimo técnicamente necesario. De lo contrario, resulta imposible cumplir el principio de mínimo privilegio: la plataforma no ofrece un ámbito más limitado utilizable, pero rechaza el disponible por demasiado amplio. Este es el relato y el argumento del autor sobre su experiencia de revisión, no una afirmación de que todas las aplicaciones reciban el mismo trato.

Qué debería ofrecer un proceso de verificación justo

Las mejoras propuestas pretenden mantener la protección y, al mismo tiempo, hacer viables las integraciones independientes.

• Criterios claros comprobables de antemano: los desarrolladores deberían conocer los usos permitidos antes de implementar.
• Decisiones concretas y comprensibles: un rechazo debería identificar la discrepancia técnica o de privacidad específica.
• Pruebas proporcionadas: evaluar flujo de datos, ubicación de almacenamiento y riesgo real, en vez de principalmente el tamaño del editor.
• Revisiones reutilizables: un pequeño cambio del producto no debería reiniciar todo el proceso probatorio.
• Una apelación técnica significativa: contemplar los casos en que el proveedor no ofrece un ámbito funcional más limitado.
• Elección efectiva del usuario: el consentimiento informado y la revocación en cualquier momento deberían pesar más que los límites generales de la plataforma.

La autorización abierta debería seguir siendo abierta

Apoyamos OAuth, una autenticación más robusta y la protección coherente de los datos del usuario. Precisamente por eso debe ser posible criticar los mecanismos de aprobación construidos encima. La seguridad debe proteger a las personas de aplicaciones dañinas sin aumentar a la ligera las barreras de entrada ni reforzar el control de los propietarios de plataformas sobre el software interoperable.

Un estándar puede ser abierto sobre el papel. En la práctica, la apertura también exige que desarrolladores independientes, empresas emergentes y pequeñas empresas de software puedan utilizarlo en condiciones transparentes y justas. El futuro de internet no debería depender de que un puñado de plataformas concedan permiso para cada integración técnicamente necesaria.