すべてのプロダクト
Search
ドキュメントセンター

Function Compute:HTTPトリガーのJWT認証の設定

最終更新日:Sep 09, 2024

HTTPサービスのセキュリティを向上させるために、Function ComputeでHTTPトリガーのJSON Web Token (JWT) 認証を設定できます。 これにより、非認証アクセスが拒否され、悪意のある攻撃がブロックされます。 有効なJWTが設定されているクライアントのみがHTTPサービスにアクセスできます。

背景

概要

Function Computeでは、HTTPトリガーのJWT認証を有効にできます。 JWTは、トークンに基づいてリクエストを認証する方法を定義するオープンスタンダード (RFC: 7519) です。 ユーザステータス情報は、クライアントによって提供されるトークンに格納される。 関数またはサーバーはトークンを保存しません。 したがって、JWT認証はサーバーレスアプリケーションに適しています。 Function Computeは、HTTPトリガー用に設定されたパブリックJSON Webキーセット (JWKS) を使用して、HTTPリクエストにJWT認証を実装できます。 Function Computeは、HTTPトリガーの設定に基づいてクレームを関数に転送します。 このようにして、関数は手動でリクエストを認証する必要なしにビジネスロジックに集中できます。 認証プロセスの詳細とJWTのトークンに関する基本情報については、「JWTベースの認証」および「JSON Webトークンの概要」をご参照ください。

JWT认证プロセス

image

上の図は、Function ComputeのHTTPトリガーに対するJWT認証のワークフローを示しています。 このプロセスでは、非対称暗号化アルゴリズムが使用される。 次の情報は、プロセスの詳細を説明しています。

  1. クライアントは、認証要求をカスタム承認サーバーに送信します。 ほとんどの場合、ユーザーのユーザー名とパスワードはリクエストで指定されています。

  2. カスタム承認サーバーは、認証要求内のユーザー名やパスワードなどの情報を読み取り、検証します。 リクエストが認証を通過した後、サーバーは秘密鍵を使用して標準のトークンを生成します。

  3. カスタム承認サーバーは、トークンを含む応答をクライアントに転送します。 クライアントは、トークンをオンプレミスのマシンにキャッシュします。

  4. クライアントは、トークンを含むビジネスリクエストをHTTPトリガーに送信します。

  5. HTTPトリガーは、設定された公開キーを使用して、リクエスト内のトークンを検証します。

  6. トークンが検証された後、リクエストは保護された関数に渡されます。

  7. protected関数は、要求を処理して応答します。

  8. HTTPトリガーは、ビジネス応答をクライアントに転送します。

前提条件

  • サービスが作成されていること。 詳細については、「サービスの管理」トピックの「サービスの作成」セクションをご参照ください。

  • HTTP関数が作成されます。 詳細については、「関数の管理」トピックの「関数の作成」セクションをご参照ください。

制限事項

  • ビジネス要件に基づいてJWTを生成および配布できます。 Function Computeは、トリガー用に設定されたパブリックJWKSを使用してJWTを認証します。

  • kidなしのJSON Webキー (JWK) がサポートされています。

  • トークンは、ヘッダークエリ (GETメソッドを使用) 、フォーム (POSTメソッドを使用) 、またはcookieパラメーターから読み取ることができます。

  • クレームヘッダークエリ (GETメソッドを使用) 、フォーム (POSTメソッドを使用) 、またはCookieとして関数に転送できます。

  • HTTPトリガーのJWKSを設定できます。 JWKSを設定すると、トークンkidパラメーターに似たパブリックJWKが検索され、トークンの署名を検証するために使用されます。 JWKのkidを1つまで空にしたり、kidを空の文字列に設定したりできます。

    次の表に、Function ComputeのJWTでサポートされているアルゴリズムを示します。

    署名アルゴリズム

    alg

    RSASSA-PKCS1-V1_5

    RS256、RS384、またはRS512

    RSASSA-PSS

    PS256、PS384、またはPS512

    楕円カーブ (ECDSA)

    ES256、ES384、またはES512

    HMAC

    HS256、HS384、またはHS512

    EdDSA

    EdDSA

    重要
    • ハッシュベースのメッセージ認証コード (HMAC) 署名アルゴリズムは、対称暗号化を使用しますが、これは安全性が低くなります。 セキュリティを確保するために、非対称暗号化アルゴリズムを使用することを推奨します。

    • 非対称暗号化アルゴリズムを使用する場合は、セキュリティのために公開鍵に関する情報のみをJWTに含める必要があります。 JTWにプライベートキーを含める必要はありません。

    • HTTPSを使用して、リクエスト内のトークンなどの機密情報を保護し、トークンのリークを防ぐことを推奨します。

