カスタムクライアント用のSnowflake OAuth の構成¶
このトピックでは、カスタムクライアントの 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
セグメントが 必要 です。詳細については、以下をご参照ください。
-
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
セグメントが 必要 です。詳細については、以下をご参照ください。
-
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:クライアントシークレット)
条件:
パラメーター |
データ型 |
必須 |
説明 |
---|---|---|---|
|
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",
}
コード交換の証明キー¶
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 |
無効な |
390305 |
OAUTH_AUTHORIZE_INVALID_STATE_LENGTH |
認証エンドポイントにパラメーターとして提供されたステータスパラメーターが2048文字を超えています。 |
390306 |
OAUTH_AUTHORIZE_INVALID_CLIENT_ID |
指定されたクライアントIDに関連付けられた統合は存在しません。 |
390307 |
OAUTH_AUTHORIZE_INVALID_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 |
リクエストの形式が正しくないか、処理できませんでした。 |
ロールの事前認証ユーザーの同意¶
セキュリティ管理者(つまり、 SECURITYADMIN ロールを持つユーザー)以上は、指定されたロールと統合を使用してユーザーのセッションを開始するクライアントの同意を事前認証できます。この同意は、 ADD DELEGATED AUTHORIZATION のキーワードで ALTER USER を使用して付与されます。この委任された認証がない場合、ユーザーは認証後にロールの同意を認証する必要があります。この委任された認証も取り消すことができます。
詳細については、 OAuth のユーザー同意の管理 をご参照ください。