カスタムクライアント用の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_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

ヨーロッパ（ロンドン）

xy12345.eu-west-2.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 またはAzure Private Linkが有効になっている場合、アカウント名には、地域セグメントの代わりに privatelink セグメントが必要です。詳細については、以下をご参照ください。

AWS PrivateLink とSnowflake

Azure Private Linkと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:R1

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

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

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

ヨーロッパ（ロンドン）

xy12345.eu-west-2.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 またはAzure Private Linkが有効になっている場合、アカウント名には、地域セグメントの代わりに privatelink セグメントが必要です。詳細については、以下をご参照ください。

AWS PrivateLink とSnowflake

Azure Private LinkとSnowflake

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 はエラータイプです。返されるエラータイプの詳細については、このトピックのエラーセクションをご参照ください。

コード交換の証明キー¶

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_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 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 フローの完了後に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	リクエストの形式が正しくないか、処理できませんでした。

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

ワークフロー¶

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

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

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

統合の例¶

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

認証エンドポイント¶

範囲¶

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

成功した応答の例¶

失敗した応答の例¶

コード交換の証明キー¶

キーペア認証の使用¶

キーローテーション¶

エラー¶

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