カスタムクライアント用のSnowflake OAuth の構成

このトピックでは、カスタムクライアントの OAuth サポートを構成する方法について説明します。

このトピックの内容:

ワークフロー

カスタムクライアントの OAuth を構成するには、次の高レベルの手順が必要です。

  1. クライアントをSnowflakeに登録します。クライアントを登録するには、統合を作成します。統合は、Snowflakeと OAuth をサポートするクライアントなどのサードパーティサービスの間のインターフェイスを提供するSnowflakeオブジェクトです。

    登録プロセスは、クライアント ID とクライアントシークレットを定義します。

  2. Snowflake OAuth エンドポイントへの呼び出しを構成して、Snowflake認証サーバーから認証コードをリクエストし、アクセストークンをリクエストおよび更新します。

    初期認証リクエストのオプションの「範囲」パラメーターは、アクセストークンによって許可されるロールを制限し、さらに更新トークンの動作を構成するために使用できます。

ステップ1: OAuth 統合を作成する

CREATE SECURITY INTEGRATION コマンドを使用して統合を作成します。

注釈

この SQL コマンドを実行できるのは、アカウント管理者( ACCOUNTADMIN ロールを持つユーザー)またはグローバル CREATE INTEGRATION 権限を持つロールのみです。

統合の使用から特定の役割をブロックする

オプションの BLOCKED_ROLES_LIST パラメーターを使用すると、ユーザーが統合での使用を明示的に同意 できない Snowflakeロールをリストできます。

デフォルトでは、アカウント管理者(ACCOUNTADMIN)およびセキュリティ管理者(SECURITYADMIN)の役割はこのリストに含まれており、削除できません。ユーザーがこれらのロールで OAuth を使用できるようにするビジネス上のニーズがあり、セキュリティチームがそれを許可している場合は、 Snowflakeサポート に連絡して、アカウントでこれらのロールを許可するようリクエストしてください。

ネットワークポリシーの管理

Snowflakeは OAuthのネットワークポリシーをサポートしています。詳細については、 OAuth およびネットワークポリシー をご参照ください。

統合の例

次の例では、キーペア認証を使用する OAuth 統合を作成します。統合では、1日(86400秒)後に期限切れになる更新トークンが許可されます。統合により、ユーザーは SYSADMIN をアクティブロールとしてセッションを開始できなくなります。

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
  ..
  ';

ステップ2: OAuth エンドポイントを呼び出す

OAuth エンドポイントは、クライアントが認証コードをリクエストし、アクセストークンをリクエストおよび更新するために呼び出す URLs です。これらのエンドポイントは、エンドポイントが呼び出されたときに実行される特定の OAuth 2.0ポリシーを参照します。

Snowflakeは、次の OAuth エンドポイントを提供します。

認証

https://<アカウント名>.snowflakecomputing.com/oauth/authorize

トークンリクエスト

https://<アカウント名>.snowflakecomputing.com/oauth/token-request

便宜上、Snowflakeはクライアントの登録時にエンドポイントを定義します。統合のエンドポイントを表示するには、 DESCRIBE INTEGRATION を実行します。

たとえば、次の例は ステップ1: OAuth 統合を作成する (このトピック内)で作成した統合に、エンドポイントを返します。

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         |                  |
...
+----------------------------------+---------------+----------------------------------------------------------------------+------------------+

認証エンドポイント

ユーザーがSnowflakeでクライアントを正常に認証した後、認証エンドポイントを使用して認証付与を取得します。認証エンドポイントは次のとおりです。

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

条件:

<アカウント名>

アカウントのフルネームを指定します(Snowflakeが提供)。

完全なアカウント名には、アカウントがホストされている 地域、および クラウドプラットフォーム を識別する 追加 のセグメントが含まれている場合があります。

地域別のアカウント名の例

アカウント名が xy12345 の場合、

クラウドプラットフォーム/地域

完全なアカウント名

AWS

US 西部(オレゴン)

xy12345

US 東部(オハイオ)

xy12345.us-east-2.aws

US 東部(バージニア北部)

xy12345.us-east-1

US 東部(商業組織、バージニア政府北部)

xy12345.us-east-1-gov.aws

カナダ(中部)

xy12345.ca-central-1.aws

EU (アイルランド)

