Consentimiento de usuarios y de administrador

Según la documentación de Microsoft, los permisos de aplicación y muchos permisos delegados de alto privilegio solo pueden ser consentidos por un administrador. Un usuario puede consentir lo que afecta a sus propios datos, como que una aplicación lea su buzón, pero no lo que afecta a toda la organización. Esa división es la primera barrera: el usuario decide por sí mismo, el administrador decide por todos.

El problema no es que el usuario pueda consentir, sino lo que se le deja consentir y a quién.

El registro trae, en cada consentimiento, el estado del publicador y los permisos aceptados. Un publicador verificado es uno cuya identidad confirmó el proveedor de la plataforma; no garantiza que la aplicación sea buena, pero un publicador sin verificar es una señal que merece más atención cuando pide acceso al correo.

Saber quién consintió permite hablar con la persona, entender por qué lo hizo y revisar qué otros permisos aceptó. No es para culpar: el usuario hizo lo que la política le dejaba hacer, y la corrección es de la política.

La política tiene activo el flujo de solicitud al administrador: cuando un usuario no puede consentir, pide la aprobación. Un flujo que nadie atiende empuja a los usuarios a buscar atajos, y por eso la espera es un indicador. Cuenta desde la fecha de la solicitud hasta la fecha de la exportación.

Microsoft describe, entre las opciones de consentimiento de usuarios, limitarlo a aplicaciones de publicadores verificados y a permisos que la organización clasificó como de bajo impacto. Lo que queda fuera pasa al flujo de solicitud al administrador. Cambiar la política solo afecta a consentimientos futuros: los ya concedidos se revisan y se revocan aparte.