Compartir a través de

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

Los tokens de identidad de usuario de Exchange y los tokens de devolución de llamada están en desuso y se desactivarán por completo en junio 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?

Los tokens de Exchange Online heredados ya se han desactivado para la mayoría de los inquilinos. Hemos proporcionado 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. Para obtener más información, consulte ¿Puedo volver a activar los tokens heredados?.

Fecha Estado de tokens heredados
Now Los tokens heredados están desactivados para la mayoría de los inquilinos. Los administradores pueden volver a habilitar tokens heredados a través de PowerShell.
16 de junio de 2025 - julio de 2025 Los tokens heredados están desactivados para todos los inquilinos. Este proceso tardará varias semanas en completarse. Los administradores ya no pueden volver a habilitar tokens heredados a través de PowerShell. Los administradores pueden solicitar una excepción a través de Soporte técnico de Microsoft en https://aka.ms/LegacyTokensByOctober (este vínculo requiere que inicie sesión en el inquilino).
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 es disponibilidad general en el canal mensual de empresa.
Enero de 2025 NAA es GA en Semi-Annual channel build 16.0.17928.20392.
Junio de 2025 NAA tendrá disponibilidad general en Semi-Annual canal extendido.

Cómo controlar los tokens heredados desactivados en Semi-Annual canal extendido, ¿qué aún no admite NAA?

Semi-Annual canal extendido no admitirá NAA hasta junio de 2025. Esto significa que incluso si los complementos se actualizan para admitir NAA y ya no usan tokens de Exchange Online heredados, no funcionarán en este canal. Si usa Semi-Annual canal extendido como administrador, se recomienda lo siguiente.

¿Los complementos COM se ven afectados por el desuso de tokens de Exchange Online heredados?

Es muy poco probable que los complementos COM se vean afectados por el desuso de los tokens de Exchange Online heredados. Los complementos web de Outlook se ven afectados principalmente porque pueden usar Office.js API que se basan en tokens de Exchange. Para obtener más información, vea How do i know if my outlook add in se basa en tokens heredados. Los tokens de Exchange se usan para acceder a los servicios web de Exchange (EWS) o a las API REST de Outlook, que también están en desuso. Si sospecha que un complemento COM podría verse afectado, puede probarlo mediante su uso en un inquilino con tokens de Exchange desactivados. Para obtener más información, vea Activar o desactivar tokens de Exchange Online heredados.

Preguntas sobre el administrador de Microsoft 365

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

Use el Get-AuthenticationPolicy comando para obtener una lista de todos los complementos de Outlook que usan tokens de Exchange Online heredados en el inquilino. Para obtener más información, vea Activar o desactivar tokens de Exchange Online heredados. Una vez que tenga la lista de complementos, deberá ponerse en contacto con los publicadores para obtener más información sobre sus planes de actualización. En algunos casos, su propia organización puede desarrollar el complemento. Tendrá que ponerse en contacto con el equipo de desarrollo adecuado de su organización.

¿Qué comandos puedo usar para identificar al publicador?

Hay algunos Exchange Online comandos de PowerShell que puede usar para realizar un seguimiento de información adicional sobre los complementos de Outlook.

Para buscar una lista de complementos instalados en el equipo de un usuario, el usuario puede ejecutar el siguiente comando.

Get-App | Select-Object -Property ProviderName, DisplayName, AppId

En la captura de pantalla siguiente se muestra un ejemplo de ejecución del Get-App comando.

Captura de pantalla de la ejecución del comando Get-App en PowerShell con los resultados de Los sondeos de Microsoft y Envío de Microsoft a OneNote.

ProviderName le ayudará a identificar quién publicó el complemento para que pueda ponerse en contacto con ellos. El AppId se puede usar para obtener detalles adicionales sobre el complemento.

Nota:

El Get-App comando no muestra una lista completa de todos los complementos instalados en el equipo del usuario. Por ejemplo, los complementos descargados localmente no aparecerán en esta lista. Es posible que tenga que realizar un seguimiento con los usuarios en algunos casos para realizar un seguimiento de dónde procede el complemento.

Para encontrar información sobre un complemento, AppId use el siguiente comando.

Get-App -Identity {identity} | Select-Object -Property ProviderName, DisplayName

En la captura de pantalla siguiente se muestra un ejemplo de uso del identificador de Mapas de Bing para obtener más información.

Captura de pantalla de la ejecución del comando Get-App en PowerShell para obtener ProviderName y DisplayName para Mapas de Bing.

