Configurer Snowflake OAuth pour les clients personnalisés

Ce chapitre décrit comment configurer la prise en charge de OAuth pour les clients personnalisés.

Dans ce chapitre :

Workflow

Les étapes de haut niveau suivantes sont requises pour configurer OAuth pour les clients personnalisés :

  1. Enregistrez votre client avec Snowflake. Pour enregistrer votre client, créez une intégration. Une intégration est un objet Snowflake qui fournit une interface entre Snowflake et des services tiers, tels qu’un client prenant en charge OAuth.

    Le processus d’inscription définit un ID de client et des secrets de client.

  2. Configurez les appels aux points de terminaison OAuth de Snowflake pour demander des codes d’autorisation au serveur d’autorisation de Snowflake, ainsi que pour demander et actualiser des jetons d’accès.

    Les paramètres facultatifs « scope » de la demande d’autorisation initiale limitent le rôle autorisé par le jeton d’accès et peuvent également être utilisés pour configurer le comportement du jeton d’actualisation.

Étape 1 : Créer une intégration OAuth

Créez une intégration à l’aide de la commande CREATE SECURITY INTEGRATION.

Note

Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) ou un rôle disposant du privilège global CREATE INTEGRATION peuvent exécuter cette commande SQL.

Blocage de rôles spécifiques lors de l’utilisation de l’intégration

Le paramètre BLOCKED_ROLES_LIST facultatif vous permet de répertorier les rôles Snowflake qu’un utilisateur ne peut pas consentir explicitement d’utiliser avec l’intégration.

Par défaut, les rôles d’administrateur de compte (ACCOUNTADMIN) et d’administrateur de sécurité (SECURITYADMIN) sont inclus dans cette liste et ne peuvent pas être supprimés. Si votre entreprise a besoin d’autoriser des utilisateurs à utiliser OAuth avec ces rôles et que votre équipe de sécurité est à l’aise pour le permettre, contactez le support de Snowflake pour demander que ces rôles soient autorisés pour votre compte.

Gestion des politiques réseau

Snowflake prend en charge les politiques réseau pour OAuth. Pour plus d’informations, voir OAuth et politiques réseau.

Exemple d’intégration

L’exemple suivant crée une intégration OAuth qui utilise l’authentification par paire de clés. L’intégration permet d’actualiser les jetons, qui expirent après 1 jour (86 400 secondes). L’intégration empêche les utilisateurs de démarrer une session avec SYSADMIN comme rôle actif :

CREATE SECURITY INTEGRATION oauth_kp_int
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'http://localhost.com'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 86400
  BLOCKED_ROLES_LIST = ('SYSADMIN')
  OAUTH_CLIENT_RSA_PUBLIC_KEY ='
  MIIBI
  ..
  ';

Étape 2 : Appeler les points de terminaison OAuth

Les points de terminaison OAuth sont les URLs que les clients appellent pour demander des codes d’autorisation et pour demander et actualiser des jetons d’accès. Ces points de terminaison font référence à des règles spécifiques OAuth 2.0 qui s’exécutent lorsque le point de terminaison est appelé.

Snowflake fournit les points de terminaison OAuth suivants :

Autorisation

https://<nom_compte>.snowflakecomputing.com/oauth/authorize

Demandes de jetons

https://<nom_compte>.snowflakecomputing.com/oauth/token-request

Pour des raisons pratiques, Snowflake définit les points de terminaison lorsqu’un client est enregistré. Pour voir les points de terminaison de votre intégration, exécutez DESCRIBE INTEGRATION.

Par exemple, l’exemple suivant renvoie les points de terminaison pour l’intégration créée dans Étape 1 : Créer une intégration OAuth (dans cette rubrique) :

DESC SECURITY INTEGRATION oauth_kp_int;

+----------------------------------+---------------+----------------------------------------------------------------------+------------------+
| property                         | property_type | property_value                                                       | property_default |
|----------------------------------+---------------+----------------------------------------------------------------------+------------------|
...
| OAUTH_AUTHORIZATION_ENDPOINT     | String        | https://myaccount.snowflakecomputing.com/oauth/authorize             |                  |
| OAUTH_TOKEN_ENDPOINT             | String        | https://myaccount.snowflakecomputing.com/oauth/token-request         |                  |
...
+----------------------------------+---------------+----------------------------------------------------------------------+------------------+

