Opciones de autenticación en complementos de Outlook

El complemento de Outlook tiene acceso a la información desde cualquier lugar en Internet, ya sea desde el servidor que hospeda el complemento, desde una red interna o desde otro lugar en la nube. Si esa información está protegida, el complemento necesita una forma de autenticar el usuario. Los complementos de Outlook ofrecen una serie de métodos de autenticación diferentes, en función de su situación específica.

Token de acceso de inicio de sesión único mediante el flujo de OBO

Los tokens de acceso de inicio de sesión único (SSO) proporcionan una manera perfecta de que el complemento de Outlook autentique y obtenga tokens de acceso para llamar a Microsoft Graph API. Esta función reduce los conflictos ya que el usuario no necesita escribir sus credenciales. Puede usar el flujo en nombre de con un servidor de nivel intermedio o la autenticación de aplicaciones anidadas (que se describe en la sección siguiente).

Nota:

El inicio de sesión único con el flujo de OBO se admite actualmente para Word, Excel, Outlook y PowerPoint. Para obtener más información sobre la compatibilidad, consulte Conjuntos de requisitos de IdentityAPI. Si está trabajando con un complemento de Outlook, asegúrese de habilitar la autenticación moderna para el inquilino de Microsoft 365. Para obtener información sobre cómo hacerlo, vea Habilitar o deshabilitar la autenticación moderna para Outlook en Exchange Online.

Considere el uso de token de acceso SSO si el complemento:

• Es usado principalmente por usuarios de Microsoft 365
• Necesita tener acceso a:
  • Servicios Microsoft expuestos como parte de Microsoft Graph
  • Un servicio que no sea de Microsoft y que controle

El método de autenticación SSO usa elOAuth2 en nombre de flujo que proporciona Azure Active Directory. Requiere que el complemento se registre en el Portal de registro de aplicaciones y especifique los ámbitos de Microsoft Graph necesarios en el manifiesto del complemento, si se usa el manifiesto XML. Si el complemento usa el manifiesto unificado para Microsoft 365, hay alguna configuración de manifiesto, pero no se especifican los ámbitos de Microsoft Graph. En su lugar, los ámbitos necesarios se especifican en tiempo de ejecución en una llamada para capturar un token en Microsoft Graph.

Con este método, el complemento puede obtener un token de acceso en el ámbito de la API de servidor back-end. El complemento usa esto como un token de portador en el Authorization encabezado para autenticar una llamada a la API. En ese momento, el servidor puede:

• Completar el flujo en nombre de para obtener un token de acceso en el ámbito de la API de Microsoft Graph
• Usar la información de identidad del token para establecer la identidad del usuario y autenticar sus propios servicios back-end

Para obtener información más detallada, consulte la información general completa sobre el método de autenticación SSO.

Para obtener más información sobre cómo usar el token SSO en un complemento de Outlook, consulte autenticar a un usuario con un token de inicio de sesión único en un complemento de Outlook.

Para ver un complemento de ejemplo que usa un token SSO, consulte SSO del complemento de Outlook.

Token de acceso de inicio de sesión único mediante la autenticación de aplicaciones anidadas (versión preliminar)

La autenticación de aplicaciones anidadas (NAA) habilita la Sign-On única (SSO) para complementos de Office que se ejecutan en el contexto de aplicaciones nativas de Office. En comparación con el flujo en nombre de que se usa con Office.js y getAccessToken(), NAA proporciona una mayor flexibilidad en la arquitectura de aplicaciones, lo que permite la creación de aplicaciones enriquecidas y controladas por el cliente. NAA simplifica el control del inicio de sesión único para el código del complemento. NAA le permite realizar llamadas de Microsoft Graph desde el código de cliente del complemento como spa sin necesidad de un servidor de nivel intermedio. No es necesario usar Office.js API, ya que la biblioteca de MSAL.js proporciona NAA.

Importante

La autenticación de aplicaciones anidadas está actualmente en versión preliminar. Para probar esta característica, únase al Programa Insider de Microsoft 365 (https://insider.microsoft365.com/join) y elija el canal beta. No use NAA en complementos de producción. Le invitamos a probar NAA en entornos de prueba o desarrollo y recibir comentarios sobre su experiencia a través de GitHub (consulte la sección Comentarios al final de esta página).

Para permitir que el complemento de Outlook use NAA, consulte Habilitación del inicio de sesión único en un complemento de Office mediante la autenticación de aplicaciones anidadas (versión preliminar). NAA funciona igual en todos los complementos de Office.

Token de identidad de usuario de Exchange

Importante

Los tokens de identidad de usuario y los tokens de devolución de llamada heredados de Exchange se desactivarán para todos los inquilinos de Exchange Online en octubre de 2024 como parte de la Iniciativa de futuro seguro de Microsoft, que proporciona a las organizaciones las herramientas necesarias para responder al panorama actual de amenazas. Los tokens de identidad de usuario de Exchange seguirán funcionando para Exchange local. La autenticación de aplicaciones anidadas es el enfoque recomendado para los tokens en el futuro. Para obtener más información, consulte nuestra entrada de blog sobre la autenticación de aplicaciones anidadas y los tokens de Exchange heredados.

Los token de identidad de usuario de Exchange proporcionan un método para que el complemento establezca la identidad del usuario. Mediante la comprobación de la identidad del usuario, puede realizar una autenticación única en el sistema back-end y aceptar el token de identidad del usuario como una autorización para las solicitudes futuras. Use el token de identidad de usuario de Exchange:

• Cuando el complemento es usado principalmente por usuarios locales de Exchange.
• Cuando el complemento necesita tener acceso a un servicio que no sea Microsoft y que usted controle.
• Como una autenticación de reserva cuando el complemento se ejecuta en una versión de Office que no es compatible con SSO.

El complemento puede llamar a getUserIdentityTokenAsync para obtener los tokens de identidad de usuario de Exchange. Para obtener más detalles sobre el uso de estos token, consulte Autenticar a un usuario con un token de identidad para Exchange.

Tokens de acceso obtenidos a través de flujos de OAuth2

Los complementos también pueden acceder a servicios de Microsoft y otros que admiten OAuth2 para la autorización. Considere el uso de tokens OAuth2 si el complemento:

• Necesita acceso a un servicio fuera de su control.

Con este método, el complemento pide al usuario que inicie sesión en el servicio mediante el método displayDialogAsync para inicializar el flujo de OAuth2.

Tokens de devolución de llamada

Importante

Los tokens de identidad de usuario y los tokens de devolución de llamada heredados de Exchange se desactivarán para todos los inquilinos de Exchange Online en octubre de 2024 como parte de la Iniciativa de futuro seguro de Microsoft, que proporciona a las organizaciones las herramientas necesarias para responder al panorama actual de amenazas. Los tokens de identidad de usuario de Exchange seguirán funcionando para Exchange local. La autenticación de aplicaciones anidadas es el enfoque recomendado para los tokens en el futuro. Para obtener más información, consulte nuestra entrada de blog sobre la autenticación de aplicaciones anidadas y los tokens de Exchange heredados.

Los tokens de devolución de llamada proporcionan acceso al buzón del usuario de su servidor back-end, mediante servicios Web Exchange (EWS), o API de REST Outlook. Considere el uso de tokens de devolución de llamada si el complemento:

• Necesita tener acceso al buzón de usuario de su servidor back-end.

Los complementos obtienen token de devolución de llamada con los métodos getCallbackTokenAsync. El nivel de acceso se controla con los permisos especificados en el manifiesto del complemento.