Opciones de autenticación
Antes de usar cualquier conector en Azure Logic Apps, Power Automate, o Power Apps, el usuario debe crear una conexión autenticándose en el servicio de red. Al crear un conector personalizado, puede definir cómo se autenticará quien vaya a usar el conector. Puede seleccionar el tipo de autenticación en la pestaña Seguridad del asistente de conectores en línea. La información adicional que deberá proporcionar dependerá del esquema de autenticación seleccionado.
Sin autenticación
Cuando esté seleccionada la opción Sin autenticación, no será necesaria más información. El usuario no necesitará autenticación para crear una conexión al conector personalizado y cualquier usuario anónimo podrá usar el conector. Esta opción solo debería usarse cuando la API permita el uso anónimo.
Autenticación básica
El tipo de autenticación más sencillo es Autenticación básica, en cuyo caso el usuario deberá facilitar el nombre de usuario y la contraseña para crear la conexión.
Los valores que introduzca en la columna Etiqueta de parámetro no serán el nombre de usuario ni la contraseña reales; son etiquetas para estos campos que el usuario verá al crear la conexión.
En el ejemplo anterior, se le pedirá al usuario que introduzca Usuario y Contraseña para crear una conexión. Debe hacer coincidir las etiquetas con los nombres que utiliza la API para aclararle a quien esté creando una conexión qué valores deberá usar con esa conexión.
Cualquier conexión de servicio que utilice Autenticación básica debe utilizar el protocolo HTTPS seguro para evitar el envío de credenciales no cifradas a distancia.
Autenticación de clave de API
Clave de API es un esquema de autenticación popular que utilizan los servicios web. Por ejemplo, Microsoft Azure Functions incluye parámetros de código como parte de la plantilla predeterminada.
Asegúrese de definir los siguientes valores:
Etiqueta de parámetro: la etiqueta para el mensaje de usuario al crear una nueva conexión.
Nombre del parámetro: el nombre del parámetro que contendrá el valor de la clave durante cada solicitud de servicio.
Ubicación del parámetro: ofrece a los fabricantes la opción de enviar la clave de API en el encabezado de la solicitud o la cadena de consulta al llamar al servicio subyacente.
En el ejemplo anterior, al usuario que cree una nueva conexión le aparecerá el siguiente mensaje.
El valor proporcionado se enviará al servicio subyacente como encabezado de solicitud X-Clave de API personalizada.
La plantilla predeterminada de Azure Functions puede usar código como nombre de parámetro y luego enviarlo como parte de la consulta estableciendo la ubicación del parámetro en Consulta, con lo que la URL del servicio será similar a:
https://functionurl.azurewebsites.net?code=user-supplied-code/
Similar a Autenticación básica, se recomienda utilizar el esquema de autenticación de Clave de API solo con protocolo HTTPS, para evitar el envío de claves sin cifrar.
Autenticación OAuth 2.0
El esquema de autenticación OAuth 2.0 solo está disponible para conectores en línea. Además de ofrecer soporte para OAuth 2.0 genérico, la plataforma proporciona implementaciones para servicios específicos, incluidos Microsoft Entra ID, GitHub, cuenta de Microsoft, etc. Las plantillas de proveedores de identidades prediseñadas, cuando se seleccionan, rellenan muchos de los campos requeridos por OAuth 2.0 con valores específicos del proveedor, con los que se reduce lo que tiene que facilitar.
La información adicional que se recopilará depende del proveedor de identidades. El proveedor de OAuth 2.0 genérico requiere los siguientes parámetros.
| Parámetro | Descripción |
|---|---|
| Id. de cliente | Identificador de la aplicación OAuth en el sistema de destino, introducido manualmente o generado por el proveedor al registrar la aplicación. |
| Secreto de cliente | Secreto asociado con la aplicación OAuth, generado por el proveedor. La mayoría de los proveedores también pueden revocar secretos existentes y emitir otros nuevos. |
| URL de autorización | URL utilizada para iniciar sesión del usuario y autorizar la aplicación, por ejemplo: https://www.facebook.com/v9.0/dialog/oauth o https://login.salesforce.com/services/oauth2/authorize. |
| URL de token | URL utilizada para obtener un token después de que el usuario haya autorizado la aplicación, por ejemplo: https://graph.facebook.com/v9.0/oauth/access_token o https://mycompany.salesforce.com/mycompany.salesforce.com. |
| URL de actualización | URL utilizada para obtener un nuevo token mediante el uso de un token de actualización, después de que el original haya vencido. Esta URL suele ser la misma que la URL del token para la mayoría de los servicios. |
| Ámbito | Cadena que representa los permisos que busca del usuario. Deje este parámetro en blanco o consulte la documentación del proveedor para especificar el ámbito del permiso que requiere su aplicación. |
Asegúrese de registrar el conector con el proveedor de identidades en forma de aplicación cliente; los detalles de registro específicos dependen del proveedor y los documenta el proveedor de identidades. Por ejemplo, para autenticarse usando Facebook, un creador generaría una aplicación de Facebook utilizando sus herramientas de desarrollo. Dado que los parámetros Id. de cliente y Secreto de cliente forman parte de las especificaciones de OAuth 2.0, los facilitan todos los proveedores de identidades OAuth 2.0 como parte del registro de la aplicación. Un valor que debe incluirse con el registro de la aplicación es URL de redireccionamiento. Este valor de la configuración del conector está inicialmente vacío, pero pasa a estar disponible cuando se guarda la configuración. Luego se puede copiar y guardar con el registro del conector con el proveedor de identidad.
La mayoría de los proveedores específicos solo requieren Id. de cliente, secreto de cliente y ámbito opcional, porque todas las URL están predefinidas para un servicio específico.
Una vez que el conector se haya publicado y esté disponible para los usuarios, se pedirá a estos últimos que introduzcan sus credenciales para iniciar sesión en el servicio durante el proceso de creación de la conexión. La aplicación utilizará estas credenciales para obtener un token de autorización. Para cada solicitud, este token de autorización se enviará a su servicio a través del encabezado de autorización estándar.
El símbolo (token) de autorización es de corta validez, y el runtime del conector utilizará el proceso de actualización para la renovación, de modo que los usuarios del conector no están implicados en el proceso de actualización.
Autenticación de Windows
La opción de autenticación de Windows está disponible solo para conexiones que usan puerta de enlace de datos local, cuando está marcada la casilla Conectarse a través de una puerta de enlace de datos local en la pestaña General. No se requiere información adicional para el esquema de autenticación de Windows.
Al crear una nueva conexión, el usuario deberá facilitar las credenciales de Windows para el servicio y luego seleccionar una de las puertas de enlace locales instaladas.
La especificación de OpenAPI que utiliza la plataforma incluye las definiciones de clave de API y autenticación básica. También puede modificarlas directamente en línea utilizando el editor Swagger. Otros esquemas de autenticación almacenan la información de autenticación por separado como propiedades extendidas del conector. Si bien esta información no está disponible para la edición de fuente directa en línea, puede modificarla utilizando la herramienta paconn. La interfaz de la línea de comandos (CLI) permite la creación de scripts del proceso de implementación del conector cuando se requiere implementación automatizada.
Los conectores personalizados admiten diversos esquemas de autenticación para adaptarse a los requisitos para permitir el acceso a servicios de API de REST seguros. Cuando los servicios de API se implementan y protegen dentro de un ambiente de Azure AD, la infraestructura del conector ofrece otras ventajas. Podrá aprender más sobre los detalles específicos de Azure AD en la siguiente unidad.