--- schema_version: "1" id: 055c93bd84d9082d66947b6b7a53d6d4445002c821651e3f15cb60c111c01e17 title: "Configurer OAuth externe pour Snowflake : flux d’identifiants client" collection: tableau version: current locale: fr-ca portal_url: https://docs.salesforce.com/tableau/current/fr-ca/online/config_oauth_snowflake_client_creds.md canonical_url: https://help.tableau.com/current/online/fr-ca/config_oauth_snowflake_client_creds.htm source_site: help.tableau.com content_type: documentation content_hash: ad85f433dd5832e141b2024199d563d43b39955ea5173a558ee28d6ede51e6a4 description: Configure Azure AD OAuth and modern authentication for Azure and Microsoft connectors in Tableau Server. --- [Passer au contenu principal](#main-content) # Configurer OAuth externe pour Snowflake : flux d’identifiants client L’authentification des identifiants client OAuth permet d’établir des connexions de machine à machine à Snowflake sans interaction de l’utilisateur. Cette méthode est idéale pour : - Comptes de service pour les actualisations de données automatisées - Tâches d’extraits programmées - Pipelines CI/CD - Sources de données publiées nécessitant des identifiants intégrés Contrairement à OAuth standard (qui utilise le flux de code d’autorisation), le flux d’identifiants client ne demande pas aux utilisateurs de se connecter. Tableau s’authentifie plutôt directement auprès de votre fournisseur d’identité à l’aide d’un ID client et d’un secret client. **Remarque :** Le flux d’identifiants client nécessite la fonctionnalité OAuth externe de Snowflake avec un fournisseur d’identité pris en charge. Cela diffère de l’OAuth natif de Snowflake. ## Avant de commencer Pour utiliser les identifiants client OAuth avec Snowflake, vous avez besoin des éléments suivants : | Exigence | Description | | --- | --- | | Fournisseur d’identité | Okta, Azure AD ou Ping Federate configurés pour l’octroi des identifiants client | | Compte Snowflake | Édition Enterprise ou supérieure avec accès ACCOUNTADMIN | | Application OAuth | Services API (Okta), enregistrement d’applications (Azure AD) ou équivalent | | Étendues personnalisées | Étendues pour l’attribution de rôles Snowflake (par exemple, « session:role:SYSADMIN ») | ## Configurer votre fournisseur d’identité Les étapes suivantes utilisent Okta comme exemple. Pour les autres fournisseurs, consultez leur documentation sur la configuration des identifiants client. ### Étape 1 : Créer une application de services API 1. Connectez-vous à votre console administrateur Okta. 2. Accédez à \*\***Applications** > **Applications**. 3. Sélectionnez \*\***Créer une intégration d’application**. 4. Choisissez \*\***Services API**\*\* et sélectionnez \*\***Suivant**. 5. Entrez un nom d’application (par exemple, `snowflake-tableau-service`). 6. Sélectionnez **Enregistrer**. 7. Copiez l’**ID client** et le **secret client**. Vous aurez besoin de ces valeurs ultérieurement. ### Étape 2 : Désactiver le DPoP (si activé) La démonstration de preuve de possession (DPoP) doit être désactivée pour le flux d’identifiants client. 1. Dans les paramètres de votre application, accédez à **Général** \> **Identifiants client**. 2. Décochez la case **Exiger un en-tête Démonstration de preuve de possession (DPoP) dans les demandes de jeton**. 3. Sélectionnez **Enregistrer**. ### Étape 3 : Ajouter des étendues personnalisées Snowflake exige des étendues personnalisées pour attribuer des rôles à la session authentifiée. 1. Accédez à **Sécurité** > **API** \> **Serveurs d’autorisation**. 2. Sélectionnez le serveur d’autorisation **par défaut** (ou votre serveur personnalisé). 3. Sélectionnez l’onglet **Étendues**, puis **Ajouter une étendue**. 4. Ajoutez ces étendues : | Nom de l’étendue | Description | | --- | --- | | snowflake | Étendue d’accès générale pour Snowflake | | session:role:SYSADMIN | Attribue le rôle SYSADMIN (ajustez en fonction de votre rôle) | **Remarque :** Créez des étendues supplémentaires pour tout autre rôle dont votre compte de service a besoin. ### Étape 4 : Configurer une stratégie d’accès 1. Sélectionnez l’onglet **Stratégies d’accès**. 2. Sélectionnez une stratégie existante ou créez-en une nouvelle. 3. Ajoutez une règle avec ces paramètres : - **Type d’octroi :** Identifiants client - **Étendues :** Toutes les étendues (ou sélectionner des étendues spécifiques) 4. Sélectionnez **Créer une règle** ou **Enregistrer**. ## Configurer Snowflake Exécutez les expressions SQL suivantes dans Snowflake en tant qu’ACCOUNTADMIN. Remplacez les valeurs d’espace réservé par votre configuration. ### Étape 1 : Créer l’intégration OAuth externe USE ROLE ACCOUNTADMIN; CREATE OR REPLACE SECURITY INTEGRATION okta\_oauth\_integration TYPE = EXTERNAL\_OAUTH ENABLED = TRUE EXTERNAL\_OAUTH\_TYPE = OKTA EXTERNAL\_OAUTH\_ISSUER = 'https://.okta.com/oauth2/default' EXTERNAL\_OAUTH\_JWS\_KEYS\_URL = 'https://.okta.com/oauth2/ default/v1/keys' EXTERNAL\_OAUTH\_TOKEN\_USER\_MAPPING\_CLAIM = 'sub' EXTERNAL\_OAUTH\_SNOWFLAKE\_USER\_MAPPING\_ATTRIBUTE = 'login\_name' EXTERNAL\_OAUTH\_AUDIENCE\_LIST = ('api://default', 'snowflake') EXTERNAL\_OAUTH\_ANY\_ROLE\_MODE = 'ENABLE'; | Paramètre | Description | | --- | --- | | `EXTERNAL_OAUTH_TYPE` | Votre fournisseur d’identité : `OKTA`, `AZURE` ou `PING_FEDERATE` | | `EXTERNAL_OAUTH_ISSUER` | URL de l’émetteur de votre serveur d’autorisation | | `EXTERNAL_OAUTH_JWS_KEYS_URL` | Point de terminaison JWKS pour la validation des jetons | | `EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLA IM` | Revendication du JWT qui identifie l’utilisateur. Utilisez `sub` pour Okta. | | `EXTERNAL_OAUTH_ANY_ROLE_MODE` | Définissez sur `ENABLE` pour permettre l’attribution de rôles via des étendues | ### Étape 2 : Créer un utilisateur de service Créez un utilisateur Snowflake avec un `LOGIN_NAME` qui correspond à l’ID du client OAuth. CREATE USER IF NOT EXISTS service\_account\_user LOGIN\_NAME = '' DISPLAY\_NAME = 'OAuth Service Account' MUST\_CHANGE\_PASSWORD = FALSE DISABLED = FALSE; \-- Grant role to the service user GRANT ROLE SYSADMIN TO USER service\_account\_user; \-- Set the default role ALTER USER service\_account\_user SET DEFAULT\_ROLE = 'SYSADMIN'; \-- Grant warehouse access GRANT USAGE ON WAREHOUSE TO USER service\_account\_user; \-- Grant database and schema access GRANT USAGE ON DATABASE TO USER service\_account\_user; GRANT USAGE ON SCHEMA . TO USER service\_account\_user; GRANT SELECT ON ALL TABLES IN SCHEMA . TO USER service\_account\_user; **Important :** Le `LOGIN_NAME` doit correspondre exactement à la revendication `sub` du jeton OAuth. Pour les applications des services d’API Okta, il s’agit de l’ID client. ## Se connecter depuis Tableau Desktop 1. Dans Tableau Desktop, sélectionnez **Connect** > **Snowflake**. 2. Entrez vos détails de connexion : | Champ | Valeur | | --- | --- | | Serveur | L’URL de votre compte Snowflake (p. ex., `account.snowflakecomputing.com`) | | Rôle | Rôle à utiliser (p. ex., `SYSADMIN`) | | Entrepôt | Votre entrepôt Snowflake | | Authentification | Identifiants client OAuth | 3. Entrez la configuration OAuth : | Champ | Valeur | | --- | --- | | URL de demande de jeton OAuth | `https://.okta.com/oauth2/default/ v1/token` | | Nom d’utilisateur | Votre identifiant client OAuth | | Mot de passe | Votre secret client OAuth | | Étendue OAuth | `snowflake session:role:SYSADMIN` | **Remarque :** L’étendue OAuth doit inclure toutes les étendues personnalisées que vous avez configurées pour l’attribution de rôle. 4. Sélectionnez **Se connecter**. ## Publier sur Tableau Cloud ou Tableau Server Lors de la publication d’un classeur ou d’une source de données qui utilise les identifiants client OAuth : 1. Dans la boîte de dialogue **Publier**, sélectionnez **Modifier** à côté de **Sources de données**. 2. Pour **Authentification**, sélectionnez **Mot de passe intégré**. 3. Les identifiants client sont intégrés dans le contenu publié. **Important :** Contrairement à OAuth standard, les identifiants client sont traités comme des mots de passe intégrés. Les utilisateurs qui accèdent au contenu publié utilisent les identifiants du compte de service, et non leur propre identité. ### Rotation des identifiants Lors de la rotation de votre secret client OAuth, mettez à jour les identifiants intégrés sur Tableau Cloud : 1. Connectez-vous à Tableau Cloud. 2. Accédez à la source de données publiée. 3. Sélectionnez **Connexions**. 4. Mettez à jour la connexion avec le nouveau secret client. Pour une rotation automatisée, utilisez l’API REST de Tableau pour mettre à jour les identifiants de connexion par programmation. ## Foire aux questions ### Quand dois-je utiliser les identifiants client OAuth plutôt qu’OAuth standard? Utilisez les identifiants client lorsque vous avez besoin d’une authentification de machine à machine sans interaction de l’utilisateur. Norme OAuth nécessite une interaction de l’utilisateur pour la connexion initiale et la réauthentification périodique. Les identifiants client utilisent une identité de compte de service et ne nécessitent aucune interaction de l’utilisateur. ### Puis-je utiliser les identifiants client avec l’OAuth natif de Snowflake? Non. L’OAuth natif de Snowflake prend uniquement en charge le flux de code d’autorisation. Les identifiants client nécessitent un OAuth externe avec un fournisseur d’identité pris en charge (Okta, Azure AD ou Ping Federate). ### Comment gérer la rotation des secrets pour le contenu publié? Lors de la rotation de votre secret client OAuth, vous devez mettre à jour les identifiants intégrés dans Tableau Cloud. Vous pouvez le faire manuellement dans l’interface utilisateur de Tableau Cloud ou par programmation à l’aide de l’API REST de Tableau. Envisagez d’automatiser ce processus dans le cadre de votre flux de travail de rotation des secrets. ### Pourquoi ma connexion échoue-t-elle avec une erreur de rôle alors que EXTERNAL\_OAUTH\_AY\_ROLE\_MODE est activé? Snowflake exige des informations de rôle dans le jeton OAuth. Ajoutez une étendue personnalisée (p. ex., `session:role:SYSADMIN`) à votre serveur d’autorisation et incluez-la dans le champ Étendue OAuth lors de la connexion depuis Tableau. ## Résolution des problèmes | Message d’erreur | Cause | Solution | | --- | --- | --- | | « L’utilisateur n’existe pas ou n’est pas autorisé » | L’utilisateur Snowflake `LOGIN_NAME` ne correspond pas à l’ID client OAuth | Définir le `LOGIN_NAME` de l’utilisateur de manière à ce qu’il corresponde à la revendication `sub` (ID client pour Okta) | | « Le rôle demandé n’est pas répertorié dans le jeton d’accès » | Étendue de rôle manquante dans le jeton | Ajouter l’étendue `session:role:` à votre serveur d’autorisation et l’inclure dans l’étendue OAuth | | « Preuve DPoP non valide » | La DPoP est activée dans Okta | Désactiver l’option « Exiger la démonstration de preuve de possession (DPoP) » dans votre application Okta | | « Étendue non valide » | Étendues personnalisées non configurées | Ajouter les étendues requises à votre serveur d’autorisation; ne pas inclure `openid` | | Échec de la validation du jeton | URL ou émetteur JWKS incorrect | Vérifier que `EXTERNAL_OAUTH_JWS_KEYS _URL` et `EXTERNAL_OAUTH_ISSUER` correspondent à votre serveur d’autorisation | ## Voir également - [Configurer OAuth pour les connexions Snowflake sur Tableau Server](https://help.tableau.com/current/server/fr-ca/config_oauth_snowflake.htm) - En savoir plus sur l’authentification OAuth standard avec Snowflake. - [Intégrations de sécurité OAuth externes](https://help.tableau.com/current/online/fr-ca/%3Chttps://octs.snowflake.com/fr-ca/user- guide/oauth-external-overview>) - Documentation Snowflake pour la configuration des fournisseurs OAuth externes. - [Flux d’identifiants client Okta](https://developer.okta.com/docs/guides/implement-grant-type/clientcreds/main/) - Documentation Okta sur la mise en œuvre des identifiants client. - [Mettre à jour la connexion à la source de données](https://help.tableau.com/current/api/rest_api/fr-ca/REST/rest_api_ref_data_sources.htm#update_data_source_connection) : Référence de l’API REST de Tableau pour les mises à jour des identifiants.