Introduction à OAuth¶

Snowflake prend en charge le protocole OAuth 2.0 pour l’authentification et l’autorisation. OAuth est un protocole à norme ouverte qui permet aux clients pris en charge d’avoir un accès autorisé à Snowflake sans partage ni stockage d’informations de connexion de l’utilisateur. Ceci est appelé autorisation déléguée, car un utilisateur autorise le client à agir en son nom pour récupérer ses données. Snowflake propose deux voies OAuth : OAuth Snowflake et OAuth externe.

Snowflake OAuth utilise le service OAuth intégré de Snowflake et prend en charge les applications suivantes :

OAuth externe intègre le serveur OAuth 2.0 d’un client et prend en charge trois options de serveur d’autorisation, des clients personnalisés et deux applications partenaires.

Le tableau suivant compare Snowflake OAuth et OAuth externe.

Catégorie	Snowflake OAuth	OAuth externe
Modifier l’application cliente	Obligatoire	Obligatoire
Accès au navigateur de l’application cliente	Obligatoire	Non requis
Clients automatiques	Nécessite un navigateur	Meilleure correspondance
Propriété du pilote	`authenticator = oauth`	`authenticator = oauth`
Syntaxe de l’intégration de sécurité	`create security integration type = oauth ...`	`create security integration type = external_oauth`
Flux OAuth	Flux d’accord de code OAuth 2.0	Tout flux OAuth que le client peut initier avec le serveur externe OAuth

Snowflake active OAuth pour les clients à l’aide d”intégrations. Une intégration est un objet Snowflake qui fournit une interface entre Snowflake et des services tiers. Les administrateurs configurent OAuth à l’aide d’une intégration de sécurité, d’un type d’intégration permettant aux clients prenant en charge OAuth de rediriger les utilisateurs vers une page d’autorisation et de générer des jetons d’accès (et éventuellement, des jetons d’actualisation) pour accéder à Snowflake.

Dans ce chapitre :

Concepts OAuth¶

Serveur d’autorisation¶

Ce serveur affiche une interface permettant à un utilisateur d’approuver ou de refuser l’accès des clients à leurs données. Le serveur envoie un jeton d’accès au client après l’authentification réussie de l’utilisateur et la validation d’une demande d’autorisation.

Jeton d’accès¶

Une chaîne qui représente l’autorisation accordée à un client par un utilisateur d’accéder à leurs données en utilisant un rôle spécifié. Ces jetons expirent après une courte période ; un mécanisme d’actualisation peut être utilisé pour obtenir de nouveaux jetons d’accès.

Jeton d’actualisation¶

Chaîne utilisée pour obtenir un nouveau jeton d’accès lorsqu’il expire. Un jeton d’actualisation est éventuellement émis par le serveur d’autorisation au client avec un jeton d’accès. Le client peut utiliser le jeton d’actualisation pour demander un autre jeton d’accès, évitant ainsi la réimplication de l’utilisateur jusqu’à l’expiration du jeton d’actualisation. À ce stade, le workflow OAuth est à nouveau appelé.

Serveur de ressources¶

Ce serveur protège la ressource (c’est-à-dire Snowflake) et gère les demandes d’accès à la ressource à l’aide de jetons d’accès.

Clients confidentiels et publics¶

Les clients confidentiels peuvent stocker un secret. Ils fonctionnent dans une zone protégée à laquelle les utilisateurs finaux ne peuvent pas accéder. Par exemple, un service sécurisé déployé sur le Cloud peut être un client confidentiel. Un client fonctionnant sur un ordinateur de bureau ou distribué via un magasin d’applications peut être un client public.

Pour les clients publics, l’utilisateur doit entrer son nom d’utilisateur et son mot de passe Snowflake avant d’autoriser l’accès client à Snowflake à l’aide du rôle spécifié. Pour les clients confidentiels, l’utilisateur n’a besoin d’entrer ses informations d’identification qu’une seule fois pour le rôle spécifié.

Snowflake prend en charge OAuth pour les clients confidentiels et publics.

Flux d’autorisation OAuth de Snowflake¶

Le flux d’autorisation OAuth est le suivant :

Dans le client, l’utilisateur tente de se connecter à Snowflake en utilisant OAuth.

L’application envoie une demande d’autorisation au serveur d’autorisation Snowflake, qui affiche à son tour un écran d’autorisation demandant à l’utilisateur d’autoriser l’accès.
L’utilisateur soumet le nom d’utilisateur et le mot de passe Snowflake. Un écran de consentement lui est alors présenté pour permettre au client d’accéder à Snowflake en utilisant un rôle spécifique dans une session utilisateur (par exemple SYSADMIN ou CUSTOM_ROLE1).