Point de terminaison d’autorisation

Le point de terminaison d’autorisation est utilisé pour obtenir une autorisation après qu’un utilisateur a correctement autorisé un client avec Snowflake. Le point de terminaison d’autorisation est le suivant :

https://<account_name>.snowflakecomputing.com/oauth/authorize

Où :

<nom_compte>

Spécifie le nom complet de votre compte (fourni par Snowflake).

Notez que votre nom de compte complet peut inclure des segments supplémentaires identifiant la région et la plate-forme Cloud où votre compte est hébergé.

Exemples de noms de compte par région

Si votre nom de compte est xy12345 :

Plate-forme Cloud/Région

Nom de compte complet

AWS

US Ouest (Oregon)

xy12345

US Est (Ohio)

xy12345.us-east-2.aws

US Est (Virginie du Nord)

xy12345.us-east-1

US Est (Gouvernement commercial - Virginie du Nord)

xy12345.us-east-1-gov.aws

Canada (Centre)

xy12345.ca-central-1.aws

EU (Irlande)

xy12345.eu-west-1

EU (Francfort)

xy12345.eu-central-1

Asie-Pacifique (Tokyo)

xy12345.ap-northeast-1.aws

Asie Pacifique (Mumbai)

xy12345.ap-south-1.aws

Asie-Pacifique (Singapour)

xy12345.ap-southeast-1

Asie-Pacifique (Sydney)

xy12345.ap-southeast-2

GCP

US Central1 (Iowa)

xy12345.us-central1.gcp

Europe Ouest2 (Londres)

xy12345.europe-west2.gcp

Europe Ouest4 (Pays-Bas)

xy12345.europe-west4.gcp

Azure

Ouest US 2 (Washington)

xy12345.west-us-2.azure

Est US 2 (Virginie)

xy12345.east-us-2.azure

US Gov Virginia

xy12345.us-gov-virginia.azure

Canada Central (Toronto)

xy12345.canada-central.azure

Europe de l’Ouest (Pays-Bas)

xy12345.west-europe.azure

Suisse Nord (Zurich)

xy12345.switzerland-north.azure

Asie du Sud-Est (Singapour)

xy12345.southeast-asia.azure

Australie Est (Nouvelle-Galles du Sud)

xy12345.australia-east.azure

Important

Si l’une des conditions suivantes est remplie, le nom de votre compte est différent de la structure décrite dans cet exemple :

  • Si votre édition Snowflake est VPS, contactez le support Snowflake pour obtenir des détails sur le nom de votre compte.

  • Si AWS PrivateLink est activé pour votre compte, le nom de votre compte nécessite un segment privatelink supplémentaire. Pour plus de détails, voir AWS PrivateLink et Snowflake.

method

GET

Important

Le point de terminaison d’autorisation doit être ouvert dans un navigateur avec lequel l’utilisateur peut interagir. N’utilisez pas cURL avec ce point de terminaison.

query parameters

Note

Les paramètres suivants doivent être une URL chiffrée.

Paramètre

Type de données

Obligatoire

Description

client_id

Chaîne

Oui

ID client (fourni par Snowflake lors de l’enregistrement du client)

response_type

Chaîne

Oui

Type de réponse créé. Prend actuellement en charge la valeur code, car Snowflake n’émet que des codes d’autorisation.

redirect_uri

Chaîne

Oui

URI où l’utilisateur est redirigé après une autorisation réussie. Doit correspondre à la valeur enregistrée avec Snowflake lors de l’enregistrement du client.

state

Chaîne

Non

Chaîne de 2 048 caractères ASCII maximum renvoyée avec la réponse du serveur d’autorisation Snowflake. Généralement utilisée pour empêcher les attaques de falsification de requêtes entre sites.

scope

Chaîne

Non

Chaîne délimitée par des espaces utilisée pour limiter la portée de la demande d’accès. Pour plus d’informations, voir Portée dans ce chapitre.

code_challenge

Chaîne

Non

Défi pour clé de vérification pour échange de code (PKCE). Chaîne générée via une méthode secrète et un défi de code. Pour plus d’informations, voir Clé de preuve pour échange de code (dans ce chapitre).

