Compartir a través de

Preguntas más frecuentes sobre la autenticación de aplicaciones anidadas y los tokens heredados de Outlook

  • Artículo

Los tokens de identidad de usuario de Exchange y los tokens de devolución de llamada están en desuso y se desactivarán a partir de febrero de 2025. Se recomienda mover complementos de Outlook que usan tokens de Exchange heredados a la autenticación de aplicaciones anidadas.

Preguntas más frecuentes generales

¿Qué es la autenticación de aplicaciones anidadas (NAA)?

La autenticación de aplicaciones anidadas permite el inicio de sesión único (SSO) para las aplicaciones anidadas dentro de aplicaciones compatibles de Microsoft, como Outlook. En comparación con los modelos de autenticación de plena confianza existentes y el flujo en nombre de, NAA proporciona una mejor seguridad y una mayor flexibilidad en la arquitectura de aplicaciones, lo que permite la creación de aplicaciones enriquecidas y controladas por el cliente. Para obtener más información, vea Habilitar el inicio de sesión único en un complemento de Office mediante la autenticación de aplicaciones anidadas.

¿Cuál es la escala de tiempo para apagar los tokens heredados de Exchange Online?

Microsoft comienza a desactivar los tokens en línea de Exchange heredados en febrero de 2025. Desde ahora hasta febrero de 2025, los inquilinos existentes y nuevos no se verán afectados. Proporcionaremos herramientas para que los administradores puedan volver a habilitar tokens de Exchange para inquilinos y complementos si esos complementos aún no se migran a NAA. Consulte ¿Puedo volver a activar los tokens heredados? para obtener más información.

Fecha Estado de tokens heredados
Febrero de 2025 Tokens heredados desactivados para todos los inquilinos. Los administradores pueden volver a habilitar tokens heredados a través de PowerShell.
Junio de 2025 Tokens heredados desactivados para todos los inquilinos. Los administradores ya no pueden volver a habilitar tokens heredados a través de PowerShell y deben ponerse en contacto con Microsoft para cualquier excepción.
Octubre de 2025 Tokens heredados desactivados para todos los inquilinos. Ya no se permiten excepciones.

¿Cuándo está disponible naa con carácter general para mi canal?

La fecha de disponibilidad general (GA) para NAA depende del canal que esté usando.

Fecha Disponibilidad general (GA) de NAA
Octubre de 2024 NAA es ga en el canal actual.
Noviembre de 2024 NAA tendrá disponibilidad general en el canal mensual de empresa.
Enero de 2025 NAA tendrá disponibilidad general en el canal de Semi-Annual.
Junio de 2025 NAA tendrá disponibilidad general en Semi-Annual canal extendido.

Preguntas sobre el administrador de Microsoft 365

¿Puedo volver a activar los tokens heredados?

A mediados de noviembre de 2024, implementaremos nuevas herramientas a través de PowerShell para que los administradores de Microsoft 365 activen o desactiven los tokens de Exchange heredados en el inquilino. Si tiene que volver a habilitar tokens de Exchange heredados, puede usar los cmdlets de PowerShell para hacerlo. Las herramientas también notificarán si algún complemento usa tokens heredados en los últimos 28 días. En junio de 2025, los tokens de Exchange Online heredados se desactivarán y no podrá volver a activarlos sin una excepción específica concedida por Microsoft. En octubre de 2025, no será posible activar tokens de Exchange Online heredados y se deshabilitarán para todos los inquilinos. Actualizaremos estas preguntas frecuentes con información adicional una vez que la herramienta esté disponible en todos los inquilinos.

Los proveedores de software independientes (ISV) están actualizando sus complementos para usar tokens de id. de entra y ámbitos de Microsoft Graph. Cuando el complemento solicita un token de acceso, debe tener el consentimiento del administrador o del usuario. Si el administrador da su consentimiento, todos los usuarios del inquilino pueden usar el complemento para los ámbitos que requiere el complemento. De lo contrario, se pedirá consentimiento a cada usuario final, si el consentimiento del usuario está habilitado. Completar el consentimiento del administrador proporciona una mejor experiencia porque no se solicita a los usuarios.

Una opción para el consentimiento es que el ISV le proporciona un URI de consentimiento del administrador.

  1. El desarrollador del complemento proporciona un URI de consentimiento del administrador. Si esto no está en la documentación que proporcionan, debe ponerse en contacto con ellos para obtener más información.
  2. El administrador busca el URI de consentimiento del administrador.
  3. Se pide al administrador que inicie sesión y dé su consentimiento a una lista de ámbitos que requiere el complemento.
  4. Una vez completado, el explorador redirige a una página web desde el ISV, que debe mostrar que el consentimiento se realizó correctamente.