L’utilisateur soumet son consentement à utiliser le rôle spécifique dans une session.

Le serveur d’autorisation Snowflake renvoie un code d’autorisation au client.
Le client renvoie le code d’autorisation au serveur d’autorisation Snowflake pour demander un jeton d’accès et, éventuellement, un jeton d’actualisation permettant au client d’obtenir de nouveaux jetons d’accès.

Le serveur d’autorisation Snowflake accepte le code d’autorisation et fournit au client un jeton d’accès spécifique aux ressources utilisateur du serveur de ressources Snowflake. En fonction des paramètres de la demande d’autorisation, le serveur d’autorisation émet un jeton d’actualisation pour obtenir de nouveaux jetons d’accès liés à la ressource spécifique.
Le client envoie le jeton d’accès au serveur de ressources Snowflake.

Le serveur de ressources reconnaît le jeton d’accès valide et crée une session utilisateur avec le rôle autorisé. Le client a maintenant accès aux ressources Snowflake limitées par le rôle spécifié par le jeton d’accès.

Les jetons d’accès ont une vie courte ; en général 10 minutes. Lorsque le jeton d’accès arrive à expiration, le client peut envoyer un jeton d’actualisation pour obtenir de nouveaux jetons d’accès. Un jeton d’actualisation est envoyé au serveur d’autorisation Snowflake pour demander un nouveau jeton d’accès à chaque expiration du jeton d’accès actuel (étapes 3 à 6). Si l’intégration est configurée pour empêcher l’envoi de jetons d’actualisation, l’utilisateur doit répéter les étapes ci-dessus pour réautoriser le client.

Configuration de la prise en charge OAuth¶

Applications partenaires OAuth Snowflake¶

Pour configurer la prise en charge, voir Configurer Snowflake OAuth pour les applications partenaires.

Pour savoir comment utiliser OAuth sans passer par l’Internet public, voir OAuth et connectivité privée.

Clients personnalisés OAuth Snowflake¶

Snowflake prend en charge les clients personnalisés configurés par votre organisation. Pour configurer la prise en charge, voir Configurer Snowflake OAuth pour les clients personnalisés.

Applications partenaires OAuth externes¶

Pour configurer les applications partenaires externes OAuth, voir Applications partenaires OAuth externes.

Clients personnalisés OAuth externes¶

Snowflake prend en charge les clients personnalisés OAuth externes configurés par votre organisation. Pour configurer la prise en charge, voir Configurer des clients personnalisés pour OAuth externe.

Audit des connexions OAuth¶

Pour interroger les tentatives de connexion des utilisateurs de Snowflake, Snowflake fournit un historique de connexion :

LOGIN_HISTORY , LOGIN_HISTORY_BY_USER (fonction de table)
Vue LOGIN_HISTORY (vue)

Lorsque OAuth est utilisé pour s’authentifier (avec succès ou non), la colonne FIRST_AUTHENTICATION_FACTOR de la sortie a la valeur OAUTH_ACCESS_TOKEN.

DDL d’intégration¶

Pour prendre en charge la création et/ou la gestion des intégrations et des autorisations déléguées, Snowflake fournit l’ensemble suivant de commandes DDL spéciales :

OAuth et authentification fédérée¶

Snowflake prend en charge OAuth avec Authentification fédérée et SSO (connexion unique) à l’aide de tout fournisseur d’identité (IdP) pris en charge par Snowflake.

Avec l’authentification fédérée configurée, le flux d’autorisation est le suivant :

Dans le client, l’utilisateur tente de se connecter à Snowflake.

L’application envoie une demande d’autorisation au serveur d’autorisation Snowflake, qui affiche à son tour un écran d’autorisation demandant à l’utilisateur d’autoriser l’accès.
L’utilisateur clique sur l’option permettant de se connecter à l’aide d’IdP et est redirigé vers la page d’authentification IdP.
L’utilisateur soumet le nom d’utilisateur et le mot de passe de l’IdP. Un écran de consentement lui est alors présenté pour permettre au client d’accéder à Snowflake en utilisant un rôle spécifique dans une session utilisateur (par exemple : SYSADMIN ou CUSTOM_ROLE1).

L’utilisateur soumet son consentement à utiliser le rôle spécifique dans une session.