code_challenge_method

Chaîne

Non

Chaîne indiquant la méthode utilisée pour dériver le défi de code pour PKCE. Pour plus d’informations, voir Clé de preuve pour échange de code (dans ce chapitre).

Lorsqu’un utilisateur autorise le client, une redirection vers redirect_uri contenant les éléments suivants dans une requête GET est effectuée :

Paramètre

Description

code

Code d’autorisation de courte durée, qui peut être échangé sur le point de terminaison du jeton contre un jeton d’accès

state

Valeur state fournie dans la demande d’origine, non modifiée.

scope

Portée de la demande d’accès ; identique à la valeur scope dans la demande d’autorisation initiale, mais peut différer à l’avenir. Pour plus d’informations, voir Portée (dans ce chapitre).

Portée

Les paramètres de portée de la demande d’autorisation initiale limitent éventuellement les opérations et le rôle autorisés par le jeton d’accès.

La portée est validée immédiatement lors d’une demande d’autorisation concernant la sémantique, mais pas nécessairement la validité. Autrement dit, toute portée non valide (par exemple, « bogus_scope ») sera refusée avant l’authentification de l’utilisateur, mais une portée à laquelle l’utilisateur n’a pas accès (un rôle particulier, etc.) ne provoquera une erreur qu’après son authentification. Les paramètres de portée valides sont les suivants :

query parameters

Paramètre

Obligatoire

Description

refresh_token

Non

S’il est inclus dans l’URL d’autorisation, Snowflake offre à l’utilisateur la possibilité de consentir à un accès hors connexion. Dans ce contexte, l’accès hors connexion consiste à autoriser le client à actualiser les jetons d’accès lorsque l’utilisateur n’est pas présent. Avec le consentement de l’utilisateur, le serveur d’autorisation renvoie un jeton d’actualisation en plus d’un jeton d’accès lors de l’utilisation du code d’autorisation.

session:role:nom_rôle

Non

Utilisé pour limiter le jeton d’accès à un rôle unique auquel l’utilisateur peut consentir pour la session. Une seule portée pour un rôle de session peut être spécifiée. Si cette portée est omise, le rôle par défaut de l’utilisateur est utilisé à la place. Lorsqu’un utilisateur autorise le consentement, Snowflake affiche toujours le rôle de la session, que cette portée soit incluse dans l’URL d’autorisation ou non. . Notez que nom_rôle est sensible à la casse et doit être entré en majuscules à moins que le nom du rôle ne soit placé entre guillemets lors de sa création à l’aide de CREATE ROLE. Pour vérifier la casse, exécutez SHOW ROLES dans Snowflake et consultez le nom du rôle dans le résultat.

Ajoutez des paramètres de portée à l’URL d’autorisation.

L’exemple suivant limite l’autorisation au rôle R1 personnalisé :

scope=session:role:R1

L’exemple suivant indique que les jetons d’accès/d’actualisation doivent utiliser le rôle par défaut pour l’utilisateur et demande un jeton d’actualisation pour permettre l’accès en mode déconnecté :

scope=refresh_token

L’exemple suivant limite l’autorisation au rôle R1 personnalisé et demande un jeton d’actualisation afin que l’accès en mode déconnecté puisse avoir lieu :

scope=refresh_token session:role:SYSADMIN

Point de terminaison du jeton

Ce point de terminaison renvoie des jetons d’accès ou des jetons d’actualisation en fonction des paramètres de la demande. Le point de terminaison du jeton est le suivant :

https://<account_name>.snowflakecomputing.com/oauth/token-request

Où :

<nom_compte>

Spécifie le nom complet de votre compte (fourni par Snowflake).

Notez que votre nom de compte complet peut inclure des segments supplémentaires identifiant la région et la plate-forme Cloud où votre compte est hébergé.

Exemples de noms de compte pour les plates-formes et les régions Cloud

Si votre nom de compte est xy12345 :

Plate-forme Cloud/Région

Nom de compte complet

AWS

US Ouest (Oregon)

xy12345

US Est (Ohio)

xy12345.us-east-2.aws

US Est (Virginie du Nord)

xy12345.us-east-1

US Est (Gouvernement commercial - Virginie du Nord)

xy12345.us-east-1-gov.aws

