Utilisation de Snowflake OAuth pour les applications locales¶

Snowflake OAuth est exécutée en créant une intégration de sécurité qui définit une interface entre Snowflake en tant que serveur d’autorisation OAuth et l’application qui authentifie au nom d’un utilisateur à l’aide du flux de code d’autorisation OAuth. Snowflake OAuth est une option d’authentification forte, car l’application n’a pas besoin de stocker ou de gérer des secrets, et vous n’avez pas besoin de configurer un fournisseur d’identité tiers comme OAuth externe.

Pour simplifier la façon dont une application locale, c’est-à-dire une application de bureau, utilise Snowflake OAuth pour l’authentification, votre compte dispose d’une intégration de sécurité intégrée appelée SNOWFLAKE$LOCAL_APPLICATION. Comme l’intégration de sécurité existe déjà, si une application locale utilise un client Snowflake comme le pilote Python ou la CLI Snowflake, l’application peut authentifier auprès de Snowflake en définissant une propriété ou un paramètre du client. Aucune configuration supplémentaire n’est nécessaire. L’intégration simplifie également la configuration des applications locales qui appellent les points de terminaison OAuth directement plutôt que d’utiliser un client Snowflake.

Un administrateur peut modifier les paramètres de l’intégration SNOWFLAKE$LOCAL_APPLICATION pour ajuster son comportement, par exemple en spécifiant la durée de validité des jetons d’accès OAuth et des jetons d’actualisation.

Snowflake OAuth pour les applications locales présente les avantages supplémentaires suivants :

Contrairement à des intégrations Snowflake OAuth créées par l’utilisateur, le changement de session en cours d’exécution est pris en charge.
Il s’agit d’un remplacement simple pour les applications qui utilisent actuellement uniquement des mots de passe pour authentifier les utilisateurs. Snowflake abandonne l’utilisation des mots de passe à un seul facteur. Snowflake OAuth pour les applications locales offre donc un moyen d’utiliser une forme d’authentification plus sécurisée sans nécessiter beaucoup de configuration.

Note

L’intégration de sécurité SNOWFLAKE$LOCAL_APPLICATION est déployée au fur et à mesure sur tous les comptes. Pour déterminer si cette intégration existe dans votre compte, exécutez la commande suivante :

SHOW SECURITY INTEGRATION LIKE 'SNOWFLAKE$LOCAL_APPLICATION';

Copy

Configurer l’intégration OAuth Snowflake¶

L’intégration de sécurité SNOWFLAKE$LOCAL_APPLICATION appartient au système, mais peut être configurée par les administrateurs de sécurité (c’est-à-dire les utilisateurs disposant du rôle SECURITYADMIN dans le système).

Les administrateurs de sécurité peuvent configurer les paramètres suivants de l’intégration de sécurité :

Paramètre	Description
`ENABLED`	Contrôle si l’intégration est activée. Si l’intégration est désactivée, les applications locales doivent utiliser une méthode d’authentification différente.
`OAUTH_ISSUE_REFRESH_TOKENS`	Contrôle si le serveur d’autorisation émet des jetons d’actualisation.
`OAUTH_REFRESH_TOKEN_VALIDITY`	Définit la durée de validité des jetons d’actualisation.
`OAUTH_SINGLE_USE_REFRESH_TOKENS_REQUIRED`	Contrôle si le serveur d’autorisation émet des jetons d’actualisation à usage unique.
`OAUTH_ACCESS_TOKEN_VALIDITY`	Définit la durée de validité des jetons d’accès.

Par exemple, pour modifier l’intégration de sécurité de sorte que le serveur d’autorisation commence à émettre des jetons d’actualisation à usage unique, exécutez les commandes suivantes :

USE ROLE SECURITYADMIN;

ALTER SECURITY INTEGRATION SNOWFLAKE$LOCAL_APPLICATION
  SET OAUTH_SINGLE_USE_REFRESH_TOKENS_REQUIRED = TRUE;

Copy

Pour plus d’informations sur le réglage de ces paramètres, voir ALTER SECURITY INTEGRATION.

Contrôle de la fréquence de connexion¶

Lorsque OAUTH_ISSUE_REFRESH_TOKENS = TRUE, les applications peuvent utiliser des jetons d’actualisation pour obtenir de nouveaux jetons d’accès sans demander aux utilisateurs de se reconnecter. Les utilisateurs ne doivent se réauthentifier que lorsque le jeton d’actualisation expire après la durée spécifiée par le paramètre. OAUTH_REFRESH_TOKEN_VALIDITY.

Configuration d’une application locale pour utiliser Snowflake OAuth¶

Cette section fournit les détails dont un développeur a besoin pour configurer une application locale afin de s’authentifier auprès de Snowflake OAuth. Les types d’applications locales suivants peuvent s’authentifier à l’aide de l’intégration :