También puede encontrar información adicional en el archivo de manifiesto del complemento. El manifiesto contiene puntos de conexión de dirección URL que también pueden ayudarle a identificar y ponerse en contacto con el publicador. Use el siguiente comando para obtener el manifiesto.

Get-App -Identity {identity} | Select-Object -Property ManifestXml

En la captura de pantalla siguiente se muestra un ejemplo de uso del identificador para obtener el manifiesto XML para Mapas de Bing.

Captura de pantalla de la ejecución del comando Get-App en PowerShell para obtener el ManifestXml de Mapas de Bing

Nota:

Los complementos de Outlook que implementó desde Microsoft AppSource se pueden identificar mediante una lista que publicamos. No es necesario realizar ninguna prueba. Para obtener más información, consulte Cómo identificar complementos publicados en Microsoft AppSource.

Cómo identificar complementos publicados en Microsoft AppSource

Hemos publicado una lista de todos los complementos de Outlook publicados en Microsoft AppSource que usan tokens heredados a partir de abril de 2025. Para obtener más información sobre cómo usar la lista y crear un informe de complementos de Outlook que potencialmente usan tokens heredados, vea Buscar complementos de Outlook que usan tokens de Exchange Online heredados.

¿Cómo sabrán los ISV que su complemento usa tokens heredados?

Los complementos pueden usar los tokens 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.

¿Qué hago para los complementos que no puedo identificar?

Después de ejecutar Get-AuthenticationPolicy , es posible que haya algunos complementos personalizados que no pueda identificar al propietario. Para esos complementos, es posible que tenga que realizar una prueba de gritos. Se recomienda que los administradores realicen una prueba de grito antes de junio de 2025 para determinar si hay algún complemento restante que se interrumpirá cuando los tokens heredados se desactiven en junio. Esto le dará tiempo para ponerse en contacto con los editores de los complementos afectados para abordar problemas importantes antes de la fecha límite de junio.

Nota:

Solo tiene que realizar la prueba de grito si ha activado tokens de Exchange Online heredados mediante el Set-AuthenticationPolicy comando . Si no ha ejecutado este comando, Exchange Online tokens ya deberían estar desactivados de forma predeterminada.

Antes de realizar la prueba de gritos, es posible que quiera informar a los usuarios de antemano, por ejemplo, a través del correo electrónico, de que habrá una prueba para desactivar los tokens heredados y que puede afectar a algunos complementos de Outlook. Considere la posibilidad de proporcionar a los usuarios la siguiente información.

  • Período de tiempo esperado de la prueba.
  • Si hay complementos conocidos de Outlook que se interrumpirán, como complementos implementados desde Microsoft AppSource que ya haya identificado.
  • En general, los complementos de Outlook no deben interrumpirse. Sin embargo, si ven problemas, pida a los usuarios que notifiquen el nombre y la descripción del complemento, junto con cualquier información de error observada.

Siga estos pasos para realizar la prueba.

  1. Ejecute el siguiente comando para desactivar los tokens de Exchange Online heredados en el inquilino. Para obtener más información sobre cómo usar este comando, consulte Activar o desactivar tokens de Exchange Online heredados.

    Set-AuthenticationPolicy -BlockLegacyExchangeTokens -Identity "LegacyExchangeTokens"

  2. Espere una cantidad adecuada de tiempo para que los usuarios notifiquen cualquier problema con los complementos. El comando tarda aproximadamente 24 horas en desactivar los tokens de Exchange Online heredados para todos los usuarios. Los usuarios pueden tardar otro día o dos en notificar cualquier problema con los complementos de Outlook.

  3. Identifique los complementos de Outlook afectados. Si los usuarios envían problemas que identifican problemas importantes, asegúrese de obtener el nombre y la descripción del complemento de Outlook afectado. Capture también el error o el comportamiento para que esta información se pueda pasar al publicador.

  4. Si se interrumpen los complementos críticos para la empresa, vuelva a activar los tokens mediante el siguiente comando. Para obtener más información sobre cómo usar este comando, consulte Activar o desactivar tokens de Exchange Online heredados.

    Set-AuthenticationPolicy -AllowLegacyExchangeTokens -Identity "LegacyExchangeTokens"

    Los tokens tardan aproximadamente 24 horas en activarse para todos los usuarios del inquilino.

  5. Si no hay informes de problemas importantes, se recomienda dejar los tokens de Exchange Online heredados como procedimiento recomendado de seguridad.

¿Puedo volver a activar Exchange Online tokens heredados?

Sí, hay comandos de PowerShell que puede usar para activar o desactivar tokens heredados en cualquier inquilino. Para obtener más información sobre cómo activar o desactivar tokens heredados, consulte Activar o desactivar tokens de Exchange Online heredados.