Canada (Centre)

xy12345.ca-central-1.aws

EU (Irlande)

xy12345.eu-west-1

EU (Francfort)

xy12345.eu-central-1

Asie-Pacifique (Tokyo)

xy12345.ap-northeast-1.aws

Asie Pacifique (Mumbai)

xy12345.ap-south-1.aws

Asie-Pacifique (Singapour)

xy12345.ap-southeast-1

Asie-Pacifique (Sydney)

xy12345.ap-southeast-2

GCP

US Central1 (Iowa)

xy12345.us-central1.gcp

Europe Ouest2 (Londres)

xy12345.europe-west2.gcp

Europe Ouest4 (Pays-Bas)

xy12345.europe-west4.gcp

Azure

Ouest US 2 (Washington)

xy12345.west-us-2.azure

Est US 2 (Virginie)

xy12345.east-us-2.azure

US Gov Virginia

xy12345.us-gov-virginia.azure

Canada Central (Toronto)

xy12345.canada-central.azure

Europe de l’Ouest (Pays-Bas)

xy12345.west-europe.azure

Suisse Nord (Zurich)

xy12345.switzerland-north.azure

Asie du Sud-Est (Singapour)

xy12345.southeast-asia.azure

Australie Est (Nouvelle-Galles du Sud)

xy12345.australia-east.azure

Important

Si l’une des conditions suivantes est remplie, le nom de votre compte est différent de la structure décrite dans cet exemple :

  • Si votre édition Snowflake est VPS, contactez le support Snowflake pour obtenir des détails sur le nom de votre compte.

  • Si AWS PrivateLink est activé pour votre compte, le nom de votre compte nécessite un segment privatelink supplémentaire. Pour plus de détails, voir AWS PrivateLink et Snowflake.

method

POST

query parameters

Paramètre

Type de données

Obligatoire

Description

grant_type

Chaîne

Oui

Type d’autorisation demandée : . authorization_code indique qu’un code d’autorisation doit être échangé contre un jeton d’accès. . refresh_token indique une demande d’actualisation d’un jeton d’accès.

code

Chaîne

Oui

Code d’autorisation renvoyé par le point de terminaison du jeton. Utilisé et requis lorsque grant_type est défini sur authorization_code.

refresh_token

Chaîne

Oui

Jeton d’actualisation renvoyé par une demande antérieure au point de terminaison du jeton lors de l’utilisation du code d’autorisation. Utilisé et requis lorsque grant_type est défini sur refresh_token.

redirect_uri

Chaîne

Oui

Rediriger URI comme spécifié dans l’intégration de sécurité (voir Étape 1 : Créer une intégration OAuth) et utilisée dans l’URL d’autorisation lors de la demande d’un code d’autorisation. Utilisé et requis lorsque grant_type est défini sur authorization_code.

code_verifier

Chaîne

Non

Requis uniquement si la demande d’autorisation a été envoyée au point de terminaison d’autorisation avec une valeur de paramètre code_challenge. Vérificateur de code pour PKCE. Pour plus d’informations, voir Clé de preuve pour échange de code (dans ce chapitre).

L’ID de client et le secret du client doivent être inclus dans l’en-tête d’autorisation. Actuellement, Snowflake ne prend en charge que le schéma d’authentification de base, ce qui signifie que la valeur attendue est sous la forme suivante :

Basic Base64(id_client:secret_client)

Où :

Paramètre

Type de données

Obligatoire

Description

id_client

Chaîne

Oui

ID de client de l’intégration.

secret_client

Chaîne

Oui

Secret du client pour l’intégration.

L’ID et le secret du client peuvent être récupérés à l’aide de la fonction SYSTEM$SHOW_OAUTH_CLIENT_SECRETS.

Notez le caractère : compris entre id_client et secret_client.

post body

Un objet JSON est renvoyé avec les attributs suivants :

Paramètre

Type de données

Description

access_token

Chaîne

Jeton d’accès utilisé pour établir une session Snowflake

refresh_token

Chaîne

Jeton d’actualisation. Non émis si le client est configuré pour ne pas émettre de jetons d’actualisation ou si l’utilisateur n’a pas consenti à la portée refresh_token.

expires_in

Entier

Nombre de secondes restantes jusqu’à l’expiration du jeton

