Qu'est-ce que OAuth2.0 ?

Exploration d'OAuth2.0

Bienvenue dans l'exploration d'OAuth2.0, un protocole d'authentification puissant mais souvent mal compris dans le monde de Tulip. Dans cet article, nous allons décortiquer les fondamentaux, vous guider à travers les flux d'authentification supportés par Tulip, démystifier la configuration de votre connecteur initial, et partager des conseils rapides pour un démarrage en douceur.

OAuth2.0 peut être complexe, et pour rester concis, nous avons omis certains aspects techniques détaillés dans cet article. Si vous souhaitez approfondir la gestion par Tulip des jetons de rafraîchissement, la gestion de la portée et de l'audience, et les configurations personnalisées des connecteurs, nous vous recommandons de consulter ce guide technique OAuth2.0 approfondi.

Dévoiler les bases

Avant d'entrer dans les détails, nous vous conseillons de vous familiariser avec les environnements et d'avoir une vue d'ensemble des hôtes de connecteurs et de leurs fonctions.

OAuth2.0 est un mécanisme permettant à Tulip (le client) d'établir son identité avec vos systèmes d'entreprise. L'accès est accordé par une poignée de main, et Tulip supporte principalement le flux de code d'autorisation, le flux OAuth le plus commun. Voici un aperçu condensé du déroulement de ce flux :

1. L'utilisateur initie le flux en cliquant sur le bouton Test avant de sauvegarder un Connecteur.
2. Tulip communique avec le serveur d'autorisation de votre fournisseur OAuth, partageant des paramètres spécifiques tels que l'identité du client, les champs d'application (ce à quoi vous essayez d'accéder), et d'autres détails pertinents.
3. Le serveur d'autorisation demande à l'utilisateur d'accorder l'accès, comme illustré ci-dessous :

1. Si l'utilisateur donne son accord, le serveur d'autorisation génère un code d'autorisation et conclut la fenêtre d'authentification.
2. Muni d'un code d'autorisation, Tulip demande en toute sécurité un jeton en s'adressant au point de terminaison du jeton, en fournissant le code d'autorisation, l'identifiant du client, le secret du client et d'autres propriétés.
3. Après avoir validé le code d'autorisation, le serveur répond avec un jeton et, éventuellement, un jeton de rafraîchissement. Ce jeton est utilisé pour les requêtes autorisées par l'utilisateur.
4. Tulip peut maintenant exécuter des requêtes au nom des utilisateurs, avec le jeton fourni pour l'autorisation.

Configuration d'OAuth

Exemple de configuration

Types d'authentification

Tulip supporte deux types d'authentification OAuth2.0 : Admin OAuth et Operator OAuth. La principale distinction réside dans la façon dont les informations d'identification sont partagées entre les utilisateurs.

• OAuth (Admin) : Utilise les informations d'identification fournies lors du test du connecteur pour tous les utilisateurs du lecteur Tulip. Idéal pour le partage des informations d'identification au sein de votre organisation. La réauthentification de l'administrateur est requise si les informations d'identification expirent.
• OAuth (Opérateur) : L'authentification est segmentée en fonction de l'utilisateur connecté à Tulip Player. Si un utilisateur ne s'est pas authentifié ou si l'authentification a expiré, l'utilisateur passe par le flux OAuth au sein de Tulip Player.

Code d'autorisation URL

C'est l'URL que Tulip contacte à l'étape 2 du flux du code d'authentification. Trouvée dans la documentation API de votre fournisseur OAuth, elle se termine généralement par /auth ou /authorize.

URL du jeton d'accès

Après la réponse du serveur d'autorisation, une requête est faite à l'URL du jeton d'accès pour obtenir un jeton d'authentification. Elle se termine généralement par /token.

ID et secret du client

Généré à partir de l'interface utilisateur de votre fournisseur OAuth, l'identifiant du client est transmis avec la demande initiale de code d'authentification. L'identifiant et le secret du client accompagnent toutes les demandes de jetons.

Audience et portée

L'audience précise les ressources spécifiques auxquelles l'utilisateur souhaite accéder, tandis que la portée définit les actions souhaitées sur ces ressources. Ces deux informations sont communiquées lors de la demande de code d'autorisation à l'étape 2.

Options supplémentaires

• Envoyer les données de la demande de jeton en tant que JSON : Modifie le type d'encodage de la demande envoyée à l'URL du jeton. Activé si nécessaire pour des intégrations spécifiques.
• Envoyer l'en-tête d'authentification pour la demande de rafraîchissement : Ajoute un Header supplémentaire aux demandes de rafraîchissement lorsque cette option est activée.
• Skip User Consent Prompt (Ignorer la demande de consentement de l'utilisateur) : Contrôle l'attribut d'invite de la demande de code d'authentification. Désactivé, il est défini sur le consentement, tandis qu'activé, il est défini sur la connexion, ce qui permet au fournisseur OAuth de décider de l'écran de connexion à afficher.

:::(Warning) (Remarque) Pour certaines intégrations, il convient d'exclure l'attribut prompt ou de lui attribuer la valeur " none". Contactez support@tulip.co pour plus de fonctionnalités :: :

Approfondir

Envie d'en savoir plus ? Consultez ces articles :

• Configuration d'OAuth2.0 et détails techniques
• Comment exécuter une fonction de connecteur dans plusieurs environnements ?