Function Compute で HTTP トリガーの JSON Web トークン(JWT)認証を設定できます。このようにして、有効なトークンを持つクライアントのみがトリガーにアクセスできます。これは、不正アクセスまたは悪意のあるアクセスをブロックすることにより、HTTP セキュリティの向上に役立ちます。
バックグラウンド
概要
Function Compute では、HTTP トリガーの JWT 認証を有効にできます。JWT (RFC 7519) は、リクエストを認証するための、使いやすいトークンベースのメソッドです。ユーザーステータス情報は、クライアントが提供する tokens に保存されます。関数またはサーバーはトークンを保存しません。したがって、このメソッドはサーバーレスアプリケーションに特に適しています。Function Compute は、HTTP トリガーに構成されているパブリック JSON Web Key Set (JWKS) を使用して、HTTP リクエストに対して JWT 認証を実行できます。Function Compute は、HTTP トリガーの構成に基づいて、claims をパラメーターとして関数に転送します。これにより、関数でのリクエスト認証が不要になり、ビジネスロジックにフォーカスできます。認証プロセスと JWT の tokens に関する基本情報の詳細については、「JWT ベースの認証」および「JSON Web トークンの概要」をご参照ください。
JWT 認証プロセス
上の図は、Function Compute における HTTP トリガーの JWT 認証のワークフローを示しています。このプロセスでは、非対称暗号化アルゴリズムが使用されます。次の項目では、プロセスの詳細について説明します。
クライアントは、カスタム認証サービスに認証リクエストを送信します。ほとんどの場合、クライアントユーザーのユーザー名とパスワードがリクエストで指定されます。
カスタム認証サービスは、リクエスト内のユーザー名やパスワードなどの認証情報を読み取って検証します。リクエストが検証に合格すると、認証サービスは秘密鍵を使用して標準
tokenを生成します。カスタム認証サービスは、
tokenを含むレスポンスをクライアントに転送します。クライアントはtokenをオンプレミスのマシンにキャッシュします。クライアントは、
tokenを含むビジネスリクエストを HTTP トリガーに送信します。HTTP トリガーは、構成済みの公開鍵を使用して、リクエスト内の
tokenを検証します。検証に合格すると、リクエストは保護された関数に渡されます。
保護された関数はレスポンスを処理して返します。
HTTP トリガーは、ビジネスレスポンスをクライアントに転送します。
始める前に
制限
ビジネス要件に基づいて JWT を生成および配布できます。Function Compute は、トリガーに設定されている公開 JWKS を使用して JWT を認証します。
kid(キー ID)のない JSON Web Key(JWK)がサポートされています。トークンは、
header、queryパラメーター(GET メソッドを使用)、フォームパラメーター(POST メソッドを使用)、またはcookieから読み取ることができます。claimsをheaders、queryパラメーター(GET メソッドを使用)、フォームパラメーター(POST メソッドを使用)、およびcookiesとして関数に転送できます。HTTP トリガー用に JWKS を設定できます。JWKS が設定されると、システムは JWKS 内で、
token内の kid と同じkidを持つ公開 JWK を検索し、その公開 JWK を使用してtokenの署名を検証します。トリガーの JWKS は、kidが存在しないか、空の文字列に設定されている JWK を最大 1 つ持つことができます。次の表に、Function Compute の JWT でサポートされているアルゴリズムを示します。
署名アルゴリズム
alg 値
RSASSA-PKCS1-V1_5
RS256、RS384、または RS512
RSASSA-PSS
PS256、PS384、または PS512
Elliptic Curve(ECDSA)
ES256、ES384、または ES512
HMAC
HS256、HS384、または HS512
EdDSA
EdDSA
重要ハッシュベースのメッセージ認証コード(HMAC)署名アルゴリズムは、セキュリティが低い対称暗号化を使用します。セキュリティ強化のため、非対称暗号化アルゴリズムを使用することをお勧めします。
非対称暗号化アルゴリズムを使用する場合は、セキュリティ上の理由から、JWT に秘密鍵ではなく公開鍵に関する情報のみを含める必要があります。
トークンの漏洩を防ぐため、リクエスト内の
tokensなどの機密情報を保護するために HTTPS を使用することをお勧めします。
手順
ステップ 1: JWT 認証を構成する
Function Compute コンソール にログオンします。左側のナビゲーションウィンドウで、[サービスと関数] をクリックします。
上部のナビゲーションバーで、リージョンを選択します。[サービス] ページで、目的のサービスをクリックします。
[関数] ページで、目的の関数の名前をクリックします。表示される [関数の詳細] ページで、[トリガー管理 (URL)] タブをクリックします。
[トリガー管理 (URL)] タブで、HTTP トリガーの [アクション] 列の [変更] をクリックします。
[トリガーの変更] パネルで、次のパラメーターを構成し、[OK] をクリックします。
[認証方式] を [JWT 認証] に設定します。

[JWKS] を構成します。
HTTP トリガーの JWT 認証を構成するには、有効な JWKS を提供する必要があります。 JWKS は手動で生成することも、Web ブラウザーで JSON Web Key generator を検索して mkjwk.org などのオンラインジェネレーターを使用することもできます。 Privacy Enhanced Mail (PEM) 形式のキーがある場合は、jwx などのツールを使用して、キーを JWKS 形式に変換できます。
この例では、mkjwk.org を使用して JWKS を生成します。 JWKS を生成するページで、[X.509 を表示] を [はい] に設定して秘密鍵を表示します。秘密鍵を使用して JWT を発行する必要があります。秘密鍵は安全に保管してください。公開鍵の内容を Function Compute コンソールの JWKS の keys 配列にコピーできます。次の図は詳細を示しています。