token_type

Chaîne

Type de jeton d’accès. Actuellement, toujours Bearer.

username

Chaîne

Nom d’utilisateur auquel appartient le jeton d’accès. Actuellement renvoyé uniquement lors de l’échange d’un code d’autorisation pour un jeton d’accès.

Assurez-vous que l’en-tête de type de contenu dans le message POST est défini comme suit :

Content-type: application/x-www-form-urlencoded

Exemple de réponse réussie

L’exemple suivant montre une réponse réussie lors de l’échange d’un code d’autorisation contre un jeton d’accès et d’actualisation :

{
  "access_token":  "ACCESS_TOKEN",
  "expires_in": 600,
  "refresh_token": "REFRESH_TOKEN",
  "token_type": "Bearer",
  "username": "user1",
}

Exemple de réponse infructueuse

L’exemple suivant montre une réponse infructueuse :

{
  "data" : null,
  "message" : "This is an invalid client.",
  "code" : null,
  "success" : false,
  "error" : "invalid_client"
}

La valeur de chaîne message est une description de l’erreur, et error correspond au type d’erreur. Pour plus d’informations sur les types d’erreurs renvoyés, reportez-vous à la section Erreurs (dans cette rubrique).

Clé de preuve pour échange de code

Snowflake prend en charge la clé de vérification pour l’échange de code (PKCE) afin d’obtenir des jetons d’accès à l’aide du type d’octroi authorization_code, comme décrit dans RFC 7636. PKCE peut être utilisé pour réduire le risque d’attaque par interception de code d’autorisation et convient aux clients qui ne sont peut-être pas en mesure de protéger complètement le secret du client.

Par défaut, PKCE est facultatif et n’est appliqué que si les paramètres code_challenge et code_challenge_method sont tous deux inclus dans l’URL du point de terminaison d’autorisation. Cependant, nous conseillons vivement à votre client d’exiger PKCE pour toutes les autorisations afin de sécuriser davantage le flux de données OAuth.

Ce qui suit décrit le fonctionnement de PKCE pour Snowflake :

  1. Le client crée un secret appelé vérificateur de code et y effectue une transformation pour générer le défi de code. Le client garde le secret.

    Important

    Générez le vérificateur de code à partir des caractères ASCII autorisés conformément à la Section 4.1 de RFC 7636.

  2. Le client qui dirige l’utilisateur vers l’URL d’autorisation ajoute les deux paramètres de requête suivants :

    code_challenge

    Spécifie le défi de code généré à l’étape 1.

    code_challenge_method

    Spécifie les transformations utilisées sur le vérificateur de code à l’étape 1 pour générer le défi de code. Actuellement, Snowflake ne prend en charge que SHA256. Cette valeur doit donc être définie sur S256. L’algorithme de transformation pour SHA256 est BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).

  3. Une fois que l’utilisateur a accepté les portées demandées ou que Snowflake a déterminé que le consentement est présent pour cet utilisateur, le code d’autorisation est émis.

  4. Le client reçoit le code d’autorisation du serveur d’autorisation Snowflake, qu’il soumet ensuite avec le code_verifier dans la demande au point de terminaison du jeton.

  5. Snowflake transforme la valeur code_verifier et vérifie que la valeur transformée correspond à la valeur code_challenge utilisée lors de la génération d’autorisations. Si ces valeurs correspondent, le serveur d’autorisation émet les jetons d’accès et d’actualisation.

Utilisation de l’authentification par paire de clés

Snowflake accepte l’authentification par paire de clés plutôt que l’authentification par nom d’utilisateur/mot de passe typique lors de l’appel vers un point de terminaison de jeton Oath. Cette méthode d’authentification nécessite une paire de clés de 2048 bits (minimum) RSA. Générez la paire de clés publiques-privées PEM (Privacy Enhanced Mail) via OpenSSL. La clé publique est attribuée à l’utilisateur Snowflake qui utilisera le client Snowflake.

