Configuración y detalles técnicos de OAuth2.0

En este artículo, profundizaremos en los detalles técnicos de cómo Tulip implementa OAuth para la autenticación de conectores. OAuth es poderoso, pero esto viene con cierta complejidad añadida. Esta guía pretende responder a cualquier pregunta técnica sobre lo que Tulip soporta, y cómo se integra.

Nota: El flujo de Credenciales de Cliente difiere un poco del flujo de código de autorización. Los pasos 1 y 2 no son relevantes para el flujo de Credenciales de Cliente.

Flujo de código de autorización de Tulip

:::(Warning) (Servicios On-Prem) Los endpoints Authorize y Token deben ser accesibles a la nube para que Tulip ejecute la autenticación para los conectores :::

Tulip inicia el proceso de autenticación cuando se prueba un Connector o se ejecuta una Connector Function dentro de una aplicación.

1. 1. Redirección al servidor de autorización:

La aplicación Tulip redirige al usuario al Servidor de Autorización (AS) junto con parámetros específicos, incluyendo el response_type (establecido en "code" para el Flujo de Código de Autorización), client_id (asignado en la UI del conector), redirect_uri (predefinido por Tulip), scope y audience (establecidos en la UI), y state (una cadena aleatoria para proteger contra ataques de Cross-Site Request Forgery).

Ejemplo:GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. El usuario otorga su consentimiento:

El Servidor de Autorización autentica al usuario y le presenta una pantalla de consentimiento. El usuario puede revisar los permisos solicitados y decidir si concede o deniega el acceso a la aplicación de terceros.

:::(Warning) (Nota) Dentro de la configuración de un conector give, el control "Skip user consent prompt" permite controlar el atributo prompt en la solicitud de autorización. Con este control desactivado, se utilizará el valor consentimiento, cuando esté activado se utilizará inicio de sesión.

Si se requieren valores adicionales del atributo prompt, póngase en contacto con support@tulip.co, y habilitaremos más opciones para esta propiedad. :::

3. Código de Autorización:

Si el usuario da su consentimiento, el Servidor de Autorización genera un código de autorización y redirige al usuario de vuelta a Tulip junto con el código de autorización. También se incluye el parámetro de estado, que permite al cliente verificar la integridad de la respuesta. Este parámetro de estado debe coincidir con el parámetro de estado pasado en el Paso 1.

Ejemplo de redirección al URI de redirección del cliente:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. 4. Solicitud de token:

El cliente dispone ahora del código de autorización y lo utiliza para realizar una solicitud segura de servidor a servidor al punto final de token del servidor de autorización. El cliente incluye el grant_type (definido como "authorization_code"), client_id, client_secret (un secreto que sólo conocen el cliente y el servidor de autorización), redirect_uri y el código de autorización.

Ejemplo de solicitud de token:

grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET ```


### 5. Respuesta de token de acceso:


Si el código de autorización es válido, el Servidor de Autorización responde con un token de acceso y, opcionalmente, un token de actualización. El token de acceso lo utiliza el cliente para autenticarse cuando realiza solicitudes a la API protegida en nombre del usuario.


Ejemplo de respuesta de token:


`{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE" }`


### 6. Acceso al servidor de recursos:


Tulip puede ahora utilizar el token de acceso obtenido para realizar peticiones autorizadas al Servidor de Recursos (API) en nombre del usuario. El token de acceso se incluye normalmente en la cabecera Authorization de la petición HTTP.


Ejemplo de solicitud API:`GET /api/resource Autorización: Portador ACCESO_TOKEN`


## Gestión de la caducidad de tokens con tokens de actualización


Los servidores de autorización suelen establecer fechas de caducidad para los tokens con el fin de regular el acceso, con ventanas de caducidad variables en función del sistema interconectado. Sin embargo, los tokens de corta duración suponen un reto, ya que la autenticación constante del usuario interrumpe la experiencia del usuario en las aplicaciones Tulip.


Para solucionar este problema, OAuth admite tokens de actualización. Aunque son opcionales, son muy recomendables, ya que agilizan la experiencia del usuario, permitiendo a Tulip actualizar los tokens sin problemas y sin necesidad de intervención manual de los operadores.


### Cómo gestiona Tulip la actualización de tokens


Cuando Tulip detecta que un token de acceso ha caducado, automáticamente intenta utilizar el token de actualización asociado para obtener un nuevo token. El objetivo principal es minimizar la reautenticación del usuario. Los siguientes pasos describen la lógica ejecutada por Tulip:


![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)


1. **Detección de caducidad:**
2. Tulip identifica un token caducado basándose en su atributo `expires_in` recibido en [el paso 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) del flujo de autenticación.
3. **Intento de flujo de tokens:**
4. Tulip inicia el flujo de tokens utilizando el tipo de concesión `refresh_token`, en sustitución del tipo de concesión `authorization_code` utilizado en el flujo de autenticación inicial.
5. **Validación de token:**
6. Si se obtiene un nuevo token, Tulip lo almacena y procede a ejecutar la función de conector solicitada por el usuario.


	* Si tiene éxito, los datos se proporcionan al tiempo de ejecución de la aplicación Tulip.
	* Si el nuevo token falla con un error OAuth, Tulip reintenta el proceso hasta 5 veces, volviendo al paso 1 cada vez.
	* Si el nuevo token falla con cualquier otro error, se muestra un error en el tiempo de ejecución del reproductor.
7. **Gestión de la ausencia de token:**
8. Si no se proporciona un nuevo token, Tulip solicita al usuario en el reproductor que se someta a la autenticación, iniciando todo el proceso de autenticación.
9. Una vez completado, se ejecuta la función del conector y se devuelven los datos.


Mediante la implementación de tokens de actualización, Tulip garantiza una experiencia de usuario más fluida al gestionar de forma inteligente la caducidad y renovación de tokens, minimizando las interrupciones en el flujo de trabajo.


## Más información


* [Introducción a Tulip Connector Hosts](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Connector Snapshotting](/r230/docs/connector-snapshotting)
* [Explicación de OAuth2.0](/r230/docs/oauth20-explained)