Function Compute で HTTP トリガーの JWT 認証を構成します。これにより、有効な JSON Web トークン (JWT) を持つクライアントのみが HTTP サービスにアクセスできるようになり、セキュリティが強化され、不正アクセスや悪意のある攻撃が防止されます。
背景情報
はじめに
Function Compute は、HTTP トリガーの JWT 認証をサポートしています。RFC 7519 で定義されている JSON Web トークン (JWT) は、トークンベースの認証スキームです。ユーザー状態情報は Token に保存され、クライアントによって提供されます。関数はこの情報を保存しないため、JWT はサーバーレスに適した認証方法です。Function Compute は、HTTP トリガーにバインドされた公開 JSON Web キーセット (JWKS) を使用して HTTP 呼び出しリクエストを認証します。HTTP トリガーの構成に基づいて、Function Compute は claims をパラメーターとして関数に転送します。関数はリクエストを認証する必要がなく、ビジネスロジックのみに焦点を当てます。JWT Token 認証プロセスと基本概念の詳細については、「JWT に基づくトークン認証」と「JWT の概要」をご参照ください。
JWT 認証フロー
上記の図は、Function Compute HTTP トリガーと非対称暗号化を使用した JWT 認証のビジネスフロー全体のシーケンス図を示しています。手順は次のとおりです。
クライアントは、カスタム認証サービスに認証リクエストを送信します。このリクエストには通常、エンドユーザーのユーザー名とパスワードが含まれます。
カスタム認証サービスは、リクエストからユーザー名やパスワードなどの認証情報を読み取り、検証します。検証が成功すると、秘密鍵を使用して標準
Tokenを生成します。カスタム認証サービスは、
Tokenを含む応答をクライアントに返します。クライアントはこのTokenをローカルにキャッシュする必要があります。クライアントは、
Tokenを含むビジネスリクエストを HTTP トリガーに送信します。HTTP トリガーは、ユーザーが構成した公開鍵を使用して、リクエスト内の
Tokenを検証します。検証が成功すると、リクエストは保護された関数に渡されます。
保護された関数はビジネスリクエストを処理し、応答を返します。
HTTP トリガーはビジネス応答をクライアントに返します。
前提条件
制限事項
JWT は任意の方法で生成および配布できます。Function Compute は、トリガーで構成された公開 JWKS を使用して JWT を認証します。
kidがない JWKS もサポートされています。header、Queryパラメーター (GET)、フォームパラメーター (POST)、およびcookieからトークンを読み取ることができます。claimsをheader、フォームパラメーター (POST)、およびcookieとして関数に転送できます。Function Compute は、HTTP トリガー用に JSON Web キー (JWKS) のセットを構成することをサポートしています。JWKS 内で、
Tokenと同じkidを持つ公開 JWK を検索し、この公開鍵を使用してTokenの署名を検証します。トリガーの JWKS では、最大 1 つの JWK が欠落または空のkidを持つことができます。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 に含めてください。秘密鍵情報を含めないでください。
リクエスト内の Token などの機密情報を保護するために HTTPS を使用してください。これにより、
Tokenの漏洩を防ぎます。
操作手順
ステップ 1: JWT 認証の構成
Function Compute コンソールにログインします。左側のナビゲーションウィンドウで、[サービスと機能] をクリックします。
トップナビゲーションバーでリージョンを選択し、[サービス] ページで目的のサービスをクリックします。
[関数] ページで、目的の関数の名前をクリックします。表示される関数の詳細ページで、[トリガー管理 (URL)] タブをクリックします。
[トリガー管理 (URL)] タブで、HTTP トリガーの [操作] 列にある [編集] ボタンをクリックします。
「トリガーの編集」パネルで、次の項目を設定してから、[OK] をクリックします。
[認証方式] を [JWT 認証] に設定します。

[JWKS] を設定します。
HTTP トリガーの JWT 認証を構成するには、有効な JSON Web キーセット (JWKS) を提供します。JWKS を自分で生成するか、JSON Web Key Generator を検索して、mkjwk.org などのオンラインツールを見つけます。PEM 形式のキーをお持ちの場合は、jwx などのツールを使用して JWKS 形式に変換します。
このトピックでは、mkjwk.org を使用して JWKS を生成する方法を説明します。次の図に示すように、生成インターフェイスで、[キー用途] を [署名] に、[アルゴリズム] を [RS256] に、[X.509 を表示] を [はい] に設定します。次に、[生成] をクリックします。コード内で秘密鍵(図の①)を使用して JWT トークンを発行します。秘密鍵は安全に保管してください。公開鍵(図の②)の内容を、コンソール内の JWKS 構成の keys 配列にコピーします。


次の例は、このトピックで構成されている JWKS を示しています。
{ "keys": [ { "alg": "RS256", "e": "AQAB", "kty": "RSA", "n": "u1LWgoomekdOMfB1lEe96OHehd4XRNCbZRm96RqwOYTTc28Sc_U5wKV2umDzolfoI682ct2BNnRRahYgZPhbOCzHYM6i8sRXjz9Ghx3QHw9zrYACtArwQxrTFiejbfzDPGdPrMQg7T8wjtLtkSyDmCzeXpbIdwmxuLyt_ahLfHelr94kEksMDa42V4Fi5bMW4cCLjlEKzBEHGmFdT8UbLPCvpgsM84JK63e5ifdeI9NdadbC8ZMiR--dFCujT7AgRRyMzxgdn2l-nZJ2ZaYzbLUtAW5_U2kfRVkDNa8d1g__2V5zjU6nfLJ1S2MoXMgRgDPeHpEehZVu2kNaSFvDUQ", "use": "sig" } ] }[JWT トークン設定] で、
Tokenの場所およびTokenの名前を選択します。トークンの場所には、ヘッダー、Cookie、クエリパラメーター(GET)、およびフォームパラメーター(POST)がサポートされています。ヘッダーをトークンの場所として選択した場合、パラメーター名 と 削除するプレフィックス を指定します。Function Compute は、トークンを取得する際に 削除するプレフィックス で設定されたプレフィックスの内容を削除します。
重要「削除するプレフィックス」を設定する際は、プレフィックスの後に空白があるかを確認してください。プレフィックス フィールドの後に空白を追加します(例:
Bearer)。JWT クレーム変換 構成で、パラメーターの場所、元のパラメーター名、および関数に渡した後のパラメーター名を選択します。
マッピングされたパラメーターの場所は、Header、Cookie、およびフォームパラメーター (POST) をサポートしています。