手順

手順1: JWT認証の設定

  1. Function Computeコンソールにログインします。 左側のナビゲーションウィンドウで、[サービスと機能] をクリックします。

  2. 上部のナビゲーションバーで、リージョンを選択します。 [サービス] ページで、目的のサービスをクリックします。

  3. [関数] ページで、目的の関数の名前をクリックします。 表示される [機能の詳細] ページで、[トリガー管理 (URL)] タブをクリックします。

  4. トリガー管理 (URL)タブで、HTTPトリガーのアクション列で変更をクリックします。

  5. [トリガーの変更] パネルで、次のパラメーターを設定し、OK をクリックします。

    1. [認証方法][JWT認証] に設定します。

      jwt_auth

    2. 設定JWKS.

      HTTPトリガーのJWT認証を設定するには、有効なJWKSを指定する必要があります。 手動でJWKSを準備するか、WebブラウザーでJSON web Keyジェネレーターを検索して、mkjwk.orgなどのオンラインジェネレーターを使用することができます。 プライバシー強化メール (PEM) 形式のキーがある場合は、jwxなどのツールを使用してキーをJWKS形式に変換できます。

      この例では、mkjwk.orgを使用してJWKSを生成します。 JWKSを生成するページで、Show X.509Yesに設定して秘密鍵を表示します。 プライベートキーを使用してコードでJWTを発行する場合は、安全に保管してください。 Function Computeコンソールで、公開鍵の内容をJWKSのkeys配列にコピーできます。 詳細は以下の図をご参照ください。

      image.png

      サンプルコード:

      {
          "keys": [
              {
                  "alg": "RS256",
                  "e": "AQAB",
                  "kty": "RSA",
                  "n": "u1LWgoomekdOMfB1lEe96OHehd4XRNCbZRm96RqwOYTTc28Sc_U5wKV2umDzolfoI682ct2BNnRRahYgZPhbOCzHYM6i8sRXjz9Ghx3QHw9zrYACtArwQxrTFiejbfzDPGdPrMQg7T8wjtLtkSyDmCzeXpbIdwmxuLyt_ahLfHelr94kEksMDa42V4Fi5bMW4cCLjlEKzBEHGmFdT8UbLPCvpgsM84JK63e5ifdeI9NdadbC8ZMiR--dFCujT7AgRRyMzxgdn2l-nZJ2ZaYzbLUtAW5_U2kfRVkDNa8d1g__2V5zjU6nfLJ1S2MoXMgRgDPeHpEehZVu2kNaSFvDUQ",
                  "use": "sig"
              }
          ]
      }
    3. [JWTトークン設定] セクションで、トークンの読み取り位置とトークンの名前を選択します。

      トークンの読み取り位置パラメーターをヘッダー、Cookie、クエリパラメーター、またはフォームパラメーターに設定できます。 トークンの読み取り位置パラメーターをヘッダーに設定した場合、Function Computeがトークンを取得するときに削除するプレフィックスを指定する必要があります。set_token

    4. では、JWTクレーム変換セクションで、パラメーターを関数に渡す位置、パラメーターの元の名前、およびパラメーターが関数に渡された後のパラメーターの新しい名前を選択します。

      マッピングパラメーターの位置パラメーターをヘッダー、Cookie、クエリパラメーター、またはフォームパラメーターに設定できます。jwt_claim_switch

    5. リクエストマッチングモードを指定します。

      • すべて一致: すべての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トリガーの設定に基づいて、ツールを使用してHTTPサービスに期待どおりにアクセスできるかどうかについて説明します。 このセクションでは、デバッグとテストにPostmanを使用します。

  1. 手順1で生成された秘密鍵を使用してJWTを作成します。

  2. Postmanを使用して、HTTPサービスにアクセスできるかどうかを確認します。

    1. 管理する関数の [トリガー管理 (URL)] タブで、HTTPトリガーのインターネットエンドポイントを取得します。 次に、Postmanページのアドレスバーにエンドポイントを入力します。

    2. Postmanのヘッダーでトークンのパラメーターを設定します。 次の表に、トークンの設定を示します。

      パラメーター

      説明

      Key

      認証

      [JWTトークン設定] セクションで指定したトークンの名前。

      ベアラーeyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9uIFNub3ciLCJhZG1pbiI6dHJ1ZSwiZXhwIjo0ODI5NTk3NjQxfQ.eRcobbpjAd3OSMxcWbmbicOTLjO2vuLR9F2QZMK4rz1JqfSRHgwQVqNxcfOIO9ckDMNlF_3jtdfCfvXfka-phJZpHmnaQJxmnOA8zA3R4wF4GUQdz5zkt74cK9jLAXpokwrviz2ROehwxTCwa0naRd_N9eFhvTRnP3u7L0xn3ll4iOf8Q4jS0mVLpjyTa5WiBkN5xi9hkFxd__p98Pah_Yf0hVQ2ldGSyTtAMmdM1Bvzad-kdZ_wW0jcctIla9bLnOo-Enr14EsGvziMh_QTZ3HQtJuToSKZ11xkNgaz7an5de6PuF5ISXQzxigpFVIkG765aEDVtEnFkMO0xyPGLg

      トークンの読み取りに使用されるヘッダー。 削除するプレフィックスとトークンの間にスペースを残す必要があります。 プレフィックスを除いたヘッダ部分がトークンとして使用される。

    3. HTTPサービスの返された情報を表示するには、[送信] をクリックします。 次の情報が返されます。

      image.png

      返された情報のnametofunctionは、クレームによって関数に渡される名前を示します。