xy12345.eu-west-1

EU (フランクフルト)

xy12345.eu-central-1

アジア太平洋(東京)

xy12345.ap-northeast-1.aws

アジア太平洋(ムンバイ)

xy12345.ap-south-1.aws

アジア太平洋(シンガポール)

xy12345.ap-southeast-1

アジア太平洋(シドニー)

xy12345.ap-southeast-2

GCP

US 中央部1(アイオワ)

xy12345.us-central1.gcp

ヨーロッパ西部2(ロンドン)

xy12345.europe-west2.gcp

ヨーロッパ西部4(オランダ)

xy12345.europe-west4.gcp

Azure

西 US 2(ワシントン)

xy12345.west-us-2.azure

東 US 2(バージニア)

xy12345.east-us-2.azure

US 政府バージニア

xy12345.us-gov-virginia.azure

カナダ中央部(トロント)

xy12345.canada-central.azure

西ヨーロッパ(オランダ)

xy12345.west-europe.azure

スイス北部(チューリッヒ)

xy12345.switzerland-north.azure

東南アジア(シンガポール)

xy12345.southeast-asia.azure

オーストラリア東部(ニューサウスウェールズ)

xy12345.australia-east.azure

重要

次のいずれかの条件に該当する場合、アカウント名はこの例の構造とは異なります。

  • Snowflake Editionが VPS の場合、アカウント名の詳細については Snowflakeサポート にお問い合わせください。

  • AWS PrivateLink がアカウントで有効になっている場合、アカウント名には追加の privatelink セグメントが 必要 です。詳細については、 AWS PrivateLink とSnowflake をご参照ください。

method

GET

重要

認証エンドポイントは、ユーザーが操作できるブラウザーで開く 必要 があります。このエンドポイントでは cURL を使用しないでください。

query parameters

注釈

次のパラメーターは URL エンコードする必要があります。

パラメーター

データ型

必須

説明

client_id

String

はい

クライアント ID (クライアントの登録時にSnowflakeが提供)

response_type

String

はい

作成された応答タイプ。Snowflakeは認証コードのみをパブリッシュするため、現在 code 値をサポートしています。

redirect_uri

String

はい

URI ユーザーが正常に認証された後にリダイレクトされる場所。クライアントの登録時にSnowflakeに登録された値と一致する必要があります。

state

String

いいえ

Snowflake認証サーバーからの応答で返される2048 ASCII 文字以下の文字列。通常、クロスサイトリクエストフォージェリによる攻撃を防ぐために使用されます。

scope

String

いいえ

アクセスリクエストの範囲を制限するために使用されるスペース区切りの文字列。詳細については、このトピックの 範囲 をご参照ください。

code_challenge

String

いいえ

コード交換の証明キーのチャレンジ(PKCE)。シークレットおよびコードチャレンジメソッドを介して生成された文字列。詳細については、 コード交換の証明キー (このトピック内)をご参照ください。

code_challenge_method

String

いいえ

PKCE のコードチャレンジを引き出すために使用されるメソッドを示す文字列。詳細については、 コード交換の証明キー (このトピック)をご参照ください。

ユーザーがクライアントを認証すると、 GET リクエストに次を含む redirect_uri にリダイレクトされます。

パラメーター

説明

code

トークンエンドポイントでアクセストークンと交換できる、存続時間が短い認証コード。

state

元のリクエストで提供された state 値、変更なし。

scope

アクセスリクエストの範囲。現在、最初の認証リクエストの scope 値と同じですが、将来異なる可能性があります。詳細については、このトピックの 範囲 をご参照ください。

範囲

オプションで、初期認可リクエストの範囲パラメーターは、アクセストークンによって許可される操作とロールを制限します。

認証リクエストの際、ただちに範囲のセマンティクスは確認されますが、必ずしも範囲の有効性が確認されるわけではありません。つまり、ユーザーが認証される前に無効な範囲(例:「bogus_scope」)は拒否されますが、ユーザーがアクセスできない範囲(特定のロールなど)は、ユーザーが認証されるまでエラーになりません。有効な範囲パラメーターは次のとおりです。

query parameters

パラメーター

必須

説明

refresh_token

いいえ