Como alternativa, el ISV puede proporcionar un manifiesto de aplicación actualizado que solicitará el consentimiento del administrador como parte de la implementación central. En este escenario, al implementar el manifiesto de aplicación actualizado, se le pedirá que dé su consentimiento antes de que se pueda completar la implementación. No es necesario un URI de consentimiento del administrador.

Por último, si el complemento se publica en el almacén de Microsoft 365, la actualización se implementará automáticamente y se pedirá al administrador que dé su consentimiento a los ámbitos. Si el administrador no da su consentimiento, los usuarios no podrán usar el complemento actualizado.

Asegúrese de que no deshabilita las características ni revoca los permisos que requiere el complemento. Para obtener un ejemplo, consulte modificación de las propiedades de directiva de buzón de correo. El complemento usa permisos delegados y, por lo tanto, tiene acceso a los mismos recursos que el usuario que inició sesión. Sin embargo, si una directiva o configuración bloquea al usuario de un recurso o acción determinados, el complemento también se bloqueará.

Cómo implementar actualizaciones de complementos desde un ISV?

Si tiene un complemento que usa tokens de Exchange heredados, debe ponerse en contacto con el ISV para obtener información sobre su escala de tiempo para migrar su complemento para usar NAA. Una vez que el ISV migra su complemento, lo más probable es que proporcione una dirección URL de consentimiento del administrador. Para obtener más información, vea ¿Cómo funciona el flujo de consentimiento del administrador? .

El ISV también puede proporcionarle un manifiesto de aplicación actualizado para implementarlo mediante la implementación centralizada. Durante la implementación centralizada, esto puede pedirle que dé su consentimiento a cualquier ámbito de Microsoft Graph que requiera el complemento. En este escenario, no tendrá que usar un URI de consentimiento del administrador.

Si el complemento se implementa desde Microsoft AppSource, lo más probable es que se le pida que dé su consentimiento a los ámbitos de Microsoft Graph cuando el ISV implemente actualizaciones en el complemento. Hasta que no dé su consentimiento, los usuarios del inquilino no podrán usar la nueva versión del complemento con NAA.

¿Qué complementos de mi organización se ven afectados?

Proporcionaremos herramientas para los administradores que notifican el identificador de aplicación de cualquier complemento que haya usado tokens heredados de Exchange Online en los últimos 28 días. Proporcionaremos más información en estas preguntas más frecuentes cuando las herramientas estén listas. Para obtener más información, consulte ¿Puedo volver a activar los tokens heredados?.

Los complementos pueden usar los tokens de Exchange heredados para obtener recursos de Exchange a través de las API REST de EWS o Outlook. A veces, un complemento requiere recursos de Exchange para algunos casos de uso y no para otros, lo que dificulta averiguar si el complemento requiere una actualización. Se recomienda ponerse en contacto con los desarrolladores y propietarios de complementos para preguntarles si su código de complemento hace referencia a las siguientes API.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si confía en un ISV para el complemento, le recomendamos que se ponga en contacto con ellos lo antes posible para confirmar que tienen un plan y una escala de tiempo para salir de los tokens de Exchange heredados. Los desarrolladores de ISV deben ponerse en contacto directamente con sus contactos de Microsoft con preguntas para asegurarse de que están listos para el final de los tokens heredados de Exchange. Si confía en un desarrollador de su organización, deben revisar estas preguntas más frecuentes y el artículo Habilitación del inicio de sesión único en un complemento de Office mediante la autenticación anidada de aplicaciones. Cualquier pregunta debe plantearse en el sitio de problemas de GitHub OfficeDev/office-js.

Una vez que el administrador o un usuario dan su consentimiento, se mostrará en el Centro de administración Microsoft Entra. Puede encontrar registros de aplicaciones mediante los pasos siguientes.

  1. Ve a https://entra.microsoft.com/#home.
  2. En el panel de navegación izquierdo, seleccione Aplicaciones>Registros de aplicaciones.
  3. En la página Registros de aplicaciones, seleccione Todas las aplicaciones.
  4. Ahora puede buscar cualquier registro de aplicación por nombre o identificador.

Preguntas más frecuentes sobre la migración de complementos de Outlook

¿Por qué Microsoft realiza la migración de complementos de Outlook?

