Autorización con proveedores de identidades que no son de Microsoft

Muchos proveedores de identidades, además de los Plataforma de identidad de Microsoft, pueden trabajar con el complemento. Estos proveedores permiten a los usuarios conceder a un complemento de Office acceso a sus cuentas en otros servicios.

El marco de trabajo estándar de la industria para habilitar el acceso de una aplicación web a un servicio en línea es OAuth 2.0. En la mayoría de los casos, no es necesario conocer los detalles de cómo funciona el marco para usarlo en el complemento. Existen muchas bibliotecas que simplifican los detalles.

Una idea fundamental de OAuth es que una aplicación puede ser una entidad de seguridad ante sí misma, al igual que un usuario o un grupo, con su propia identidad y conjunto de permisos. En un flujo típico, un usuario realiza una acción en el complemento que requiere otro servicio. El complemento solicita un conjunto específico de permisos a la cuenta de ese usuario. A continuación, el servicio solicita al usuario que conceda esos permisos.

Una vez concedido el permiso, el servicio envía al complemento un token de acceso codificado. El complemento incluye el token en las solicitudes a las API del servicio. El token concede solo los permisos aprobados por el usuario y expira después de una hora especificada.

Elección de un flujo de OAuth 2.0

Hay varios modelos de OAuth, llamados flujos o tipos de concesión, diseñados para distintos escenarios. Los dos patrones siguientes son los más comúnmente implementados.

• Flujo implícito: la comunicación entre el complemento y el servicio en línea se implementa con código JavaScript del lado cliente. Este flujo se suele usar en aplicaciones de una sola página (SPA).
• Flujo de código de autorización: la comunicación se establece de servidor a servidor entre la aplicación web del complemento y el servicio en línea. Por tanto, se implementa con código de servidor.

El propósito del flujo de OAuth es proteger la identidad y la autorización de la aplicación. En el flujo de código de autorización, el proveedor de identidades emite un secreto de cliente que debe permanecer confidencial. Una aplicación que no tiene ningún back-end del lado servidor, como un SPA, no puede almacenar ese secreto de forma segura, por lo que se recomienda el flujo implícito para las SPA.

Debe estar familiarizado con las ventajas y los inconvenientes del flujo implícito y del flujo de código de autorización. Para más información sobre estos dos flujos, vea Código de autorización e Implícito.

Uso del flujo implícito en complementos de Office

Compruebe la documentación del proveedor de identidades para confirmar que admite el flujo implícito.

Para obtener información sobre otras bibliotecas que admiten el flujo implícito, vea la sección Bibliotecas más adelante en este artículo.

Uso del flujo de código de autorización en complementos de Office

Hay muchas bibliotecas disponibles para implementar el flujo de código de autorización en distintos lenguajes y marcos de trabajo. Para ver algunos ejemplos, consulte la sección Bibliotecas más adelante en este artículo.

Bibliotecas

Las bibliotecas están disponibles para muchas plataformas e idiomas, tanto para el flujo implícito como para el flujo de código de autorización. Algunas bibliotecas son de uso general, mientras que otras son para servicios en línea específicos.

• Facebook: busque "biblioteca" o "sdk" en Facebook for Developers.
• General OAuth 2.0: el grupo de trabajo de OAuth de IETF mantiene el código de OAuth, una página de vínculos de biblioteca para más de una docena de idiomas. Algunas de estas bibliotecas son para implementar un servicio compatible con OAuth. Para un complemento de Office, busque bibliotecas cliente , ya que el servidor web es un cliente del servicio compatible con OAuth.

Servicios intermediarios

El complemento puede usar un servicio intermedio, como OAuth.io o Auth0 , para realizar la autorización. Un servicio intermediario podría proporcionar tokens de acceso para servicios en línea populares, simplificar el inicio de sesión social para el complemento o ambos. El complemento puede conectarse al servicio middleman con el script del lado cliente o el código del lado servidor, y el servicio middleman devuelve los tokens necesarios para el servicio en línea.

Se recomienda que la interfaz de usuario para la autenticación y autorización en el complemento use la API de cuadro de diálogo de Office para abrir una página de inicio de sesión. Para obtener más información, consulte Autenticación y autorización con la API de cuadro de diálogo de Office.

Al abrir un cuadro de diálogo de Office de esta manera, el cuadro de diálogo se ejecuta en un explorador independiente e instancia del motor de JavaScript desde la página primaria, como el panel de tareas o el archivo de función del complemento. Un token y cualquier otra información que se pueda convertir en una cadena se devuelve al elemento primario mediante messageParent. Después, la página principal puede usar el token para realizar llamadas autorizadas al recurso.

Debido a esta arquitectura, tenga cuidado al usar las API de un servicio intermedio. Algunos servicios proporcionan un conjunto de API en el que el código crea un objeto de contexto que obtiene un token y usa ese token en llamadas posteriores al recurso. Algunos servicios incluso usan un único método de API que realiza la llamada inicial y crea el objeto de contexto. Un objeto como este no se puede stringified completamente, por lo que no se puede pasar desde el cuadro de diálogo de Office a la página primaria.

Los servicios de Middleman normalmente también proporcionan un segundo conjunto de API en un nivel inferior de abstracción, como una API REST. Este conjunto de API de nivel inferior suele incluir una API que obtiene un token del servicio y otras API que pasan el token al servicio al solicitar acceso al recurso. Use este conjunto de API de nivel inferior para que el cuadro de diálogo de Office pueda obtener el token y, a continuación, pasarlo a la página primaria mediante messageParent.

¿Qué es CORS?

CORS significa Uso compartido de recursos entre orígenes. Para obtener información sobre el uso de CORS en complementos, vea Abordar las limitaciones de directivas del mismo origen en complementos de Office.

Vea también

• Información general sobre autenticación y autorización en los complementos de Office