Pour configurer la paire de clés publiques/privées :

  1. Depuis la ligne de commande d’une fenêtre de terminal, générez une clé privée :

    $ openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8
    

    OpenSSL demande une phrase secrète utilisée pour chiffrer le fichier de la clé privée. Nous vous recommandons d’utiliser une phrase secrète forte pour protéger la clé privée. Enregistrez cette phrase secrète. Vous l’entrerez lorsque vous vous connecterez à Snowflake. Notez que la phrase secrète n’est utilisée que pour protéger la clé privée et ne sera jamais envoyée à Snowflake.

    Exemple de clé privée PEM

    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIIE6TAbBgkqhkiG9w0BBQMwDgQILYPyCppzOwECAggABIIEyLiGSpeeGSe3xHP1
    wHLjfCYycUPennlX2bd8yX8xOxGSGfvB+99+PmSlex0FmY9ov1J8H1H9Y3lMWXbL
    ...
    -----END ENCRYPTED PRIVATE KEY-----
    
  2. Depuis la ligne de commande, générez la clé publique en faisant référence à la clé privée :

    $ openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
    

    Exemple de clé publique PEM

    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4
    zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk
    ...
    -----END PUBLIC KEY-----
    
  3. Copiez les fichiers de clés publiques et privées dans un répertoire local en vue de leur stockage. Enregistrez le chemin d’accès aux fichiers.

    Notez que la clé privée est stockée au format PKCS#8 (Public Key Cryptography Standards) et est chiffrée à l’aide de la phrase de chiffrement que vous avez spécifiée à l’étape précédente ; toutefois, le fichier doit toujours être protégé contre tout accès non autorisé au moyen du mécanisme d’autorisation de fichier fourni par votre système d’exploitation. Il est de votre responsabilité de sécuriser le fichier lorsqu’il n’est pas utilisé.

  4. Attribuez la clé publique à l’objet d’intégration à l’aide de ALTER SECURITY INTEGRATION. Par exemple :

    ALTER SECURITY INTEGRATION myint SET OAUTH_CLIENT_RSA_PUBLIC_KEY='MIIBIjANBgkqh...';
    

    Note

    • Seuls les administrateurs de compte peuvent exécuter la commande ALTER SECURITY INTEGRATION.

    • Excluez l’en-tête et le pied de page de la clé publique dans la commande.

    Vérifiez l’empreinte de la clé publique en utilisant DESCRIBE INTEGRATION :

    DESC SECURITY INTEGRATION myint;
    
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    | property                         | property_type | property_value                                                       | property_default |
    |----------------------------------+---------------+----------------------------------------------------------------------+------------------|
    ...
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_FP   | String        | SHA256:MRItnbO/123abc/abcdefghijklmn12345678901234=                  |                  |
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP | String        |                                                                      |                  |
    ...
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    

    Note

    La propriété OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP est décrite dans Rotation de clé (dans ce chapitre).

  5. Modifiez et exécutez l’exemple de code ci-dessous. Le code déchiffre le fichier de la clé privée et le transmet au serveur d’autorisation Snowflake :

  • Mettez à jour les paramètres de sécurité :

    • <clé_privée> : ouvrez le fichier rsa_key.p8 dans un éditeur de texte et copiez les lignes entre :

    -----BEGIN RSA PRIVATE KEY-----
    ...
    -----END RSA PRIVATE KEY-----
    
  • Mettez à jour les paramètres de session :

    • <account_name> : spécifie le nom complet de votre compte (fourni par Snowflake).

  • Mettez à jour les champs de jetons Web (JWT) JSON :

    post body

    Un objet JSON avec les champs standards suivants (« revendications ») :

    Attribut

    Type de données

    Obligatoire

    Description

    iss

    Chaîne

    Oui

    Spécifie le principal qui a émis le JWT au format id_client.empreinte_clé_publiqueid_client est l’ID de client de l’intégration du client OAuth et empreinte_clé_publique est l’empreinte de la clé publique utilisée lors de la vérification.

    sub

    Chaîne

    Oui

    Objet du JWT au format nom_compte.id_clientnom_compte est le nom complet du compte Snowflake et id_client est l’ID du client de l’intégration du client OAuth. Selon la plate-forme Cloud (AWS ou Azure) et la région où votre compte est hébergé, le nom complet du compte peut nécessiter des segments supplémentaires. Pour plus d’informations, voir la description de la variable compte sous Point de terminaison du jeton.

    iat

    Horodatage

    Non

    Heure à laquelle le jeton a été émis.

    exp

    Horodatage

    Oui

    Heure à laquelle le jeton doit expirer. Cette période devrait être relativement courte (quelques minutes, par exemple).