Cambiar a Microsoft Graph mediante tokens de id. de Entra es una gran mejora en la seguridad para los clientes de Outlook y Exchange. Entra ID (anteriormente Azure Active Directory) es un servicio líder de administración de identidades y acceso basado en la nube. Los clientes pueden aprovechar las características de confianza cero, como el acceso condicional, los requisitos de MFA, la supervisión continua de tokens, la heurística de seguridad en tiempo real y mucho más que no están disponibles con tokens de Exchange heredados. Los clientes almacenan datos empresariales importantes almacenados en Exchange, por lo que es fundamental que nos aseguremos de que estos datos están protegidos. La migración de todo el ecosistema de Outlook para usar tokens de id. de Entra con Microsoft Graph mejora considerablemente la seguridad de los datos de los clientes.

¿Mi complemento de Outlook tiene que migrar a NAA?

No. Los complementos de Outlook no tienen que usar NAA, aunque NAA ofrece la mejor experiencia de autenticación para los usuarios y la mejor posición de seguridad para las organizaciones. Si los complementos no usan tokens de Exchange heredados, no se verán afectados por el desuso de los tokens de Exchange. Los complementos que usan MSAL.js u otros métodos de SSO que dependen de Entra ID seguirán funcionando.

Cómo saber si mi complemento de Outlook se basa en tokens heredados?

Proporcionaremos herramientas para los administradores que notifican el identificador de aplicación de cualquier complemento que haya usado tokens heredados de Exchange Online en los últimos 28 días. Proporcionaremos más información cuando las herramientas estén listas en estas preguntas más frecuentes. Consulte ¿Puedo volver a activar los tokens heredados? para obtener más información.

Para averiguar si el complemento usa tokens de identidad de usuario y tokens de devolución de llamada heredados de Exchange, busque en el código las llamadas a las siguientes API.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si el complemento llama a cualquiera de estas API, debe adoptar NAA y migrar a mediante tokens de id. de entra para acceder a Microsoft Graph en su lugar.

¿Qué complementos de Outlook están en el ámbito?

Muchos complementos principales están en el ámbito. Si el complemento usa EWS o REST de Outlook para acceder a Exchange Online recursos, es casi seguro que necesita migrar de tokens heredados de Outlook a NAA. Si el complemento es solo para Exchange local (por ejemplo, Exchange 2019), no se ve afectado por este cambio.

¿Qué pasará con mis complementos de Outlook si no migre a NAA?

Si no migra los complementos de Outlook a NAA, dejarán de funcionar según lo esperado en Exchange Online. Cuando se desactivan los tokens de Exchange, Exchange Online bloqueará la emisión de tokens heredados. Cualquier complemento que use tokens heredados no podrá acceder a los recursos de Exchange Online.

Si el complemento solo funciona de forma local o si el complemento está en una ruta de desuso, es posible que no tenga que actualizarlo. Sin embargo, la mayoría de los complementos que acceden a recursos de Exchange a través de EWS o REST de Outlook deben migrar para seguir funcionando según lo previsto.

Cómo migrar mis complementos de Outlook a NAA?

Para admitir NAA en el complemento de Outlook, consulte la siguiente documentación y ejemplo.

Cómo mantenerse al día con las instrucciones más recientes?

Actualizaremos estas preguntas más frecuentes a medida que haya información nueva disponible. Compartiremos instrucciones adicionales para avanzar en la llamada a la comunidad de complementos de Office y en el blog para desarrolladores de M365. Por último, puede formular preguntas sobre NAA y la desuso de tokens Exchange Online heredados en el sitio de problemas de GitHub OfficeDev/office-js. Coloque "NAA" en el título para que podamos agrupar y priorizar los problemas.

Si envía un problema, incluya la siguiente información.

  • Versión de cliente de Outlook.
  • Audiencia del canal de versión de Outlook (para el cliente).
  • Captura de pantalla del problema.
  • La plataforma donde se produce el problema (Windows, Outlook (nuevo), Mac, iOS, Android).
  • Id. de sesión donde se encuentra el problema.
  • Tipo de cuenta que se usa.
  • Versión de msal-browser.
  • Registros de msal-browser.

Preguntas para la solución de problemas de desarrolladores

NAA no proporciona el inicio de sesión único y sigue solicitando a los usuarios que inicien sesión

Esto puede ocurrir cuando NAA no está disponible en el cliente de Outlook. Si está en Windows, compruebe que usa el canal beta o el canal actual (versión preliminar). Debe unirse al Programa Insider de Microsoft 365 para cambiar a estos canales. Una buena manera de comprobar si NAA está disponible es comprobar el conjunto de requisitos mediante el siguiente fragmento de código. Office.context.requirements.isSetSupported("NestedAppAuth")

Cómo obtener más información de depuración de MSAL y NAA?

Use el código siguiente para habilitar la información de depuración en msalConfig al inicializar la aplicación cliente pública anidable. Esto registrará detalles adicionales en la consola.

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

Contenido relacionado