Le serveur d’autorisation Snowflake renvoie un code d’autorisation au client.
Le client renvoie le code d’autorisation au serveur d’autorisation Snowflake pour demander un jeton d’accès et, éventuellement, un jeton d’actualisation permettant au client d’obtenir de nouveaux jetons d’accès.

Le serveur d’autorisation Snowflake accepte le code d’autorisation et fournit au client un jeton d’accès spécifique aux ressources utilisateur du serveur de ressources Snowflake. En fonction des paramètres de la demande d’autorisation, le serveur d’autorisation émet un jeton d’actualisation pour obtenir de nouveaux jetons d’accès liés à la ressource spécifique.
Le client envoie le jeton d’accès au serveur de ressources Snowflake.

Le serveur de ressources reconnaît le jeton d’accès valide et crée une session utilisateur avec le rôle autorisé. Le client a maintenant accès aux ressources Snowflake limitées par le rôle spécifié par le jeton d’accès.

OAuth et connectivité privée¶

Snowflake prend en charge OAuth externe avec Connectivité privée au service Snowflake.

OAuth Snowflake et Tableau peuvent être utilisés avec une connectivité privée à Snowflake comme suit :

Tableau Desktop

À partir de Tableau 2020.4, Tableau contient un client OAuth intégré qui prend en charge la connexion à Snowflake avec l’URL du compte pour Connectivité privée au service Snowflake.

Après la mise à niveau vers Tableau 2020.4, aucune autre configuration n’est nécessaire ; utilisez l’URL de connectivité correspondante pour AWS ou Azure afin de vous connecter à Snowflake.

Tableau Server

À partir de Tableau 2020.4, les utilisateurs peuvent éventuellement configurer Tableau Server pour utiliser le client OAuth intégré afin de se connecter à Snowflake avec l’URL du compte pour Connectivité privée au service Snowflake.

Pour utiliser cette fonctionnalité, créez une nouvelle intégration de sécurité Client personnalisé et suivez les instructions de Tableau.

Tableau Online

Tableau Online ne prend pas en charge l’URL du compte Snowflake pour Connectivité privée au service Snowflake car Tableau Online nécessite un accès à l’Internet public.

Veuillez contacter Tableau pour plus d’informations concernant le moment où Tableau Online prendra en charge les URLs de compte Snowflake de connectivité privée pour Connectivité privée au service Snowflake.

Important

Pour déterminer l’URL de compte à utiliser avec Connectivité privée au service Snowflake, appelez la fonction SYSTEM$GET_PRIVATELINK_CONFIG.

Looker

Actuellement, la combinaison de Snowflake OAuth et Looker nécessite l’accès à l’Internet public. Par conséquent, vous ne pouvez pas utiliser OAuth Snowflake et Looker avec Connectivité privée au service Snowflake.

Pour plus d’informations, voir :

OAuth et politiques réseau¶

Vous pouvez utiliser des politiques réseau avec Snowflake OAuth uniquement. L’intégration de sécurité OAuth externe ne prend pas en charge la définition d’une politique réseau distincte.

L’intégration de sécurité OAuth de Snowflake possède un paramètre network_policy afin que l’intégration OAuth de Snowflake puisse authentifier et autoriser les utilisateurs sans ajouter ces adresses IP pour un accès utilisateur normal.

La configuration d’une politique réseau spécifique à l’intégration OAuth de Snowflake permet à la politique réseau OAuth de Snowflake d’être distincte des autres politiques réseau qui peuvent s’appliquer au compte Snowflake. La politique réseau OAuth de Snowflake n’affecte pas les autres politiques réseau du compte et les autres politiques réseau du compte n’affectent pas la politique réseau OAuth de Snowflake. Par conséquent, la politique réseau OAuth de Snowflake permet l’authentification et l’autorisation des utilisateurs comme prévu.

Important

Si une politique réseau par utilisateur ou compte est définie et que vous utilisez un service qui s’exécute dans un emplacement différent (par exemple, le service Microsoft Power BI), vous ne pourrez pas vous connecter à Snowflake.

Après avoir créé l’intégration de sécurité OAuth de Snowflake, définissez la politique réseau OAuth à l’aide de cette commande :

alter security integration <intégration_oauth> set network_policy = <politique_réseau_oauth>;

Pour annuler la politique réseau OAuth de Snowflake, utilisez cette commande :

alter security integration <intégration_oauth> unset <politique_réseau_oauth>;

Où :

<oauth_integration>: Spécifie le nom de l’intégration de sécurité OAuth de Snowflake.
<oauth_network_policy>: Spécifie la politique réseau OAuth de Snowflake dans Snowflake.

