On 2022-05-19 at 20:38 +0200, Camaleón wrote: > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes.
No es una ventaja para los clientes de correo ni está diseñado como tal. Ellos funcionarían mejor simplemente con una contraseña. Para los usuarios, es una cuestión de que el cliente de correo de su elección soporte este sistema. > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso > o derivarnos al webmail :-/ El problema de fondo es que la gente utiliza contraseñas inseguras. Si tu contraseña es «Camaleon1» el servidor de Gmail no podrá hacer demasiado para proteger tu cuenta (y seguro que tienen clientes con contraseña aún más ridículas y que se negarán a cambiarlas, pero que les cuplarían si les entran en la cuenta). Lo que consiguen con OAuth es dirigir al usuario al navegador, donde tienen mucha más libertad: le pueden pedir un segundo factor (si lo tiene configurado), reenviarlo a un servidor SSO, pedirle una pregunta de seguridad, hacerle resolver un captcha, etc. Una vez dado de alta (a través de ese acceso por la web) el cliente de correo, este se conectará haciendo uso del token que le ha devuelto para cuando necesite acceder. Un saludo