En junio de 2025, los tokens heredados se desactivarán y no podrá volver a activarlos. Los administradores pueden solicitar una excepción a través de Soporte técnico de Microsoft en https://aka.ms/LegacyTokensByOctober (este vínculo requiere que inicie sesión en el inquilino). En octubre de 2025, no será posible activar los tokens heredados y se deshabilitarán para todos los inquilinos.

Los proveedores de software independientes (ISV) están actualizando sus complementos para usar tokens de Entra ID 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. Para una mejor experiencia porque no se solicita a los usuarios, complete el consentimiento del administrador.

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.

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. Vaya a https://entra.microsoft.com/#home e inicie sesión como administrador en el inquilino.
  2. En el panel de navegación izquierdo, seleccione Aplicaciones>empresariales aplicaciones.
  3. En la página Aplicaciones empresariales , en la sección Administrar , seleccione Todas las aplicaciones.
  4. Seleccione el complemento. Se abrirá una página de información general. En la página de información general, seleccione Permisos. Hay dos vistas para los permisos; Administración consentimiento y consentimiento del usuario. Seleccione Consentimiento del usuario para ver los consentimientos individuales.

¿Hay una lista de publicadores que han actualizado sus complementos?

Algunos editores de complementos de Outlook ampliamente usados ya han actualizado sus complementos como se muestra a continuación.

Si el publicador actualizó su manifiesto y el complemento se implementa a través de Microsoft Store, se le pedirá como administrador que actualice e implemente las actualizaciones. Si el publicador actualizó su manifiesto y el complemento se implementa a través de la implementación central, deberá implementar el nuevo manifiesto como administrador. En algunos casos, el publicador puede tener un URI de consentimiento de administrador que debe usar para dar su consentimiento a nuevos ámbitos para el complemento. Póngase en contacto con los publicadores si necesita más información sobre cómo actualizar un complemento.

Algunos complementos se están rompiendo. ¿Puedo saber si esto se debe a que los tokens de Exchange se desactivaron?

Si observa que un complemento tiene problemas y sospecha que puede verse afectado por tokens de Exchange desactivados, realice las siguientes acciones.

Comprobación de la lista de complementos conocidos

Hemos publicado una lista de complementos que se sabía que usaban tokens de Exchange heredados a partir de octubre de 2024. Si un complemento está en esta lista, debe ponerse en contacto con el publicador para ver si hay actualizaciones disponibles. Para obtener más información, vea Buscar complementos de Outlook que usan tokens de Exchange Online heredados.

Compruebe si los tokens están desactivados mediante Script Lab

Compruebe si los tokens de Exchange Online heredados están desactivados para un usuario mediante el complemento de Script Lab.

  1. Instale Script Lab para Outlook.

  2. Inicie sesión en Outlook con la cuenta de usuario o buzón de correo que se ve afectado. Los tokens de Exchange pueden estar desactivados para un usuario, pero no para otro hasta que se complete el lanzamiento.

  3. En un correo electrónico nuevo o existente, abra Script Lab en el menú Aplicaciones y elija Código en el menú Script Lab.

    Captura de pantalla del menú Script Lab.

  4. En el panel de tareas Script Lab, seleccione el icono backstage (tiene tres líneas).

    Captura de pantalla del icono de backstage.

  5. Seleccione Ejemplos y busque el ejemplo Obtener un token de identidad de usuario . Seleccione este ejemplo para abrirlo en el editor de código.

    Captura de pantalla del menú de Script Lab y el cuadro de búsqueda para buscar el ejemplo obtener un token de identidad de usuario.

  6. Una vez cargado el código del ejemplo, seleccione Ejecutar ejecución>en este panel.

    Captura de pantalla de la opción de menú Ejecutar en Script Lab.

  7. Una vez que se ejecute el código, seleccione Obtener token.

Si los tokens de Exchange Online heredados están activados, verá un token mostrado en la consola como una cadena codificada en Base64.

Captura de pantalla de un token que se muestra en la ventana de la consola.

Si los tokens de Exchange Online heredados están desactivados, verá un error en la consola como se muestra a continuación.

Captura de pantalla de un error en la ventana de la consola.