リクエストマッチングモードを設定します。
すべて一致: すべてのHTTPリクエストでJWT検証が必要です。
ホワイトリストモード: 「リクエストパスホワイトリスト」に設定されたパスを持つ HTTP リクエストは JWT 検証を必要としません。その他のリクエストは JWT 検証を必要とします。
[ブラックリストモード]: 「リクエストパスのブラックリスト」に設定されたパスを持つ HTTP リクエストは JWT 検証を必要とします。その他のリクエストは JWT 検証を必要としません。
[ホワイトリストモード] および [ブラックリストモード] は、以下の 2 つのマッチングモードをサポートしています。
完全一致
リクエストパスは、設定されたパスと完全に一致する必要があります。たとえば、[リクエストパスブラックリスト] を /a に設定した場合、/a パスからのリクエストには JWT 検証が必要です。/a/ パスからのリクエストには検証は必要ありません。
あいまい一致
ワイルドカード (*) を使用してパスを設定します。ワイルドカード (*) はパスの末尾でのみ使用できます。たとえば、[リクエストパスブラックリスト] を /login/* に設定した場合、/login/ のパスプレフィックスを持つリクエスト(例:/login/a や /login/b/c/d)は JWT 検証を必要とします。
ステップ 2: 操作検証
Postman などのデバッグツールで、HTTP トリガーの JWT 構成に基づいてアクセスエンドポイントとトークンを入力します。HTTP サービスにアクセスできることを確認します。
ステップ 1 で生成された X.509 PEM 形式の秘密鍵を、JWT トークンを発行するための秘密鍵として使用します。次の手順は、ローカル Python スクリプトを使用してトークンを生成する方法を示しています。
PyJWT モジュールをインストールします。
pip install 'PyJWT>=2.0'次の Python サンプルスクリプトをローカルで実行して、JWT トークンを生成します。
import jwt import time private_key = """ -----BEGIN PRIVATE KEY----- <Use the X.509 PEM-formatted private key generated in Step 1> -----END PRIVATE KEY----- """ headers = { "alg": "RS256", "typ": "JWT" } payload = { "sub": "1234567890", "name": "John Snow", "iat": int(time.time()), # Token issuance time "exp": int(time.time()) + 60 * 60, # Set token validity to 1 hour } encoded = jwt.encode(payload=payload, key=private_key.encode(), headers=headers) print("Generated token: %s" % encoded)
Postman を使用して、HTTP サービスにアクセスできることを確認します。
対象の関数の [トリガー管理 (URL)] タブで、HTTP トリガーのパブリックネットワークアクセス エンドポイントを取得し、Postman の URL フィールドに入力します。
Postman の [ヘッダー] で Token パラメーター情報を設定し、次に [送信] をクリックしてリクエストを送信します。次の例では、このトピックで入力された Token を示しています。
名前
例の値
説明
Key
Authentication[JWT トークン設定]で設定されたパラメーター名。
Value
Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9uIFNub3ciLCJhZG1pbiI6dHJ1ZSwiZXhwIjo0ODI5NTk3NjQxfQ.eRcobbpjAd3OSMxcWbmbicOTLjO2vuLR9F2QZMK4rz1JqfSRHgwQVqNxcfOIO9ckDMNlF_3jtdfCfvXfka-phJZpHmnaQJxmnOA8zA3R4wF4GUQdz5zkt74cK9jLAXpokwrviz2ROehwxTCwa0naRd_N9eFhvTRnP3u7L0xn3ll4iOf8Q4jS0mVLpjyTa5WiBkN5xi9hkFxd__p98Pah_Yf0hVQ2ldGSyTtAMmdM1Bvzad-kdZ_wW0jcctIla9bLnOo-Enr14EsGvziMh_QTZ3HQtJuToSKZ11xkNgaz7an5de6PuF5ISXQzxigpFVIkG765aEDVtEnFkMO0xyPGLQ「[JWT トークン設定]」では、JWT トークンを構築する際にプレフィックスを削除するようシステムを設定できます。たとえば、削除するプレフィックスとして
Bearerを指定したと仮定します。重要リクエストヘッダー内のJWTパラメーターのプレフィックスと空白は、[プレフィックスの削除] で設定された内容と一致している必要があります。[JWTトークン設定]。それ以外の場合、トリガーはトークンを解析できず、「無効または期限切れのJWT」というエラーを返します。
カスタムドメイン名での JWT 認証の使用
上記の図に示すように、カスタムドメイン名は HTTP トリガーの前に配置されます。ユーザーリクエストはまずカスタムドメイン名によって処理され、次に 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 リクエストのパスはカスタムドメイン名の書き換えられたパスになります。カスタムドメイン名書き換え機能の詳細については、「書き換えポリシーの構成 (パブリックプレビュー)」をご参照ください。
カスタムドメイン名 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 検証を実行します。