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

Muchos proveedores de identidades, además de la plataforma de identidad de Microsoft, pueden trabajar con su 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 para 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 solo concede los permisos que el usuario aprobó y expira después de un tiempo especificado.

Elegir 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 que se implementan con más frecuencia.

• 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 del código de autorización, el proveedor de identidad emite un secreto de cliente que debe permanecer confidencial. Una aplicación que no tiene back-end del lado servidor, como una SPA, no puede almacenar ese secreto de forma segura, por lo que recomendamos 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.

Usar el flujo implícito en complementos de Office

Compruebe la documentación del proveedor de identidad 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.

Usar el 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 obtener 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.
• OAuth general 2.0: El grupo de trabajo de OAuth del IETF mantiene el código OAuth, una página de enlaces a bibliotecas para más de una docena de idiomas. Algunas de estas bibliotecas sirven 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 intermediario, como Auth0, para realizar la autorización. Un servicio intermediario puede proporcionar tokens de acceso para servicios en línea populares, simplificar el inicio de sesión social para el complemento o ambas cosas. El complemento puede conectarse al servicio intermediario con un script del lado cliente o código del lado del servidor, y el servicio intermediario 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 del cuadro de diálogo de Office para abrir una página de inicio de sesión. Para obtener más información, vea Autenticar y autorizar con la API de diálogo de Office.

Al abrir un cuadro de diálogo de Office de esta forma, el cuadro de diálogo se ejecuta en una instancia del explorador y del motor JavaScript independientes de la página principal, como el panel de tareas o el archivo de funciones 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 API de un servicio intermediario. Algunos servicios proporcionan un conjunto de API en el que el código crea un objeto de contexto que obtiene un token y lo usa en llamadas posteriores al recurso. Algunos servicios incluso usan un solo método de API que realiza la llamada inicial y crea el objeto de contexto. Un objeto como este no se puede enlazar completamente, por lo que no se puede pasar del cuadro de diálogo de Office a la página primaria.

Los servicios intermediarios suelen proporcionar también un segundo conjunto de API en un nivel inferior de abstracción, como una API REST. Este conjunto de API de nivel inferior normalmente incluye una API que obtiene un token del servicio y otras API que devuelven 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 son las siglas de Cross-Origin Resource Sharing. Para obtener información sobre el uso de CORS en complementos, consulte Abordar las limitaciones de la directiva del mismo origen en los complementos de Office.

Vea también

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