El código y el error reales pueden variar, pero a menudo verá el código de error 9017 o 9018 junto con las descripciones de error siguientes.

  • GenericTokenError: An internal error has occurred.
  • InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Si un complemento se ve afectado por los tokens de Exchange desactivados, puede volver a activarlos. Para obtener más información, consulte ¿Puedo volver a activar Exchange Online tokens heredados?.

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 Entra ID 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 Entra ID 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?

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 Entra ID 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. Cuando el complemento llama a una API que solicita un token de Exchange, como getUserIdentityTokenAsync, obtiene un error genérico similar al siguiente con códigos de error como 9017 o 9018.

  • "GenericTokenError: se ha producido un error interno".
  • "InternalServerError: el servidor exchange devolvió un error. Consulte el objeto de diagnóstico para obtener más información."

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 desarrolladores

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;
        }
      },
    }
  }
};

Prueba del complemento actualizado

Una vez que haya actualizado el complemento para usar NAA, debe probarlo en todas las plataformas que admita, como Mac, móvil, web y Outlook en Windows.

Prueba cuando los tokens de Exchange están desactivados

Para probar que el complemento funciona correctamente cuando los tokens de Exchange están desactivados, implemente el complemento en un inquilino con tokens desactivados y pruébelo. Para desactivar los tokens, consulte Activar o desactivar tokens de Exchange Online heredados.

Si ha implementado un patrón en el que el código usa tokens de Exchange pero, a continuación, se cae si no están disponibles, asegúrese de comprobar los errores correctos. Cuando se produce un error en una llamada para obtener un token de Exchange, compruebe asyncResult.diagnostics. Si se devuelve cualquiera de los siguientes errores, cambie a NAA.

  • GenericTokenError: An internal error has occurred.
  • InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Prueba del código de reserva para la vista web trident+

Si el complemento de Outlook admite Outlook 2016 o Outlook 2019 en Windows, compruebe que funciona correctamente cuando se usa la vista web Trident+ (Internet Explorer 11). Cuando se usa la vista web trident+, el código debe volver a MSAL v2 para abrir un cuadro de diálogo e iniciar sesión en el usuario. Para obtener más información sobre cómo implementar el patrón de reserva, vea Complemento de Outlook con SSO mediante la autenticación de aplicaciones anidadas, incluida la reserva de Internet Explorer.

Nota:

La compatibilidad con Outlook 2016 y Outlook 2019 finaliza en octubre de 2025. Para obtener más información, vea Fin del soporte técnico para Office 2016 y Office 2019.

Pruebas en Trident+ y WebView2

Outlook 2016 y Outlook 2019 en Windows usan Trident+ o WebView2 en función de varias condiciones del sistema operativo.

Nota:

La compatibilidad con Outlook 2016 y Outlook 2019 finaliza en octubre de 2025. Para obtener más información, vea Fin del soporte técnico para Office 2016 y Office 2019.

¿Qué tokens devuelve MSAL y hay ámbitos mínimos para solicitar?

Cuando se solicita un token a través de MSAL, siempre devuelve tres tokens.

Token Objetivo Scopes AuthencationResult propiedad
Token de identificador Proporciona información sobre el usuario al cliente (panel de tareas). profile y openid authResult.idToken
Token de actualización Actualiza el identificador y los tokens de acceso cuando expiran. offline_access No disponible.
Token de acceso Autentica al usuario para ámbitos específicos en un recurso, como Microsoft Graph. Cualquier ámbito de recursos, como user.read. authResult.accessToken

MSAL siempre devuelve estos tres tokens. Solicita , profileopenidy offline_access como ámbitos predeterminados, incluso si la solicitud de token no los incluye. Esto garantiza que se soliciten los tokens de id. y actualización. Sin embargo, debe incluir al menos un ámbito de recurso, como user.read para obtener un token de acceso. Si no es así, la solicitud puede producir un error.

¿Debo validar el token de identificador de MSAL?

No. Se trata de un patrón de autenticación heredado que se usó con tokens de Exchange para autorizar el acceso a sus propios recursos. Pasar el token de identificador a través de una llamada de red para habilitar o autorizar el acceso a un servicio es un anti-patrón de seguridad. El token de identificador solo está pensado para el cliente (panel de tareas) y no hay ninguna manera de que el servicio use el token de forma confiable para asegurarse de que el usuario tiene acceso autorizado. Para obtener más información sobre las notificaciones de token de identificador, consulte Referencia de notificaciones de token de identificador.

Es muy importante que siempre solicite un token de acceso a sus propios servicios. El token de acceso también incluye las mismas notificaciones de identificador, por lo que no es necesario pasar el token de identificador. En su lugar, cree un ámbito personalizado para el servicio. Para obtener más información sobre la configuración de registro de aplicaciones para sus propios servicios, consulte API web protegida: Registro de aplicaciones. Cuando el servicio recibe el token de acceso, puede validarlo y usar notificaciones de identificador desde dentro del token de acceso.