Pour plus d’informations, voir Politiques réseau et ALTER SECURITY INTEGRATION.

OAuth et rôles secondaires¶

Snowflake prend en charge l’utilisation de rôles secondaires avec External Oauth.

Pour plus d’informations, voir Utilisation de rôles secondaires avec External OAuth.

Notez que le changement de rôle en cours de session vers des rôles secondaires avec Snowflake OAuth n’est pas pris en charge.

OAuth avec les clients, les pilotes et les connecteurs¶

Les clients, pilotes et connecteurs pris en charge peuvent utiliser OAuth pour vérifier les informations de connexion de l’utilisateur.

Remarques :

Il est nécessaire de définir le paramètre authenticator sur oauth et le paramètre token sur oauth_access_token.
Lors du passage de la valeur token en tant que paramètre de requête URL, il est nécessaire d’encoder en URL la valeur oauth_access_token.
Lors du passage de la valeur token à un objet Propriétés (par exemple, pilote JDBC), aucune modification n’est nécessaire.

Pour plus d’informations, consultez les paramètres de connexion pour chaque client, pilote ou connecteur.

OAuth et redirection des clients¶

Snowflake prend en charge l’utilisation de la redirection des clients avec Snowflake OAuth et External OAuth, y compris l’utilisation de la redirection des clients et OAuth avec les clients Snowflake pris en charge.

Pour plus d’informations, voir Rediriger les connexions du client.

Codes d’erreur OAuth¶

Voici les codes d’erreur associés à OAuth qui peuvent être renvoyés au cours du flux d’autorisation, de l’échange de jetons ou de la création d’une session Snowflake après avoir terminé le flux OAuth :

Code d’erreur	Erreur	Description
390302	OAUTH_CONSENT_INVALID	Problème générant ou validant le consentement pour un utilisateur donné.
390303	OAUTH_ACCESS_TOKEN_INVALID	Le jeton d’accès fourni utilisé lors de la tentative de création d’une session Snowflake est arrivé à expiration ou n’est pas valide.
390304	OAUTH_AUTHORIZE_INVALID_RESPONSE_TYPE	Un `response_type` non valide a été fourni en tant que paramètre du point de terminaison d’autorisation (il devrait très probablement s’agir d’un `code`)
390305	OAUTH_AUTHORIZE_INVALID_STATE_LENGTH	Le paramètre d’état fourni en tant que paramètre du point de terminaison d’autorisation dépasse 2 048 caractères.
390306	OAUTH_AUTHORIZE_INVALID_CLIENT_ID	L’intégration associée à un identifiant client fourni n’existe pas.
390307	OAUTH_AUTHORIZE_INVALID_REDIRECT_URI	`redirect_uri` donné en tant que paramètre de point de terminaison d’autorisation ne correspond pas à `redirect_uri` de l’intégration associée à `client_id` fourni ou `redirect_uri` n’est pas formaté correctement.
390308	OAUTH_AUTHORIZE_INVALID_SCOPE	Soit la portée demandée n’est pas une portée valide, soit les portées demandées ne peuvent pas être entièrement accordées à l’utilisateur.
390309	OAUTH_USERNAMES_MISMATCH	L’utilisateur que vous avez essayé d’authentifier diffère de l’utilisateur lié au jeton d’accès.
390311	OAUTH_AUTHORIZE_INVALID_CODE_CHALLENGE_PARAMS	Le défi de code ou la méthode de défi de code est manquant, non valide, ou non pris en charge.
390318	OAUTH_ACCESS_TOKEN_EXPIRED	Le jeton d’accès OAuth a expiré. {0}
390144	JWT_TOKEN_INVALID	Le jeton JWT n’est pas valide.

De plus, les erreurs suivantes proviennent du RFC et sont renvoyées dans le blob JSON créé lors d’une demande ou d’un échange de jetons infructueux :

Erreur	Description
invalid_client	Une erreur d’authentification du client est survenue. Le client est inconnu, le secret du client ne correspond pas, etc.
invalid_grant	L’octroi d’autorisation ou le jeton d’actualisation fourni n’est pas valide, a expiré, a été révoqué, ne correspond pas à l’URI de redirection utilisée dans la demande d’autorisation ou a été émis vers un autre client.
unsupported_grant_type	Un type d’octroi fourni actuellement n’est pas pris en charge par Snowflake (« jeton_actualisation » et « code_autorisation » sont les deux seuls types d’octrois pris en charge pour le moment).
invalid_request	La requête était mal formée ou n’a pas pu être traitée.