認証 URL に含まれている場合、Snowflakeはオフラインアクセスに同意するオプションをユーザーに提示します。このコンテキストでは、オフラインアクセスとは、ユーザーが存在しないときにクライアントがアクセストークンを更新できるようにすることを指します。ユーザーの同意があると、認証サーバーは、認証コードを引き換えるときにアクセストークンに加えて更新トークンを返します。

session:role:ロール名

いいえ

ユーザーがセッションに同意できる 単一 ロールのアクセストークンを制限するために使用されます。指定できるセッションロール範囲は1つだけです。この範囲を省略すると、代わりにユーザーの既定のロールが使用されます。ユーザーが同意を承認すると、このスコープが承認 URLに含まれているかどうかに関係なく、Snowflakeは常にセッションのロールを表示します。 . ロール名 は大文字と小文字が区別され、 CREATE ROLE を使用して作成されたときにロール名が引用符で囲まれていない限り、すべて大文字で入力する必要があります。ケースを確認するには、Snowflakeで SHOW ROLES を実行し、出力でロール名を確認します。

範囲パラメーターを認証 URLに追加します。

次の例では、許可をカスタムR1ロールに制限しています。

scope=session:role:R1

次の例は、アクセス/リフレッシュトークンがユーザーの既定のロールを使用し、オフラインアクセスが発生するようにリフレッシュトークンをリクエストすることを示しています。

scope=refresh_token

次の例では、認証をカスタムR1ロールに制限し、オフラインアクセスが発生するように更新トークンをリクエストします。

scope=refresh_token session:role:SYSADMIN

トークンエンドポイント

このエンドポイントは、リクエストパラメーターに応じてアクセストークンまたはリフレッシュトークンを返します。トークンエンドポイントは次のとおりです。

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

条件:

<アカウント名>

アカウントのフルネームを指定します(Snowflakeが提供)。

完全なアカウント名には、アカウントがホストされている 地域、および クラウドプラットフォーム を識別する 追加 のセグメントが含まれている場合があります。

クラウドプラットフォームと地域のアカウント名の例

アカウント名が xy12345 の場合、

クラウドプラットフォーム/地域

完全なアカウント名

AWS

US 西部(オレゴン)

xy12345

US 東部(オハイオ)

xy12345.us-east-2.aws

US 東部(バージニア北部)

xy12345.us-east-1

US 東部(商業組織、バージニア政府北部)

xy12345.us-east-1-gov.aws

カナダ(中部)

xy12345.ca-central-1.aws

EU (アイルランド)

xy12345.eu-west-1

EU (フランクフルト)

xy12345.eu-central-1

アジア太平洋(東京)

xy12345.ap-northeast-1.aws

アジア太平洋(ムンバイ)

xy12345.ap-south-1.aws

アジア太平洋(シンガポール)

xy12345.ap-southeast-1

アジア太平洋(シドニー)

xy12345.ap-southeast-2

GCP

US 中央部1(アイオワ)

xy12345.us-central1.gcp

ヨーロッパ西部2(ロンドン)

xy12345.europe-west2.gcp

ヨーロッパ西部4(オランダ)

xy12345.europe-west4.gcp

Azure

西 US 2(ワシントン)

xy12345.west-us-2.azure

東 US 2(バージニア)

xy12345.east-us-2.azure

US 政府バージニア

xy12345.us-gov-virginia.azure

カナダ中央部(トロント)

xy12345.canada-central.azure

西ヨーロッパ(オランダ)

xy12345.west-europe.azure

スイス北部(チューリッヒ)

xy12345.switzerland-north.azure

東南アジア(シンガポール)

xy12345.southeast-asia.azure

オーストラリア東部(ニューサウスウェールズ)

xy12345.australia-east.azure

重要

次のいずれかの条件に該当する場合、アカウント名はこの例の構造とは異なります。

  • Snowflake Editionが VPS の場合、アカウント名の詳細については Snowflakeサポート にお問い合わせください。

  • AWS PrivateLink がアカウントで有効になっている場合、アカウント名には追加の privatelink セグメントが 必要 です。詳細については、 AWS PrivateLink とSnowflake をご参照ください。

method

POST

query parameters

パラメーター

データ型

必須

説明

grant_type

String

はい

要求された付与のタイプ: . authorization_code は、認証コードをアクセストークンと交換する必要があることを示します。 . refresh_token は、アクセストークンを更新する要求を示します。

