Function ComputeでHTTPトリガーのJSON Webトークン (JWT) 認証を設定できます。 これにより、有効なトークンを持つクライアントのみがトリガーにアクセスできます。 これにより、不正または悪意のあるアクセスをブロックしてHTTPセキュリティを向上させます。
背景
概要
Function Computeでは、HTTPトリガーのJWT認証を有効にできます。 JWT (RFC 7519) は、リクエストを認証するための使いやすいトークンベースの方法です。 ユーザステータス情報は、クライアントによって提供されるトークンに格納される。 関数またはサーバーはトークンを保存しません。 したがって、この方法は、サーバーレスアプリケーションに特に適しています。 Function Computeは、HTTPリクエストに対してJWT認証を実行するためにHTTPトリガー用に設定されたパブリックJSON Webキーセット (JWKS) を使用できます。 Function Computeは、HTTPトリガーの設定に基づいて、クレーム
をパラメーターとして関数に転送します。 これにより、関数ではリクエスト認証が不要になり、ビジネスロジックに集中できます。 認証プロセスの詳細とJWTのトークン
に関する基本情報については、「JWTベースの認証」および「JSON Webトークンの概要」をご参照ください。
JWT认证プロセス
上の図は、Function ComputeのHTTPトリガーに対するJWT認証のワークフローを示しています。 このプロセスでは、非対称暗号化アルゴリズムが使用される。 以下の項目は、プロセスの詳細を説明します。
クライアントは、認証要求をカスタム認証サービスに送信します。 ほとんどの場合、クライアントユーザーのユーザー名とパスワードはリクエストで指定されています。
カスタム認証サービスは、リクエスト内のユーザー名やパスワードなどの認証情報を読み取り、検証します。 リクエストが検証に合格した後、認証サービスは秘密鍵を使用して標準の
トークン
を生成します。カスタム認証サービスは、
トークン
を含む応答をクライアントに転送します。 クライアントは、トークン
をオンプレミスのマシンにキャッシュします。クライアントは、
トークン
を含むビジネスリクエストをHTTPトリガーに送信します。HTTPトリガーは、設定された公開キーを使用して、リクエスト内の
トークン
を検証します。検証に合格した後、リクエストは保護された関数に渡されます。
protected関数は処理して応答を返します。
HTTPトリガーは、ビジネス応答をクライアントに転送します。
始める前に
制限事項
ビジネス要件に基づいてJWTを生成および配布できます。 Function Computeは、トリガー用に設定されたパブリックJWKSを使用してJWTを認証します。
kid
(キーID) を持たないJSON Webキー (JWK) がサポートされています。トークンは、
ヘッダー
、クエリ
パラメーター (GETメソッドを使用) 、フォームパラメーター (POSTメソッドを使用) 、またはcookie
から読み取ることができます。クレーム
をヘッダー
、クエリ
パラメーター (GETメソッドを使用) 、フォームパラメーター (POSTメソッドを使用) 、およびCookie
として関数に転送できます。HTTPトリガーのJWKSを設定できます。 JWKSが設定された後、システムは、
トークン
内のkidと同じkid
を持つパブリックJWKを求めてJWKSを検索し、パブリックJWKを使用してトークン
の署名を検証します。 トリガーのJWKSは、kid
が存在しないか、空の文字列に設定されているJWKを1つだけ持つことができます。次の表に、Function ComputeのJWTでサポートされているアルゴリズムを示します。
署名アルゴリズム
alg value
RSASSA-PKCS1-V1_5
RS256、RS384、またはRS512
RSASSA-PSS
PS256、PS384、またはPS512
楕円カーブ (ECDSA)
ES256、ES384、またはES512
HMAC
HS256、HS384、またはHS512
EdDSA
EdDSA
重要ハッシュベースのメッセージ認証コード (HMAC) 署名アルゴリズムは、弱いセキュリティを提供する対称暗号化を使用します。 セキュリティを強化するために、非対称暗号化アルゴリズムを使用することを推奨します。
非対称暗号化アルゴリズムを使用する場合、セキュリティ上の理由から、秘密鍵ではなく公開鍵に関する情報のみをJWTに含める必要があります。
リクエスト内の
トークン
などの機密情報を保護し、トークンの漏洩を防ぐためにHTTPSを使用することを推奨します。
手順
手順1: JWT認証の設定
Function Computeコンソールにログインします。 左側のナビゲーションウィンドウで、[サービスと機能] をクリックします。
上部のナビゲーションバーで、リージョンを選択します。 [サービス] ページで、目的のサービスをクリックします。
[関数] ページで、目的の関数の名前をクリックします。 表示される [機能の詳細] ページで、[トリガー管理 (URL)] タブをクリックします。
トリガー管理 (URL)タブで、アクション列で、HTTPトリガーの変更をクリックしします。
[トリガーの変更] パネルで、次のパラメーターを設定し、OKをクリックします。
[認証方法] を [JWT認証] に設定します。
設定JWKS.
HTTPトリガーのJWT認証を設定するには、有効なJWKSを指定する必要があります。 JWKSを手動で生成するか、WebブラウザーでJSON web Keyジェネレーターで検索して、mkjwk.orgなどのオンラインジェネレーターを使用することができます。 プライバシー強化メール (PEM) 形式のキーがある場合は、jwxなどのツールを使用してキーをJWKS形式に変換できます。
この例では、mkjwk.orgを使用してJWKSを生成します。 JWKSを生成するページで、Show X.509をYesに設定して秘密鍵を表示します。 JWTを発行するには、秘密鍵を使用する必要があります。 秘密鍵を安全に保つ。 Function Computeコンソールで、公開鍵の内容をJWKSのkeys配列にコピーできます。 詳細は以下の図をご参照ください。
サンプルコード:
{ "keys": [ { "alg": "RS256", "e": "AQAB", "kty": "RSA", "n": "u1LWgoomekdOMfB1lEe96OHehd4XRNCbZRm96RqwOYTTc28Sc_U5wKV2umDzolfoI682ct2BNnRRahYgZPhbOCzHYM6i8sRXjz9Ghx3QHw9zrYACtArwQxrTFiejbfzDPGdPrMQg7T8wjtLtkSyDmCzeXpbIdwmxuLyt_ahLfHelr94kEksMDa42V4Fi5bMW4cCLjlEKzBEHGmFdT8UbLPCvpgsM84JK63e5ifdeI9NdadbC8ZMiR--dFCujT7AgRRyMzxgdn2l-nZJ2ZaYzbLUtAW5_U2kfRVkDNa8d1g__2V5zjU6nfLJ1S2MoXMgRgDPeHpEehZVu2kNaSFvDUQ", "use": "sig" } ] }
JWTトークンの設定セクションで、
トークン
の位置と名前を選択します。トークン
の読み取り位置パラメーターをヘッダー、Cookie、クエリパラメーター、またはフォームパラメーターに設定できます。トークン
の読み取り位置パラメーターをヘッダーに設定した場合、パラメーター名およびプレフィックスの削除パラメーターを指定する必要があります。 Function Computeがトークンを取得すると、[プレフィックスの削除] パラメーターで指定されたプレフィックスが削除されます。重要プレフィックスの削除パラメーターを設定するときに、プレフィックスの後にスペースが存在するかどうかを確認します。 指定したプレフィックスの後にスペースを追加することを推奨します (例:
Bearer
) 。JWTクレーム変換セクションで、パラメーターを関数に渡す位置、パラメーターの元の名前、およびパラメーターが関数に渡された後のパラメーターの新しい名前を選択します。
マッピングパラメーターの位置パラメーターをヘッダー、Cookie、クエリパラメーター、またはフォームパラメーターに設定できます。
リクエストマッチングモードを指定します。
すべて一致: すべてのHTTPリクエストは、JWTを使用して検証する必要があります。
ホワイトリストモード: [リクエストパスのホワイトリスト] で指定されたパスから送信されるHTTPリクエストは、JWTを使用して認証されません。 他の要求は、JWTを使用して認証される。
ブラックリストモード: [リクエストパスのブラックリスト] で指定されたパスから送信されたHTTPリクエストは、JWTを使用して認証されます。 その他のリクエストは、JWTを使用して認証されません。
ホワイトリストモードとブラックリストモードは、次の対応モードをサポートしています。
正確なマッチング
パスは、指定されたパスとまったく同じ場合にのみ一致します。 たとえば、[リクエストパスのブラックリスト] を /aに設定した場合、/aから送信されるリクエストにはJWT認証が必要です。 /a/ から送信されるリクエストには、JWT認証は必要ありません。
ファジーマッチング
ワイルドカードとしてアスタリスク (*) が付加されたパスに値を設定できます。 たとえば、[リクエストパスのブラックリスト] パラメーターを /login/* に設定した場合、/login/ というプレフィックスが付いたパス (/login/aや /login/b/c/dなど) から送信されるリクエストにはJWT認証が必要です。
手順2: HTTPトリガーのJWT設定の確認
このセクションでは、HTTPトリガーのJWT設定に基づいてツールを使用して、HTTPサービスに期待どおりにアクセスできるかどうかを確認する方法について説明します。 このセクションでは、Postmanが使用されます。
手順1で生成されたX.509 PEM形式の秘密鍵を秘密鍵として使用して、JWTを発行します。 次の手順では、Pythonを例として使用して、ローカルスクリプトを使用してトークンを生成するプロセスを示します。
PyJWTモジュールをインストールします。
pip install PyJWT
オンプレミスマシンで次のPythonスクリプトを実行して、JWTを生成します。
import jwt import time private_key = """ -----BEGIN PRIVATE KEY----- <Use the private key in the X.509 PEM format generated in Step 1> -----END PRIVATE KEY----- """ headers = { "alg": "RS256", "typ": "JWT" } payload = { "sub": "1234567890", "name": "John Snow", "iat": int(time.time()), # The time when the token was issued. "exp": int(time.time()) + 60 * 60, # Set the validity period of the token to 1 hour. } encoded = jwt.encode(payload=payload, key=private_key.encode(), headers=headers) print("Generated token: %s" % encoded)
Postmanを使用して、HTTPサービスにアクセスできるかどうかを確認します。
管理する関数の [トリガー管理 (URL)] タブで、HTTPトリガーのインターネットエンドポイントを取得します。 次に、Postmanのアドレスバーにエンドポイントを入力します。
Postmanの [ヘッダー] タブでトークンパラメーターを設定し、[送信] をクリックしてリクエストを送信します。 次の表に、トークンの設定を示します。
名前
例
説明
Key
認証
[JWTトークン設定] セクションで指定したトークンの名前。
値
ベアラーeyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9uIFNub3ciLCJhZG1pbiI6dHJ1ZSwiZXhwIjo0ODI5NTk3NjQxfQ.eRcobbpjAd3OSMxcWbmbicOTLjO2vuLR9F2QZMK4rz1JqfSRHgwQVqNxcfOIO9ckDMNlF_3jtdfCfvXfka-phJZpHmnaQJxmnOA8zA3R4wF4GUQdz5zkt74cK9jLAXpokwrviz2ROehwxTCwa0naRd_N9eFhvTRnP3u7L0xn3ll4iOf8Q4jS0mVLpjyTa5WiBkN5xi9hkFxd__p98Pah_Yf0hVQ2ldGSyTtAMmdM1Bvzad-kdZ_wW0jcctIla9bLnOo-Enr14EsGvziMh_QTZ3HQtJuToSKZ11xkNgaz7an5de6PuF5ISXQzxigpFVIkG765aEDVtEnFkMO0xyPGLg
JWTトークン設定のプレフィックスの削除パラメーターの値を含むJWT値。 この例では、Remove Prefixパラメーターは
Bearer
に設定されています。重要リクエストヘッダーのJWTパラメーターのプレフィックスとスペースは、[JWTトークン設定] セクションの [プレフィックスの削除] パラメーターと同じである必要があります。 それ以外の場合、トリガーがトークンを解析し、「invalidまたはexpired jwt」エラーを報告するときにエラーが発生します。
カスタムドメイン名でJWT認証を実行する
上の図は、HTTPトリガーがリクエストを処理する前に、カスタムドメイン名がユーザーリクエストを処理することを示しています。 JWT認証はHTTPトリガーで実行されます。 このセクションでは、カスタムドメイン名が設定されているシナリオでJWT認証を使用する方法について説明します。
書き換えポリシーが設定されていないカスタムドメイン名
書き換えポリシーが設定されていないカスタムドメイン名に対してルートが設定されている場合、着信HTTPリクエストのパスはカスタムドメイン名のパスです。
たとえば、次の表に、カスタムドメイン名www.fc-jwt.com
のルートルールを示します。 JWT-demo
関数のHTTPトリガーのjwt設定の [リクエストパスのブラックリスト] パラメーターの値は、/fc-jwt/auth/* です。
パス | サービス名 | 関数名 | バージョン |
/fc-jwt/* | jwt | jwt-デモ | 1 |
リクエストのURLが /fc-jwt/auth/aliyunの場合、リクエストのパスが [リクエストパスのブラックリスト] パラメーターで指定された値と一致するため、HTTPトリガーはHTTPリクエストを検証します。
書き換えポリシーが設定されたカスタムドメイン名
書き換えポリシーが設定されたカスタムドメイン名にルートが設定されている場合、受信HTTPリクエストのパスは書き換えられたURLになります。 カスタムドメイン名の書き換え機能の詳細については、「書き換えポリシーの設定 (パブリックレビュー) 」をご参照ください。
たとえば、次の表に示すように、カスタムドメイン名www.fc-jwt.com
のルートルールを設定したとします。 JWT-demo
関数のHTTPトリガーのjwt設定では、[リクエストパスのブラックリスト] パラメーターが /fc-jwt/auth/* に設定され、ワイルドカード書き換えポリシーが設定されています。 一致ルールは /fc-jwt/*
で、置換ルールは /$1
です。
パス | サービス名 | 関数名 | バージョン |
/fc-jwt/* | jwt | jwt-デモ | 1 |
リクエストのURLが /fc-jwt/auth/aliyunの場合、書き換えられたURLは /auth/aliyunです。 ワイルドカード書き換えルールの詳細については、「書き換えポリシーの設定 (パブリックレビュー) 」をご参照ください。 HTTPトリガーはリクエストを検証しません。 この場合、HTTPトリガーへのリクエストのパスは /auth/aliyunで、[リクエストパスのブラックリスト] パラメーターの値と一致しません。
[リクエストパスのブラックリスト] パラメーターを /auth/* に設定した場合、HTTPトリガーは、URLが /fc-JWT /auth/aliyunであるリクエストに対してjwt認証を実行します。