Configuration et détails techniques d'OAuth2.0

Dans cet article, nous allons nous plonger dans les détails techniques de la façon dont Tulip implémente OAuth pour l'authentification des connecteurs. OAuth est puissant, mais il s'accompagne d'une certaine complexité. Ce guide est destiné à répondre à toutes les questions techniques sur ce que Tulip supporte et comment il est intégré.

Note : Le flux des informations d'identification du client diffère quelque peu du flux du code d'autorisation. Les étapes 1 et 2 ne sont pas pertinentes pour le flux des informations d'identification du client.

Flux du code d'autorisation Tulip

:::(Warning) (Services sur site) Les points de terminaison Authorize et Token doivent être accessibles au nuage pour que Tulip exécute l'authentification pour les connecteurs :: :

Tulip initie le processus d'authentification lors du test d'un connecteur ou de l'exécution d'une fonction de connecteur dans une application.

1. Redirection vers le serveur d'autorisation :

L'application Tulip redirige l'utilisateur vers le serveur d'autorisation (AS) avec des paramètres spécifiques, y compris le response_type (défini à "code" pour le flux de code d'autorisation), client_id (assigné dans l'interface utilisateur du connecteur), redirect_uri (prédéfini par Tulip), scope et audience (définis dans l'interface utilisateur), et state (une chaîne aléatoire pour se protéger contre les attaques Cross-Site Request Forgery).

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

2. L'utilisateur donne son accord :

Le serveur d'autorisation authentifie l'utilisateur et lui présente un écran de consentement. L'utilisateur peut examiner les autorisations demandées et décider d'accorder ou de refuser l'accès à l'application tierce.

:::(Warning) (Note) Dans la configuration d'un connecteur give, le contrôle "Skip user consent prompt" vous permet de contrôler l'attribut prompt sur la demande d'autorisation. Lorsque ce contrôle est désactivé, c'est la valeur " consentement" qui est utilisée, alors que lorsque ce contrôle est activé, c'est la valeur "connexion" qui est utilisée.

Si d'autres valeurs de l'attribut prompt sont nécessaires, contactez support@tulip.co, et nous activerons d'autres options pour cette propriété. :: :

3. Code d'autorisation :

Si l'utilisateur donne son accord, le serveur d'autorisation génère un code d'autorisation et redirige l'utilisateur vers Tulip avec le code d'autorisation. Le paramètre d'état est également inclus, ce qui permet au client de vérifier l'intégrité de la réponse. Ce paramètre d'état doit correspondre au paramètre d'état transmis à l'étape 1.

Exemple de redirection vers l'URI de redirection du client :

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Demande de jeton :

Le client dispose maintenant du code d'autorisation et l'utilise pour effectuer une demande sécurisée, de serveur à serveur, au point de terminaison du jeton du serveur d'autorisation. Le client inclut le grant_type (défini sur "authorization_code"), le client_id, le client_secret (un secret connu uniquement du client et du serveur d'autorisation), le redirect_uri et le code d'autorisation.

Exemple de demande de jeton :

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


### 5. Réponse au jeton d'accès :


Si le code d'autorisation est valide, le serveur d'autorisation répond par un jeton d'accès et, éventuellement, un jeton de rafraîchissement. Le jeton d'accès est utilisé par le client pour s'authentifier lorsqu'il effectue des demandes à l'API protégée au nom de l'utilisateur.


Exemple de réponse par jeton :


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


### 6. Accès au serveur de ressources :


Tulip peut maintenant utiliser le jeton d'accès obtenu pour faire des requêtes autorisées au serveur de ressources (API) au nom de l'utilisateur. Le jeton d'accès est généralement inclus dans l'en-tête Authorization de la requête HTTP.


Exemple de requête API :`GET /api/resource Authorization : Bearer ACCESS_TOKEN`


## Gestion de l'expiration des jetons avec les jetons de rafraîchissement


Les serveurs d'autorisation fixent généralement des dates d'expiration pour les jetons afin de réguler l'accès, avec des fenêtres d'expiration variables en fonction du système interfacé. Cependant, les jetons à courte durée de vie posent un problème car l'authentification constante de l'utilisateur perturbe l'expérience de l'utilisateur dans les applications Tulip.


Pour résoudre ce problème, OAuth prend en charge les jetons de rafraîchissement. Bien qu'optionnels, ils sont fortement recommandés car ils rationalisent l'expérience de l'utilisateur en permettant à Tulip de rafraîchir les tokens de manière transparente sans nécessiter d'intervention manuelle de la part des opérateurs.


### Comment Tulip gère le rafraîchissement des jetons


Lorsque Tulip détecte qu'un jeton d'accès a expiré, il tente automatiquement d'utiliser le jeton de rafraîchissement associé pour obtenir un nouveau jeton. L'objectif principal est de minimiser la réauthentification de l'utilisateur. Les étapes suivantes décrivent la logique exécutée par Tulip :


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


1. **Détection de l'expiration :**
2. Tulip identifie un jeton expiré sur la base de son attribut `expires_in` reçu à l'[étape 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) du flux d'authentification.
3. **Tentative de flux de jetons :**
4. Tulip initie le flux de jetons en utilisant le type de subvention `refresh_token`, remplaçant le type de subvention `authorization_code` utilisé dans le flux d'authentification initial.
5. **Validation du jeton :**
6. Si un nouveau jeton est obtenu, Tulip le stocke et procède à l'exécution de la fonction de connecteur demandée par l'utilisateur.


	* En cas de succès, les données sont fournies à l'application Tulip.
	* Si le nouveau jeton échoue avec une erreur OAuth, Tulip réessaie le processus jusqu'à 5 fois, en revenant à l'étape 1 à chaque fois.
	* Si le nouveau jeton échoue à cause d'une autre erreur, une erreur est affichée dans le moteur d'exécution du lecteur.
7. **Gestion de l'absence de jeton :**
8. Si un nouveau jeton n'est pas fourni, Tulip invite l'utilisateur du lecteur à s'authentifier, ce qui lance l'ensemble du processus d'authentification.
9. Une fois le processus terminé, la fonction du connecteur est exécutée et les données sont renvoyées.


En mettant en œuvre des jetons de rafraîchissement, Tulip garantit une expérience utilisateur plus fluide en gérant intelligemment l'expiration et le renouvellement des jetons, minimisant ainsi les perturbations du flux de travail.


## Pour en savoir plus


* [Introduction à Tulip Connector Hosts](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Snapshot du connecteur](/r230/docs/connector-snapshotting)
* [OAuth2.0 expliqué](/r230/docs/oauth20-explained)