カスタムドメイン名でJWT認証を使用する

image

上の図は、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認証を実行します。

トラブルシューティング

HTTPトリガーのjwt認証を有効にした後に「invalidまたはexpired JWT」が報告されるのはなぜですか。

このメッセージは、JWT認証が失敗したことを示す。 次の原因により、JWT認証が失敗することがあります。

  • トークンの署名または形式が無効です。

  • トークンの有効期限が切れています。

  • トークンのkidがHTTPトリガーのJWKS設定と一致しないか、一致したJWKが不正確で、トークンを正しく検証できません。

HTTPトリガーのjwt認証を有効にした後に「JWTトークンが欠落している」と報告されるのはなぜですか。

このメッセージは、Function ComputeがJWT設定に基づいてトークンを見つけることができないことを示します。 リクエストにトークンが含まれているかどうか、およびトークンの位置と名前が正しいかどうかを確認します。 [JWTトークン設定] セクションの [読み取り位置] パラメーターを [ヘッダー] に設定した場合、トークンを設定するときに [プレフィックスの削除] パラメーターの値を追加し、値とJWTトークンの間にスペースを残す必要があります。 それ以外の場合は、エラーが返されます。

JWT認証には追加料金が発生しますか?

JWT認証を使用する場合、追加料金は発生しません。 デフォルトでは、関数の呼び出し数に基づいて、Function Computeが提供するゲートウェイ関連の機能に対して課金されます。 したがって、JWT認証を有効にするかどうかに関係なく、追加料金は発生しません。