Estoy creando una aplicación que se ejecutará como un servicio automatizado sin interacción del usuario para procesar para conectarse a un buzón y procesar correos electrónicos (descargar archivos adjuntos, mover correos electrónicos a una carpeta "procesada", etc.). Al leer sobre las opciones de autenticación de los servicios web de Exchange (EWS), veo que es compatible con oAuth y Basic Auth. (consulte Autenticación de EWS) . Las ventajas enumeradas para oAuth son que solo corre el riesgo de exponer un token de autenticación temporal para el usuario, y no las credenciales del usuario. Sin embargo, AFAIK solo se aplica a las aplicaciones que involucran la interacción del usuario, ya que para conectarse utilizando oAuth desde una cuenta de servicio sin ninguna interacción del usuario, deberá usar las credenciales de la aplicación (y esas credenciales de la aplicación deben almacenarse en la configuración de la aplicación o en otro lugar), y luego tiene que dar a la aplicación acceso completo a la cuenta de correo electrónico de cada usuario a través de los permisos de registro de la aplicación de Azure AD o, de lo contrario, requeriría la interacción del usuario durante el proceso de inicio de sesión de oAuth. La sección de autenticación básica del artículo hace que parezca que esto solo se usaría para fines de demostración y no en escenarios de producción.
Si tuviera que usar oAuth, entonces tendría que usar el tipo de concesión de credenciales de cliente de OAuth 2.0 que se menciona aquí: Daemon Auth .
Para el escenario en el que una aplicación daemon necesita llamar a una API web, Es importante entender algunas cosas. Primero, la interacción del usuario es no es posible con una aplicación daemon, que requiere la aplicación Tener identidad propia. Un ejemplo de una aplicación daemon es un trabajo por lotes, o un servicio de sistema operativo que se ejecuta en segundo plano. Este tipo de aplicación solicita un token de acceso utilizando su Identidad de la aplicación y presentando su ID de solicitud, credencial. (contraseña o certificado), e ID de aplicación URI para Azure AD. Después autenticación exitosa, el demonio recibe un token de acceso de Azure AD, que luego se usa para llamar a la API web.
En este caso, ¿no es la Autenticación básica una mejor opción, con una cuenta de servicio dedicada para un buzón, donde esa cuenta solo se usa para este buzón? Esto parece mucho más seguro que usar la ruta de autenticación de oAuth, porque si las credenciales están comprometidas, entonces el atacante solo tiene acceso a un único buzón de cuenta de servicio, y no al correo electrónico de toda la compañía a través del ID de la aplicación y el secreto de la aplicación.
¿Me estoy perdiendo algo?