code

String

はい

トークンエンドポイントから返された認証コード。 grant_typeauthorization_code に設定されている場合に使用され、必須です。

refresh_token

String

はい

認証コードを引き換えるときに、以前のリクエストからトークンエンドポイントに返された更新トークン。 grant_typerefresh_token に設定されている場合に使用する必要があります。

redirect_uri

String

はい

セキュリティ統合( ステップ1: OAuth 統合を作成する を参照)で指定されたとおりに URI をリダイレクトします。認証コードをリクエストするときに認証 URL で使用されます。 grant_typeauthorization_code に設定されている場合に使用する必要があります。

code_verifier

String

いいえ

認証リクエストが code_challenge パラメーター値で 認証エンドポイント に送信された場合にのみ必要です。 PKCE のコード確認。詳細については、 コード交換の証明キー (このトピック)をご参照ください。

クライアント ID とクライアントシークレットを認証ヘッダーに含める必要があります。現在、Snowflakeは 基本認証スキーム のみをサポートしています。つまり、期待される値は次の形式です。

Basic Base64(クライアントID:クライアントシークレット)

条件:

パラメーター

データ型

必須

説明

クライアントID

String

はい

統合のクライアント ID 。

クライアントシークレット

String

はい

統合のクライアントシークレット。

クライアント ID とクライアントシークレットの両方は、 SYSTEM$SHOW_OAUTH_CLIENT_SECRETS 関数を使用して取得できます。

クライアントIDクライアントシークレット の間の : 文字に注意してください。

post body

次の属性を持つ JSON オブジェクトが返されます。

パラメーター

データ型

説明

access_token

String

Snowflakeセッションの確立に使用されるアクセストークン

refresh_token

String

更新トークン。クライアントが更新トークンをパブリッシュしないように構成されている場合、またはユーザーが refresh_token 範囲に同意しなかった場合はパブリッシュされません。

expires_in

整数

トークンの有効期限が切れるまでの残りの秒数

token_type

String

アクセストークンタイプ。現在、常に Bearer です。

username

String

アクセストークンが属するユーザー名。現在、アクセストークンの認証コードを交換する場合にのみ返されます。

POST メッセージのコンテンツタイプのヘッダーが次のように設定されていることを確認します。

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

成功した応答の例

次の例は、アクセストークンと更新トークンの認証コードを交換するときの正常な応答を示しています。

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

失敗した応答の例

次の例は、失敗した応答を示しています。

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

message 文字列値はエラーの説明であり、 error はエラータイプです。返されるエラータイプの詳細については、このトピックの エラー セクションをご参照ください。

コード交換の証明キー

Snowflakeは、 RFC 7636 で説明されているように、 authorization_code 付与タイプを使用してアクセストークンを取得するためのコード交換用の証明キー(PKCE)をサポートしています。PKCE は、認証コード傍受による攻撃の可能性を減らすために使用でき、クライアントシークレットを十分安全に保持できないクライアントに適しています。

デフォルトでは、 PKCE はオプションであり、 code_challenge および code_challenge_method パラメーターが両方とも許可エンドポイント URLに含まれている場合にのみ強制されます。ただし、 OAuth フローをより安全にするために、クライアントに対してすべての認証に PKCE を要求することを 強く お勧めします。

以下は、Snowflakeの PKCE の仕組みを説明しています。

  1. クライアントは コード確認 と呼ばれるシークレットを作成し、それを変換して コードチャレンジ を生成します。クライアントはシークレットを保持します。

    重要

    セクション4.1 RFC 7636 に従って、許可された ASCII 文字から コード識別子 を生成します。

  2. ユーザーを認証 URL に誘導するクライアントは、次の2つのクエリパラメーターを追加します。

    code_challenge

    ステップ1で生成されたコードチャレンジを指定します。

    code_challenge_method

    コードチャレンジを生成するために、ステップ1のコード確認で使用される変換を指定します。現在、Snowflakeは SHA256 のみをサポートしているため、この値は S256 に設定する必要があります。SHA256 の変換アルゴリズムは BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) です。

  3. ユーザーがリクエストされた範囲に同意するか、Snowflakeがそのユーザーに同意があると判断した後、認証コードがパブリッシュされます。

  4. クライアントは、Snowflake認証サーバーから認証コードを受け取り、トークンエンドポイントへのリクエストの code_verifier とともに送信します。

  5. Snowflakeは code_verifier 値を変換し、変換された値が認証の生成時に使用される code_challenge 値と一致することを確認します。これらの値が一致する場合、許可サーバーはアクセストークンと更新トークンをパブリッシュします。