¿Por qué recibo errores de las directivas de acceso condicional?

La concesión de acceso condicional de la aplicación cliente aprobada está en desuso y se retirará en marzo de 2026. MSAL NAA no admite esta directiva y devolverá errores (incluso si concede al complemento una excepción a esta directiva). Para migrar fuera de esta directiva, consulte Migración de la aplicación cliente aprobada a la directiva de protección de aplicaciones en Acceso condicional.

Algunas directivas de acceso condicional provocarán problemas para los complementos que usan MSAL NAA en función de lo que requieran del cliente. A menudo, están relacionadas con las directivas de administración de dispositivos. Para obtener más información, consulte Tipos de administración de dispositivos en Creación y asignación de directivas de protección de aplicaciones.

En ocasiones, debe controlar los desafíos de notificaciones en función de las directivas. Para obtener más información sobre cómo controlar un desafío de notificaciones en el complemento, consulte Desafíos de notificaciones, solicitudes de notificaciones y funcionalidades de cliente.

¿Por qué no se actualiza el token de identificador?

Hay un problema conocido en el que MSAL a veces no actualiza el token de identificador después de que expire. Esto no debería causar ningún problema en el complemento, ya que el token de identificador solo está pensado para su uso en el panel de tareas para obtener información básica de identidad de usuario, como el nombre y el correo electrónico. No hay ninguna razón para validar el token de identificador o comprobar la notificación de expiración. Si necesita autenticar el usuario en sus propios recursos, use el token de acceso que también contiene información de identidad de usuario. El token de identificador nunca debe pasarse fuera del código de cliente que lo recibió.

Cómo determinar si el usuario es una cuenta en línea o local?

Puede determinar si el usuario que ha iniciado sesión tiene una cuenta de Exchange Online o una cuenta de Exchange local mediante la propiedad Office.UserProfile.accountType. Si el valor de la propiedad de tipo de cuenta es enterprise, el buzón de correo se encuentra en un servidor exchange local. Tenga en cuenta que el Outlook 2016 perpetuo con licencia por volumen no admite la propiedad accountType. Para solucionar este problema, llame a la operación ResolveNames en el servicio web de Exchange (EWS) en el servidor local de Exchange para obtener los tipos de destinatario.

Nota:

La compatibilidad con Outlook 2016 y Outlook 2019 finaliza en octubre de 2025. Para obtener más información, vea Fin del soporte técnico para Office 2016 y Office 2019.

Cómo implementar mi complemento en Microsoft AppSource

Si va a publicar un nuevo complemento en Microsoft AppSource, tendrá que pasar por un proceso de certificación. Para obtener más información, vea Publicar el complemento de Office en Microsoft AppSource. Si va a actualizar el manifiesto de un complemento que ya está publicado en Microsoft AppSource, debe volver a realizar el proceso de certificación. Puede actualizar el código fuente del complemento en el servidor web en cualquier momento sin necesidad de pasar por el proceso de certificación.

Si el complemento usa el inicio de sesión único a través de NAA, el complemento debe cumplir las siguientes directrices de publicación.

Asegúrese de controlar el consentimiento del administrador correctamente. Consulte Publicación de un complemento que requiera el consentimiento del administrador para los ámbitos de Microsoft Graph.

Para obtener más detalles sobre la implementación, consulte Hacer que las soluciones estén disponibles en Microsoft AppSource y en Office. Si actualiza el complemento (cambie el manifiesto), deberá volver a realizar el proceso de certificación. Puede actualizar el código del servidor web en cualquier momento sin necesidad de revisión.

Los usuarios reciben un error no explicado al iniciar sesión

Cuando el complemento solicita un token, los usuarios pueden ver un cuadro de diálogo emergente de inicio de sesión que muestra uno de los siguientes errores.

  • Se ha producido un error. [código de error]
  • No puedes llegar allí desde aquí.

Compruebe si el administrador tiene aplicadas directivas de acceso condicional que aplican restricciones de cliente específicas, como la ubicación móvil o el tipo de plataforma. Además, la concesión de acceso condicional de la aplicación cliente aprobada está en desuso y provocará estos errores con las solicitudes de token NAA. Un administrador debe quitar completamente esta directiva y cambiar a la concesión de directiva de protección de aplicaciones más reciente para que NAA funcione. Para obtener más información, consulte Migración de la aplicación cliente aprobada a la directiva de protección de aplicaciones en acceso condicional.

Contenido relacionado