¿Qué es OAuth2.0?

Explorando OAuth2.0

Bienvenido a una exploración de OAuth2.0, un protocolo de autenticación poderoso pero a menudo incomprendido dentro del Tulip-verso. En este artículo, vamos a desentrañar los fundamentos, guiarte a través de los flujos de autenticación soportados por Tulip, desmitificar la configuración de tu conector inicial, y compartir consejos rápidos para un comienzo sin problemas.

OAuth2.0 puede ser intrincado, y para mantener las cosas concisas, hemos omitido algunos aspectos técnicos detallados de este artículo. Si deseas profundizar en el manejo de Tulip de los tokens de actualización, la gestión del alcance y la audiencia, y las configuraciones personalizadas del conector, te recomendamos que consultes esta guía técnica en profundidad de OAuth2.0.

Desvelando lo básico

Antes de profundizar en los detalles, sugerimos familiarizarse con los entornos y obtener una visión general de los hosts de conectores y sus funciones.

OAuth2.0 sirve como mecanismo para que Tulip (el cliente) establezca su identidad con tus sistemas empresariales. El acceso se concede a través de un apretón de manos, y Tulip soporta principalmente el flujo de código de autorización, el flujo más común de OAuth. He aquí una visión general condensada de cómo se desarrolla este flujo:

1. El usuario inicia el flujo pulsando el botón Test antes de guardar un Connector.
2. Tulip se comunica con el servidor de Autorización de su proveedor de OAuth, compartiendo parámetros específicos como la identidad del cliente, alcances (a qué está intentando acceder), y otros detalles relevantes.
3. El servidor de autorización solicita al usuario que conceda el acceso, como se muestra a continuación:

1. Tras el consentimiento del usuario, el servidor de autorización genera un código de autorización y concluye la ventana de autenticación.
2. Armado con un código de autorización, Tulip solicita de forma segura un token llegando al punto final del token, proporcionando el código de autorización, id de cliente, secreto de cliente y propiedades adicionales.
3. Tras validar el código de autorización, el servidor responde con un token y, opcionalmente, con un token de actualización. Este token sirve para las solicitudes autorizadas por el usuario.
4. Tulip puede ahora ejecutar peticiones en nombre de los usuarios, con el token proporcionado para la autorización.

Configuración de OAuth

Ejemplo de configuración

Tipos de autenticación

Tulip soporta dos tipos de autenticación OAuth2.0: Admin OAuth y Operator OAuth. La distinción clave radica en cómo se comparten las credenciales entre los usuarios.

:::(Info) (Nota) En versiones anteriores de Tulip, OAuth2.0 (Cuenta de servicio) se denominaba OAuth2 (Admin) y OAuth2.0 (Credenciales de usuario) se denominaba OAuth2 (Operador). :::

• OAuth2.0 (Cuenta de servicio): Utiliza las credenciales proporcionadas durante las pruebas del conector para todos los usuarios de Tulip Player. Ideal para compartir credenciales en toda la organización. Se requiere la reautenticación del administrador si las credenciales caducan.
• OAuth2.0 (Credenciales de usuario): Segmenta la autenticación basándose en el usuario que ha iniciado sesión en Tulip Player. Si un usuario no se ha autenticado o la autenticación expira, el usuario se somete al flujo OAuth dentro de Tulip Player.

Código de Autorización URL

Esta es la URL que Tulip contacta en el paso 2 del flujo del código de autenticación. Se encuentra en la documentación de la API de tu proveedor de OAuth, normalmente termina en /auth o /authorize.

URL del token de acceso

Después de la respuesta del servidor de autorización, se realiza una solicitud a la URL del token de acceso para obtener un token para la autenticación. Suele terminar en /token.

ID de cliente y secreto de cliente

Generado desde la interfaz de usuario del proveedor de OAuth, el ID de cliente se pasa con la solicitud inicial de un código de autenticación. El ID de cliente y el secreto de cliente acompañan a todas las solicitudes de token.

Audiencia y alcance

Audiencia especifica los activos específicos a los que su usuario busca acceso, mientras que Alcance define las acciones deseadas en estos activos. Ambos se transmiten durante la solicitud del código de autorización en el paso 2.

Opciones adicionales

• Enviar datos de solicitud de token como {{glosario.JSON}}: Cambia el tipo de codificación para la solicitud enviada a la URL del token. Activado si es necesario para integraciones específicas.
• Enviar encabezado de autenticación para la solicitud de actualización: Añade un Header adicional a las solicitudes de actualización cuando está activado.
• Omitir solicitud de consentimiento del usuario: Controla el atributo de solicitud del código de autenticación. Desactivado lo establece en consentimiento, mientras que activado lo establece en inicio de sesión, dejando que el proveedor de OAuth decida qué pantalla de inicio de sesión mostrar.

:::(Warning) (Nota) Para algunas integraciones, excluye o establece el atributo prompt a ninguno. Ponte en contacto con support@tulip.co para obtener más información. :::

Profundizando

¿Desea obtener más información? Explore estos artículos:

• Configuración y detalles técnicos de OAuth2.0
• Cómo ejecutar una función de conector en varios entornos