キーペア認証の使用

Snowflakeは、Oathトークンエンドポイントを呼び出すときに、一般的なユーザー名/パスワード認証ではなく、キーペア認証の使用をサポートしています。この認証方法には、2048ビット(最小)の RSA キーペアが必要です。 OpenSSLを使用して PEM (Privacy Enhanced Mail)公開/秘密キーペアを生成します。公開キーは、Snowflakeクライアントを使用するSnowflakeユーザーに割り当てられます。

公開/秘密キーペアを構成するには:

  1. ターミナルウィンドウのコマンドラインから、秘密キーを生成します。

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

    OpenSSL は、秘密キーファイルの暗号化に使用されるパスフレーズの入力を求めます。強力なパスフレーズを使用して秘密キーを保護することをお勧めします。このパスフレーズを記録します。Snowflakeに接続するときに入力します。パスフレーズは秘密キーの保護にのみ使用され、Snowflakeには送信されません。

    サンプル PEM 秘密キー

    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIIE6TAbBgkqhkiG9w0BBQMwDgQILYPyCppzOwECAggABIIEyLiGSpeeGSe3xHP1
    wHLjfCYycUPennlX2bd8yX8xOxGSGfvB+99+PmSlex0FmY9ov1J8H1H9Y3lMWXbL
    ...
    -----END ENCRYPTED PRIVATE KEY-----
    
  2. コマンドラインから、秘密キーを参照して公開キーを生成します。

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

    サンプル PEM 公開キー

    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4
    zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk
    ...
    -----END PUBLIC KEY-----
    
  3. 公開キーファイルと秘密キーファイルを保存用のローカルディレクトリにコピーします。ファイルへのパスを記録します。

    秘密キーは PKCS#8(公開キー暗号化標準)形式を使用して格納され、前の手順で指定したパスフレーズを使用して暗号化されることに注意してください。ただし、オペレーティングシステムが提供するファイル許可メカニズムを使用して、ファイルを不正アクセスから保護する必要があります。ファイルが使用されていない場合、ファイルを保護するのはユーザーの責任です。

  4. ALTER SECURITY INTEGRATION を使用して、公開キーを統合オブジェクトに割り当てます。例:

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

    注釈

    • アカウント管理者のみが ALTER SECURITY INTEGRATION コマンドを実行できます。

    • コマンド内で公開キーのヘッダーとフッターを除外します。

    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        |                                                                      |                  |
    ...
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    

    注釈

    OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP プロパティについては、このトピックの キーローテーション で説明しています。

  5. 以下のサンプルコードを変更して実行します。コードは秘密キーファイルを復号化し、Snowflake認証サーバーに渡します。

  • セキュリティパラメーターを更新します。

    • <秘密キー> :テキストエディターで rsa_key.p8 ファイルを開き、次の間の行をコピーします。

    -----BEGIN RSA PRIVATE KEY-----
    ...
    -----END RSA PRIVATE KEY-----
    
  • セッションパラメーターを更新します。

    • <account_name> :アカウントのフルネームを指定します(Snowflakeが提供)。

  • JSON ウェブトークン(JWT)フィールドを更新します。

    post body

    次の標準フィールド(「クレーム」)を持つ JSON オブジェクト:

    属性

    データ型

    必須「

    説明

    iss

    String

    はい

    クライアントID.公開キーフィンガープリント の形式で JWT をパブリッシュしたプリンシパルを指定します。 クライアントID は OAuth クライアント統合のクライアント ID および 公開キーフィンガープリント は、確認中に使用される公開キーのフィンガープリントです。

    sub

    String

    はい

    アカウント名.クライアントID の形式の JWT の件名。 アカウント名 はSnowflakeアカウントの完全な名前で、 クライアントID は OAuth クライアント統合のクライアント ID です。アカウントがホストされているクラウドプラットフォーム(AWS またはAzure)および地域によっては、完全なアカウント名に 追加 のセグメントが必要な場合があります。詳細については、 トークンエンドポイントアカウント 変数の説明をご参照ください。

    iat

    タイムスタンプ

    いいえ

    トークンがパブリッシュされた時刻。

    exp

    タイムスタンプ

    はい

    トークンの有効期限。この期間は比較的短くする必要があります(例:数分)。

