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

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"}`


:::(Warning) (Services Not Using `expires_in`)

:::


### 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/resourceAuthorization: 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 distintas ventanas de caducidad 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.


:::(Warning) (Services Not Using `expires_in`)

:::


1. **Intento de flujo de tokens:**
2. Tulip inicia el flujo de tokens utilizando el tipo de concesión `refresh_token`, sustituyendo el tipo de concesión utilizado en el flujo de autenticación inicial.
3. **Validación de token:**
4. 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.
5. **Gestión de la ausencia de token:**
6. 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.
7. 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)