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

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

このトピックの内容：

ワークフロー
ステップ1： OAuth 統合を作成する
ステップ2： OAuth エンドポイントを呼び出す
- 認証エンドポイント
  - 範囲
- トークンエンドポイント
  - 成功した応答の例
  - 失敗した応答の例
コード交換の証明キー
キーペア認証の使用
- キーローテーション
エラーコード
ロールの事前認証ユーザーの同意

ワークフロー¶

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

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

登録プロセスは、クライアント ID とクライアントシークレットを定義します。
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_identifier>.snowflakecomputing.com/oauth/authorize

条件:

<アカウント識別子>
アカウントのフルネームを指定します（Snowflakeが提供）。

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

リージョン別のアカウント名の例

アカウントロケーターが xy12345 の場合:

クラウドプラットフォーム / . リージョン

アカウントロケーター . （必要に応じて追加のセグメントを含む）

Amazon Web Services（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

ヨーロッパ（ロンドン）

xy12345.eu-west-2.aws

EU （フランクフルト）

xy12345.eu-central-1

アジア太平洋（東京）

xy12345.ap-northeast-1.aws

アジア太平洋（ムンバイ）

xy12345.ap-south-1.aws

アジア太平洋（シンガポール）

xy12345.ap-southeast-1

アジア太平洋（シドニー）

xy12345.ap-southeast-2

Google Cloud Platform（GCP）

US 中央部1（アイオワ）

xy12345.us-central1.gcp

ヨーロッパ西部2（ロンドン）

xy12345.europe-west2.gcp

ヨーロッパ西部4（オランダ）

xy12345.europe-west4.gcp

Microsoft Azure

西 US 2（ワシントン）

xy12345.west-us-2.azure

中部 US （アイオワ）

xy12345.central-us.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

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:R1

トークンエンドポイント¶

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

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

条件:

<アカウント識別子>
アカウントのフルネームを指定します（Snowflakeが提供）。

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

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

アカウントロケーターが xy12345 の場合:

クラウドプラットフォーム / . リージョン

アカウントロケーター . （必要に応じて追加のセグメントを含む）

Amazon Web Services（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

ヨーロッパ（ロンドン）

xy12345.eu-west-2.aws

EU （フランクフルト）

xy12345.eu-central-1

アジア太平洋（東京）

xy12345.ap-northeast-1.aws

アジア太平洋（ムンバイ）

xy12345.ap-south-1.aws

アジア太平洋（シンガポール）

xy12345.ap-southeast-1

アジア太平洋（シドニー）

xy12345.ap-southeast-2

Google Cloud Platform（GCP）

US 中央部1（アイオワ）

xy12345.us-central1.gcp

ヨーロッパ西部2（ロンドン）

xy12345.europe-west2.gcp

ヨーロッパ西部4（オランダ）

xy12345.europe-west4.gcp

Microsoft Azure

西 US 2（ワシントン）

xy12345.west-us-2.azure

中部 US （アイオワ）

xy12345.central-us.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

method: POST

query parameters

パラメーター	データ型	必須	説明
`grant_type`	String	はい	要求された付与のタイプ： . `authorization_code` は、認証コードをアクセストークンと交換する必要があることを示します。 . `refresh_token` は、アクセストークンを更新する要求を示します。
`code`	String	はい	トークンエンドポイントから返された認証コード。 `grant_type` が `authorization_code` に設定されている場合に使用され、必須です。
`refresh_token`	String	はい	認証コードを引き換えるときに、以前のリクエストからトークンエンドポイントに返された更新トークン。 `grant_type` が `refresh_token` に設定されている場合に使用する必要があります。
`redirect_uri`	String	はい	セキュリティ統合（ステップ1： OAuth 統合を作成するを参照）で指定されたとおりに URI をリダイレクトします。認証コードをリクエストするときに認証 URL で使用されます。 `grant_type` が `authorization_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 はエラータイプです。返されるエラーの種類の詳細については、 OAuth エラーコードをご参照ください。

コード交換の証明キー¶

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

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

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

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

重要

セクション4.1 RFC 7636 に従って、許可された ASCII 文字から コード識別子 を生成します。
ユーザーを認証 URL に誘導するクライアントは、次の2つのクエリパラメーターを追加します。

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

code_challenge_method
コードチャレンジを生成するために、ステップ1のコード確認で使用される変換を指定します。現在、Snowflakeは SHA256 のみをサポートしているため、この値は S256 に設定する必要があります。SHA256 の変換アルゴリズムは BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) です。
ユーザーがリクエストされた範囲に同意するか、Snowflakeがそのユーザーに同意があると判断した後、認証コードがパブリッシュされます。
クライアントは、Snowflake認証サーバーから認証コードを受け取り、トークンエンドポイントへのリクエストの code_verifier とともに送信します。
Snowflakeは code_verifier 値を変換し、変換された値が認証の生成時に使用される code_challenge 値と一致することを確認します。これらの値が一致する場合、許可サーバーはアクセストークンと更新トークンをパブリッシュします。

キーペア認証の使用¶

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

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

ターミナルウィンドウのコマンドラインから、秘密キーを生成します。
$ 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-----

コマンドラインから、秘密キーを参照して公開キーを生成します。

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

サンプル PEM 公開キー

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4
zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk
...
-----END PUBLIC KEY-----

公開キーファイルと秘密キーファイルを保存用のローカルディレクトリにコピーします。ファイルへのパスを記録します。

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

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 プロパティについては、このトピックのキーローテーションで説明しています。

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

セキュリティパラメーターを更新します。
- <秘密キー> ：テキストエディターで rsa_key.p8 ファイルを開き、次の間の行をコピーします。
```
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
```
セッションパラメーターを更新します。
- <account_identifier> ：アカウントのフルネームを指定します（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_identifier>.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_identifier = "<account_identifier>"
    client_id = "1234"  # found by running DESC SECURITY INTEGRATION
    issuer = "{}.{}".format(client_id, public_key_fp)
    subject = "{}.{}".format(account_identifier, 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 INTEGRATION の OAUTH_CLIENT_RSA_PUBLIC_KEY および OAUTH_CLIENT_RSA_PUBLIC_KEY_2 パラメーターを使用して、最大2個の公開キーを1人のユーザーに関連付けることができます。

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

このトピックのキーペア認証の使用の次の手順を完了します。
- 新しい秘密キーと公開キーのセットを生成します。
- 統合に公開キーを割り当てます。公開キーの値を OAUTH_CLIENT_RSA_PUBLIC_KEY または OAUTH_CLIENT_RSA_PUBLIC_KEY_2 （現在使用されていないキーの値）に設定します。例：
  alter integration myint set oauth_client_rsa_public_key_2='JERUEHtcve...';
Snowflakeに接続するようにコードを更新します。新しい秘密キーを指定します。

Snowflakeは、送信された秘密キーに基づいて、認証のための正しいアクティブな公開キーを確認します。
統合から古い公開キーを削除します。例：
```
alter integration myint unset rsa_public_key;
```

エラーコード¶

OAuth に関連付けられたエラーコードのリスト、および認証フロー、トークンのリクエストまたは交換中、または OAuth フロー完了後のSnowflakeセッション作成時に JSON BLOBで返されるエラーについては、 OAuth エラーコードをご参照ください。

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

ワークフロー¶

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

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

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

統合の例¶

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

認証エンドポイント¶

範囲¶

トークンエンドポイント¶

成功した応答の例¶

失敗した応答の例¶

コード交換の証明キー¶

キーペア認証の使用¶

キーローテーション¶

エラーコード¶

ロールの事前認証ユーザーの同意¶