サンプルコード

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()

トークンが作成されたら、トークンエンドポイントにリクエストで送信します。リクエストでは、次のように、通常クライアント ID およびクライアントシークレットに使用される基本認証形式の代わりに、認証ヘッダーとしてベアラー認証形式が必要です。

"Authorization: Bearer JWT_TOKEN"

キーローテーション

Snowflakeは、複数のアクティブキーをサポートして、連続したローテーションを可能にします。内部的に従う有効期限のスケジュールに基づいて、公開キーと秘密キーをローテーションして交換します。

現在、 ALTER SECURITY INTEGRATIONOAUTH_CLIENT_RSA_PUBLIC_KEY および OAUTH_CLIENT_RSA_PUBLIC_KEY_2 パラメーターを使用して、最大2個の公開キーを1人のユーザーに関連付けることができます。

キーをローテーションするには:

  1. このトピックの キーペア認証の使用 の次の手順を完了します。

    • 新しい秘密キーと公開キーのセットを生成します。

    • 統合に公開キーを割り当てます。公開キーの値を OAUTH_CLIENT_RSA_PUBLIC_KEY または OAUTH_CLIENT_RSA_PUBLIC_KEY_2 (現在使用されていないキーの値)に設定します。例:

      alter integration myint set oauth_client_rsa_public_key_2='JERUEHtcve...';
      
  2. Snowflakeに接続するようにコードを更新します。新しい秘密キーを指定します。

    Snowflakeは、送信された秘密キーに基づいて、認証のための正しいアクティブな公開キーを確認します。

  3. 統合から古い公開キーを削除します。例:

    alter integration myint unset rsa_public_key;
    

エラー

以下は、認証フロー中、トークン交換中、または OAuth フローの完了後にSnowflakeセッションを作成する時に返される可能性がある OAuth に関連するエラーコードです。

エラーコード

エラー

説明

390302

OAUTH_CONSENT_INVALID

特定のユーザーに対する同意の生成または検証に関する問題。

390303

OAUTH_ACCESS_TOKEN_INVALID

Snowflakeセッションを作成しようとしたときに使用されたアクセストークンが期限切れまたは無効です。

390304

OAUTH_AUTHORIZE_INVALID_RESPONSE_TYPE

無効な response_type が、認証エンドポイントにパラメーターとして提供されました( code である可能性が高い)。

390305

OAUTH_AUTHORIZE_INVALID_STATE_LENGTH

認証エンドポイントにパラメーターとして提供されたステータスパラメーターが2048文字を超えています。

390306

OAUTH_AUTHORIZE_INVALID_CLIENT_ID

指定されたクライアントIDに関連付けられた統合は存在しません。

390307

OAUTH_AUTHORIZE_INVALID_REDIRECT_URI

認証エンドポイントへのパラメーターとして指定された redirect_uri が、提供された client_id に関連付けられた統合の redirect_uri と一致しないか、 redirect_uri が適切にフォーマットされていません

390308

OAUTH_AUTHORIZE_INVALID_SCOPE

リクエストされた範囲が有効なスコープではないか、リクエストされた範囲をユーザーに完全に付与できません。

さらに、 RFC から次のエラーが取得され、トークンのリクエストまたは交換が失敗したときに生成された JSON BLOBに返されます。

エラー

説明

invalid_client

クライアントが不明である、クライアントのシークレットが一致しないなど、クライアント認証に関連する障害がありました。

invalid_grant

提供された認可付与またはリフレッシュトークンが無効であるか、期限が切れているか、取り消されているか、認可リクエストで使用されたリダイレクト URI と一致しないか、別のクライアントにパブリッシュされました。

unsupported_grant_type

現在、Snowflakeがサポートしていない付与タイプが提供されています(現時点でサポートされている付与タイプは「refresh_token」と「authorization_code」のみです)。

invalid_request

リクエストの形式が正しくないか、処理できませんでした。