サンプルコード:
{ "keys": [ { "alg": "RS256", "e": "AQAB", "kty": "RSA", "n": "u1LWgoomekdOMfB1lEe96OHehd4XRNCbZRm96RqwOYTTc28Sc_U5wKV2umDzolfoI682ct2BNnRRahYgZPhbOCzHYM6i8sRXjz9Ghx3QHw9zrYACtArwQxrTFiejbfzDPGdPrMQg7T8wjtLtkSyDmCzeXpbIdwmxuLyt_ahLfHelr94kEksMDa42V4Fi5bMW4cCLjlEKzBEHGmFdT8UbLPCvpgsM84JK63e5ifdeI9NdadbC8ZMiR--dFCujT7AgRRyMzxgdn2l-nZJ2ZaYzbLUtAW5_U2kfRVkDNa8d1g__2V5zjU6nfLJ1S2MoXMgRgDPeHpEehZVu2kNaSFvDUQ", "use": "sig" } ] }[JWT トークン構成] セクションで、
tokenの位置と名前を選択します。tokenの [読み取り位置] パラメーターを [ヘッダー]、[Cookie]、[クエリパラメーター]、または [フォームパラメーター] に設定できます。tokenの [読み取り位置] パラメーターを [ヘッダー] に設定する場合は、[パラメーター名] と [プレフィックスの削除] パラメーターを指定する必要があります。 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----- <ステップ 1 で生成された X.509 PEM 形式の秘密鍵を使用します> -----END PRIVATE KEY----- """ headers = { "alg": "RS256", "typ": "JWT" } payload = { "sub": "1234567890", "name": "John Snow", "iat": int(time.time()), # トークンが発行された時刻。 "exp": int(time.time()) + 60 * 60, # トークンの有効期間を 1 時間に設定します。 } encoded = jwt.encode(payload=payload, key=private_key.encode(), headers=headers) print("Generated token: %s" % encoded)
Postman を使用して、HTTP サービスにアクセスできるかどうかを確認します。
管理する関数の [トリガー管理 (URL)] タブで、HTTP トリガーのインターネットエンドポイントを取得します。次に、Postman のアドレスバーにエンドポイントを入力します。
Postman の [ヘッダー] タブでトークンパラメーターを構成し、[送信] をクリックしてリクエストを送信します。次の表は、トークンの構成について説明しています。
名前
例
説明
キー
Authentication[JWT トークン構成] セクションで指定したトークンの名前。
値
Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9uIFNub3ciLCJhZG1pbiI6dHJ1ZSwiZXhwIjo0ODI5NTk3NjQxfQ.eRcobbpjAd3OSMxcWbmbicOTLjO2vuLR9F2QZMK4rz1JqfSRHgwQVqNxcfOIO9ckDMNlF_3jtdfCfvXfka-phJZpHmnaQJxmnOA8zA3R4wF4GUQdz5zkt74cK9jLAXpokwrviz2ROehwxTCwa0naRd_N9eFhvTRnP3u7L0xn3ll4iOf8Q4jS0mVLpjyTa5WiBkN5xi9hkFxd__p98Pah_Yf0hVQ2ldGSyTtAMmdM1Bvzad-kdZ_wW0jcctIla9bLnOo-Enr14EsGvziMh_QTZ3HQtJuToSKZ11xkNgaz7an5de6PuF5ISXQzxigpFVIkG765aEDVtEnFkMO0xyPGLgJWT 値。 [JWT トークン構成] の [プレフィックスの削除] パラメーターの値が含まれています。この例では、[プレフィックスの削除] パラメーターは
Bearerに設定されています。重要リクエストヘッダーの JWT パラメーターのプレフィックスとスペースは、[JWT トークン構成] セクションの [プレフィックスの削除] パラメーターのプレフィックスとスペースと同じである必要があります。そうでない場合、トリガーがトークンを解析するときにエラーが発生し、「無効または期限切れの jwt」エラーが報告されます。
カスタムドメイン名で JWT 認証を実行する
前の図は、カスタムドメイン名が HTTP トリガーがリクエストを処理する前にユーザーリクエストを処理することを示しています。 JWT 認証は HTTP トリガーで実行されます。 このセクションでは、カスタムドメイン名が構成されているシナリオで JWT 認証を使用する方法について説明します。
書き換えポリシーが構成されていないカスタムドメイン名
書き換えポリシーが構成されていないカスタムドメイン名にルートが構成されている場合、着信 HTTP リクエストのパスはカスタムドメイン名のパスになります。
たとえば、次の表では、カスタムドメイン名 www.fc-jwt.com のルート ルールについて説明します。 jwt-demo 関数の HTTP トリガーの JWT 構成の [リクエストパスのブラックリスト] パラメーターの値は /fc-jwt/auth/* です。
パス | サービス名 | 関数名 | バージョン |
/fc-jwt/* | jwt | jwt-demo | 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-demo | 1 |
リクエストの URL が /fc-jwt/auth/aliyun の場合、書き換えられた URL は /auth/aliyun になります。 ワイルドカード書き換えルールの詳細については、「書き換えポリシーを構成する(パブリックレビュー中)」をご参照ください。 HTTP トリガーはリクエストを検証しません。 この場合、HTTP トリガーへのリクエストのパスは /auth/aliyun であり、[リクエストパスのブラックリスト] パラメーターの値と一致しません。
[リクエストパスのブラックリスト] パラメーターを /auth/* に設定すると、HTTP トリガーは、URL が /fc-jwt/auth/aliyun のリクエストに対して JWT 認証を実行します。