Une application locale qui utilise un client Snowflake comme le pilote Python ou la CLI Snowflake. Voir Applications qui utilisent un client Snowflake.
Une application locale qui envoie directement des requêtes REST au point de terminaison d’autorisation OAuth et au point de terminaison de jeton, sans utiliser de client Snowflake. Voir Applications qui appellent directement les points de terminaison OAuth.

Applications qui utilisent un client Snowflake¶

Lorsqu’une application locale utilise un client Snowflake comme le pilote ODBC de Snowflake, elle peut s’authentifier à l’aide de Snowflake OAuth en définissant l’option de connexion authenticator sur oauth_authorization_code. Aucun développement supplémentaire n’est nécessaire.

Conditions préalables¶

Avec Snowflake OAuth pour les applications locales, le client Snowflake doit pouvoir ouvrir le navigateur Web de l’utilisateur. Pour cette raison, le client Snowflake et l’application locale qui l’utilise doivent être installés sur le poste de l’utilisateur. Snowflake OAuth pour les applications locales ne fonctionne pas si le client Snowflake est utilisé par du code qui s’exécute sur un serveur.

Clients pris en charge¶

Votre application locale peut utiliser les clients Snowflake suivants pour s’authentifier auprès de Snowflake OAuth pour les applications locales :

Client	Version minimale requise	Configuration requise
.NET	v4.8.0	Définissez `authenticator=oauth_authorization_code` dans la chaîne de connexion.
Go	v1.14.1	Définissez `authenticator=oauth_authorization_code` dans la configuration de connexion.
JDBC	v3.24.1	Définissez `authenticator=oauth_authorization_code` dans la chaîne de connexion du pilote.
Node.js	v2.1.0	Définissez `authenticator: 'oauth_authorization_code'` dans les options de connexion.
ODBC	v3.9.0	Pour Linux et macOS, définissez `authenticator=oauth_authorization_code` dans le fichier `odbc.ini`. Pour Windows, dans l’outil Administrateur de la source de données ODBC, modifiez le DSN de Snowflake et définissez l’authentificateur sur `oauth_authorization_code`.
Python	v3.16.0	Validez `AUTHENTICATOR=OAUTH_AUTHORIZATION_CODE` dans la fonction `snowflake.connector.connect()`.
Snowflake CLI	v3.8.1	Ajoutez l’option `authenticator = "OAUTH_AUTHORIZATION_CODE"` à la définition de la connexion.
SnowSQL	v1.4.0	Ajoutez le paramètre `authenticator = "OAUTH_AUTHORIZATION_CODE"` dans le fichier de configuration.

Applications qui appellent directement les points de terminaison OAuth¶

Votre application locale peut utiliser Snowflake OAuth en adressant des requêtes au point de terminaison d’autorisation et au point de terminaison du jeton de Snowflake en tant que serveur d’autorisation. Vous n’avez pas besoin d’utiliser un client Snowflake. L’application envoie une requête au point de terminaison d’autorisation de Snowflake pour authentifier l’utilisateur et recevoir un code d’autorisation, puis envoie une requête au point de terminaison du jeton pour échanger ce code contre un jeton d’accès.

Pour plus d’informations sur la création de requêtes REST vers les points de terminaison d’autorisation et de jeton de Snowflake, voir Appel des points de terminaison OAuth.

Exigences relatives aux requêtes¶

Les requêtes REST de votre application vers les points de terminaison d’autorisation et de jeton doivent être conformes aux exigences suivantes :

L’URL de redirection dans la requête vers le point de terminaison d’autorisation doit être http://127.0.0.1[:port][/path]. C’est-à-dire que votre application locale doit être à l’écoute sur une adresse de boucle pour le code d’autorisation renvoyé par Snowflake en tant que serveur d’autorisation.
Les demandes vers les points de terminaison d’autorisation et de jeton doivent mettre en œuvre la clé de preuve pour l’échange de code (PKCE). Pour plus d’informations, voir Clé de preuve pour l’échange de code.
Lorsque vous appelez le point de terminaison du jeton pour échanger un code d’autorisation contre un jeton d’accès, l’application doit fournir l’ID du client approprié et le secret du client. Cette exigence varie légèrement en fonction de la manière dont vous envoyez ces identifiants de connexion client :
- Si vous envoyez les identifiants de connexion client dans l’en-tête de la requête, l’ID du client doit être LOCAL_APPLICATION et le secret du client doit être LOCAL_APPLICATION.
- Si vous envoyez les identifiants de connexion client dans le corps du POST, l’ID client doit être LOCAL_APPLICATION. L’intégration configure l’application locale comme client public, donc le secret du client n’est pas nécessaire si vous fournissez l’ID du client en tant que client_id=LOCAL_APPLICATION dans le corps du POST.

Notes sur l’utilisation¶

Chaque compte dispose d’une intégration SNOWFLAKE$LOCAL_APPLICATION, donc cette intégration n’est pas répliquée. La configuration de l’intégration est unique pour chaque compte.