Autorización con proveedores de identidades que no son de Microsoft
Hay muchas identidades populares que proporcionan servicios, además de los Plataforma de identidad de Microsoft, que puede usar en el complemento. Proporcionan a los usuarios y aplicaciones, como el complemento de Office, acceso a las cuentas de los usuarios en otras aplicaciones.
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 los casos más típicos, cuando el usuario realiza una acción en el complemento de Office que solicita el servicio en línea, el complemento envía al servicio una solicitud para un conjunto específico de permisos en la cuenta del usuario. Después, el servicio pide al usuario que conceda esos permisos al complemento. Cuando se conceden los permisos, el servicio envía al complemento un pequeño token de acceso codificado. Para usar el servicio, el complemento incluye el token en todas sus solicitudes a las API del servicio. Pero el complemento solo puede actuar con los permisos que le ha concedido el usuario. Además, el token caduca después del tiempo especificado.
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, se le proporciona un secreto de cliente que debe mantener oculto. Una aplicación que no tiene back-end del lado del servidor, como una SPA, no tiene forma de proteger el secreto, por lo que le recomendamos que utilice el flujo implícito en 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.
Nota:
También tiene la posibilidad de usar un servicio intermediario para realizar el proceso de autorización y pasar el token de acceso al complemento. Para más información sobre este escenario, vea la sección Servicios intermediarios más adelante en este artículo.
Uso del flujo implícito en complementos de Office
La mejor manera de saber si un servicio en línea admite el flujo implícito es consultar la documentación específica del servicio.
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 más información sobre algunas de estas bibliotecas, 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 2.0 en general: hay una página de vínculos a bibliotecas para más de una docena idiomas gestionada por el grupo de trabajo de IETF para OAuth en: OAuth Code. Tenga en cuenta que algunas de estas bibliotecas son para implementar un servicio compatible con OAuth. Las bibliotecas de interés para un desarrollador de complementos se denominan bibliotecas cliente en esta página porque 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 o simplificar el proceso de habilitar el inicio de sesión social para el complemento. Con muy poco código, el complemento puede usar scripts del lado cliente o código del lado servidor para conectarse al servicio intermediario y enviar al complemento los tokens necesarios para el servicio en línea. Todo el código que implementa la autorización se encuentra en el servicio intermediario.
Se recomienda que la interfaz de usuario para la autenticación y autorización en el complemento use las API de cuadro de diálogo para abrir una página de inicio de sesión. Consulte Autenticación con la API de cuadro de diálogo de Office para obtener más información. Al abrir un cuadro de diálogo de Office de esta manera, el cuadro de diálogo tiene una instancia completamente nueva e independiente del explorador y el motor de JavaScript de la instancia en la página principal (por ejemplo, el panel de tareas del complemento o FunctionFile). Un token y cualquier otra información que puede convertirse en una cadena, se devuelve a la página principal con la API denominada messageParent. Después, la página principal puede usar el token para realizar llamadas autorizadas al recurso. Debido a esta arquitectura, debe tener cuidado con cómo usa las API proporcionadas por un servicio intermediario. A menudo, el servicio le proporcionará un conjunto de API en el que el código crea algún tipo de objeto de contexto que obtiene un token y usa ese token para hacer llamadas posteriores al recurso. A menudo, el servicio tiene un solo método API que realiza la llamada inicial y crea el objeto de contexto. Un objeto así no puede ser convertido completamente en cadenas, por lo que no se puede pasar desde el cuadro de diálogo de Office a la página principal. Normalmente, el servicio intermediario proporciona un segundo conjunto de API, en un nivel inferior de abstracción, como una API de REST. Este segundo conjunto tendrá una API que obtiene un token del servicio y otras API que pasan el token de servicio cuando se utiliza para obtener acceso autorizado al recurso. Deberá usar una API en este nivel inferior de abstracción para poder obtener el token en el cuadro de diálogo de Office y, después, usar messageParent para pasarlo a la página principal.
¿Qué es CORS?
CORS es el acrónimo de Cross Origin Resource Sharing (Uso compartido de recursos entre orígenes). Para obtener información sobre cómo usar CORS dentro de los complementos, consulte Abordar las limitaciones de la directiva de mismo origen en complementos para Office.