Exemple de code

import datetime
import json
import urllib

import jwt
import requests

private_key = """
-----BEGIN RSA PRIVATE KEY-----
<private_key>
-----END RSA PRIVATE KEY-----"""

public_key_fp = "SHA256:MR..."


def _make_request(payload, encoded_jwt_token):
    token_url = "https://<account_name>.snowflakecomputing.com/oauth/token-request"
    headers = {
            u'Authorization': "Bearer %s" % (encoded_jwt_token),
            u'content-type': u'application/x-www-form-urlencoded'
    }
    r = requests.post(
            token_url,
            headers=headers,
            data=urllib.urlencode(payload))
    return r.json()


def make_request_for_access_token(oauth_az_code, encoded_jwt_token):
    """ Given an Authorization Code, make a request for an Access Token
    and a Refresh Token."""
    payload = {
        'grant_type': 'authorization_code',
        'code': oauth_az_code
    }
    return _make_request(payload, encoded_jwt_token)


def make_request_for_refresh_token(refresh_token, encoded_jwt_token):
    """ Given a Refresh Token, make a request for another Access Token."""
    payload = {
        'grant_type': 'refresh_token',
        'refresh_token': refresh_token
    }
    return _make_request(payload, encoded_jwt_token)


def main():
    account_name = "<account_name>"
    client_id = "1234"  # found by running DESC SECURITY INTEGRATION
    issuer = "{}.{}".format(client_id, public_key_fp)
    subject = "{}.{}".format(account_name, client_id)
    payload = {
        'iss': issuer,
        'sub': subject,
        'iat': datetime.datetime.utcnow(),
        'exp': datetime.datetime.utcnow() + datetime.timedelta(seconds=30)
    }
    encoded_jwt_token = jwt.encode(
            payload,
            private_key,
            algorithm='RS256')

    data = make_request_for_access_token(oauth_az_code, encoded_jwt_token)
    refresh_token = data['refresh_token']
    data = make_request_for_refresh_token(refresh_token, encoded_jwt_token)
    access_token = data['access_token']


if __name__ == '__main__':
    main()

Une fois le jeton créé, envoyez-le dans des demandes vers le point de terminaison du jeton. Les demandes requièrent le format d’autorisation Bearer comme en-tête d’autorisation au lieu du format d’autorisation de base normalement utilisé pour l’ID du client et le secret du client, comme suit :

"Authorization: Bearer JWT_TOKEN"

Rotation de clé

Snowflake accepte plusieurs clés actives pour permettre une rotation ininterrompue. Faites pivoter et remplacez vos clés publiques et privées en fonction du calendrier d’expiration que vous suivez en interne.

Actuellement, vous pouvez utiliser les paramètres OAUTH_CLIENT_RSA_PUBLIC_KEY et OAUTH_CLIENT_RSA_PUBLIC_KEY_2 pour ALTER SECURITY INTEGRATION afin d’associer jusqu’à 2 clés publiques à un seul utilisateur.

Pour faire tourner vos clés :

  1. Effectuez les étapes de la section Utilisation de l’authentification par paire de clés (dans cette rubrique) :

    • Générer un nouvel ensemble de clés privées et publiques.

    • Attribuer la clé publique à l’intégration. Définir la valeur de la clé publique sur OAUTH_CLIENT_RSA_PUBLIC_KEY ou OAUTH_CLIENT_RSA_PUBLIC_KEY_2 (la valeur de la clé qui n’est pas actuellement utilisée). Par exemple :

      alter integration myint set oauth_client_rsa_public_key_2='JERUEHtcve...';
      
  2. Mettez à jour le code pour vous connecter à Snowflake. Spécifiez la nouvelle clé privée.

    Snowflake vérifie la bonne clé publique active pour l’authentification sur la base de la clé privée soumise.

  3. Retirez l’ancienne clé publique de l’intégration. Par exemple :

    alter integration myint unset rsa_public_key;
    

Erreurs

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.

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

client_nonvalide

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’octroi pris en charge pour le moment).

requête_nonvalide

La requête était mal formée ou n’a pas pu être traitée.