--- schema_version: "1" id: e9bf6ab15836552ee926551137c1fb6ecf19a29e166bdc487ebf7270d6b47d45 title: "Configuration d’OAuth externe pour Snowflake : flux d’informations d’identification client" collection: tableau version: current locale: fr-fr portal_url: https://docs.salesforce.com/tableau/current/fr-fr/server-linux/config_oauth_snowflake_client_creds.md canonical_url: https://help.tableau.com/current/server-linux/fr-fr/config_oauth_snowflake_client_creds.htm source_site: help.tableau.com content_type: documentation content_hash: 68d77d3808b9dd3963abac73a08284026532a00f574bef3c35d14d669f524417 description: Configure Azure AD OAuth and modern authentication for Azure and Microsoft connectors in Tableau Server. --- [Passer au contenu principal](#main-content) # Configuration d’OAuth externe pour Snowflake : flux d’informations d’identification client L’authentification avec les informations d’identification du client OAuth permet d’activer les connexions à Snowflake d’ordinateur à ordinateur sans interaction de l’utilisateur. Cette méthode est idéale pour : - Comptes de service pour les actualisations de données automatisées - Travaux d’extrait programmés - Pipelines CI/DC - Sources de données publiées qui nécessitent des informations d’identification intégrées À la différence d’OAuth standard (qui utilise le flux de code d’autorisation), le flux d’informations d’identification client n’invite pas les utilisateurs à se connecter. Au lieu de cela, Tableau s’authentifie directement auprès de votre fournisseur d’identité à l’aide d’un ID client et d’un secret. **Remarque :** le flux d’informations d’identification client nécessite la fonctionnalité OAuth externe de Snowflake avec un fournisseur d’identité pris en charge. Ce processus est différent de l’authentification OAuth native de Snowflake. ## Avant de commencer Pour utiliser les informations d’identification du client OAuth avec Snowflake, vous avez besoin des éléments suivants : | Exigence | Description | | --- | --- | | Fournisseur d’identité | Okta, Azure AD ou Ping Federate configuré pour l’attribution d’informations d’identification client | | Compte Snowflake | Édition Enterprise ou supérieure avec accès ACCOUNTADMIN | | Application OAuth | Services d’API (Okta), enregistrement d’application (Azure AD) ou équivalent | | Portées personnalisées | Portées pour l’attribution de rôle Snowflake (par exemple, \`session:role:SYSADMIN\` ) | ## Configurer votre fournisseur d’identité Les étapes suivantes prennent l’exemple d’Okta. Pour les autres fournisseurs, consultez leur documentation pour la configuration des informations d’identification client. ### Étape 1 : Créer une application de Services d’API 1. Connectez-vous à votre console d’administration Okta. 2. Allez à \*\***Applications** > **Applications**. 3. Sélectionnez \*\***Créer une intégration d’application**. 4. Choisissez \*\***Services d’API**\*\* puis sélectionnez \*\***Suivant**. 5. Entrez un nom d’application (par exemple, `snowflake-tableau-service`). 6. Sélectionnez **Enregistrer**. 7. Copiez le fichier **ID client** et **Secret client**. Vous aurez besoin de ces valeurs à une étape ultérieure. ### Étape 2 : Désactiver DPoP (si activé) La démonstration de la preuve de possession (DPoP) doit être désactivée pour le flux des informations d’identification client. 1. Dans les paramètres de votre application, accédez à **Général** \> **Informations d’identification client**. 2. Désélectionnez la case **Exiger l’en-tête Demonstrating Proof of Possession (DPoP) dans les requêtes de jeton**. 3. Sélectionnez **Enregistrer**. ### Étape 3 : Ajouter des portées personnalisées Snowflake exige des portées personnalisées pour attribuer des rôles à la session authentifiée. 1. Accédez à **Sécurité** > **API** \> **Serveurs d’autorisations**. 2. Sélectionnez le serveur d’autorisations **par défaut** (ou votre serveur personnalisé). 3. Sélectionnez l’onglet **Portées**, puis **Ajouter une portée**. 4. Ajoutez ces portées : | Nom de la portée | Description | | --- | --- | | snowflake | Portée 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 portées supplémentaires pour tous les autres rôles 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’attribution :** informations d’identification du client - **Portées :** toutes les portées (ou sélectionnez des portées spécifiques) 4. Sélectionnez **Créer une règle** ou **Enregistrer**. ## Configurer Snowflake Exécutez les instructions SQL suivantes dans Snowflake en tant que 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’autorisations | | `EXTERNAL_OAUTH_JWS_KEYS_URL` | Point de terminaison JWKS pour la validation de jeton | | `EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLA IM` | Revendication JWT qui identifie l’utilisateur. Utilisez `sub` pour Okta. | | `EXTERNAL_OAUTH_ANY_ROLE_MODE` | Définissez sur `ENABLE` pour autoriser l’affectation de rôles via des portées | ### Étape 2 : Créer un utilisateur de service Créez un utilisateur Snowflake avec un `LOGIN_NAME` correspondant à l’ID 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 :** `LOGIN_NAME` doit correspondre exactement à la revendication `sub` dans le jeton OAuth. Pour les applications de services d’API Okta, il s’agit de l’ID client. ## Connexion depuis Tableau Desktop 1. Dans Tableau Desktop, sélectionnez **Connexion** > **Snowflake**. 2. Entrez vos identifiants de connexion : | Champ | Valeur | | --- | --- | | Serveur | URL de votre compte Snowflake (par exemple `account.snowflakecomputing.com`) | | Rôle | Rôle à utiliser (par exemple, `SYSADMIN`) | | Entrepôt | Votre entrepôt Snowflake | | Authentification | Informations d’identification de 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 ID de client OAuth | | Mot de passe | Votre secret client OAuth | | Portée OAuth | `snowflake session:role:SYSADMIN` | **Remarque :** la portée OAuth doit inclure toutes les portées personnalisées que vous avez configurées pour l’attribution de rôle. 4. Sélectionnez **Connexion**. ## Publier sur Tableau Cloud ou Tableau Server Lors de la publication d’un classeur ou d’une source de données utilisant les informations d’identification de 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 informations d’identification du client sont intégrées dans le contenu publié. **Important :** à la différence d’OAuth standard, les informations d’identification des clients sont traitées comme des mots de passe intégrés. Les utilisateurs accédant au contenu publié utilisent les informations d’identification du compte de service, et non leur propre identité. ### Rotation des informations d’identification Lorsque votre secret client OAuth change, mettez à jour les informations d’identification intégrées 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 la rotation automatisée, utilisez l’API REST de Tableau pour mettre à jour les identifiants de connexion de manière programmée. ## Questions fréquemment posées ### Quand dois-je utiliser les informations d’identification de client OAuth au lieu d’OAuth standard ? Utilisez les informations d’identification client lorsque vous avez besoin d’une authentification sans surveillance d’ordinateur à ordinateur. Standard OAuth exige une interaction de l’utilisateur pour la connexion initiale et la réauthentification périodique. Les informations d’identification client utilisent une identité de compte de service et n’exigent pas d’interaction de l’utilisateur. ### Puis-je utiliser les informations d’identification client avec OAuth natif de Snowflake ? Non. OAuth natif de Snowflake prend uniquement en charge le flux de code d’autorisation. Les informations d’identification client exigent OAuth externe avec un fournisseur d’identité pris en charge (Okta, Azure AD ou Ping Federate). ### Comment puis-je gérer la rotation des secrets pour le contenu publié ? Lorsque votre secret client OAuth change, vous devez mettre à jour les informations d’identification intégrées dans Tableau Cloud. Vous pouvez le faire manuellement via 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 workflow de rotation des secrets. ### Pourquoi ma connexion échoue-t-elle avec une erreur de rôle alors même que EXTERNAL\_OAUTH\_ANY\_ROLE\_MODE est activé ? Snowflake exige des informations de rôle dans le jeton OAuth. Ajoutez une portée personnalisée (par exemple, `session:role:SYSADMIN`) à votre serveur d’autorisations et incluez-la dans le champ Portée 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éfinissez l’utilisateur `LOGIN_NAME` 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 » | Portée de rôle manquante dans le jeton | Ajoutez la portée `session:role:` à votre serveur d’autorisations et incluez-la dans la portée OAuth | | « Preuve DPoP non valide » | DPoP est activé dans Okta | Désactivez l’option « Exiger Demonstrating Proof of Possession (DPoP) » dans votre application Okta | | « Portée non valide » | Portées personnalisées non configurées | Ajoutez les portées requises à votre serveur d’autorisations. N’incluez pas `openid` | | Échec de la validation du jeton | Erreur d’URL ou d’émetteur JWKS | Vérifiez que `EXTERNAL_OAUTH_JWS_KEYS _URL` et `EXTERNAL_OAUTH_ISSUER` correspondent à votre serveur d’autorisations | ## À consulter également - [Configurer OAuth pour les connexions Snowflake sur Tableau Server](https://help.tableau.com/current/server-linux/fr-fr/config_oauth_snowflake.htm) - En savoir plus sur l’authentification OAuth standard avec Snowflake. - [Intégrations de sécurité OAuth externes](https://docs.snowflake.com/en/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 pour la mise en œuvre des informations d’identification des clients. - [Mettre à jour la connexion à des sources de données](https://help.tableau.com/current/api/rest_api/fr-fr/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 informations d’identification.