Chrome拡張からAzure Logic Apps（Consumption）をSASを使わずに安全に呼び出す方法

Question

Chrome拡張からAzure Logic Apps（Consumption）をSASを使わずに安全に呼び出す方法

Tsuzuki Nagai 0

■ 問題

Chrome拡張からAzure Logic Apps（Consumptionプラン）やFunction Appを安全に呼び出す方法について、ベストプラクティスを知りたいです。

現在はHTTPトリガーに対してSAS付きURLを利用していますが、セキュリティ面に課題があると考えています。

■ 背景

Logic AppsはすべてConsumptionプランで構築しています
HTTPトリガー（Request trigger）を公開して外部から呼び出しています
呼び出しには sig を含むSAS付きURLを利用しています
呼び出し頻度は月に100回も無い状況です。

Chrome拡張からこれらの処理をトリガーする要件が新たに発生しました。

■ 現在の動作（再現可能な状態）

以下の方法では正常に動作します：

Chrome拡張
   ↓
HTTP POST（SAS付きURL）
   ↓
Logic Apps 実行

■ 課題（期待値との差分）

現在の方式には以下の課題があります：

SAS付きURLが実質的な認証情報となるため、漏洩時のリスクが高い
Chrome拡張にURLを埋め込む設計に不安がある
呼び出し元ユーザーを識別できない

■ 検討事項

以下の構成を検討しています：

APIMを利用する構成

Chrome拡張
   ↓（OAuth 2.0 / Azure AD）
API Management
   ↓
Logic Apps / Function App

APIMでOAuth 2.0（Azure AD / Entra ID）を有効化
Chrome拡張からアクセストークンを取得してAPIMを呼び出す
Logic Apps / Functionsは直接公開しない

■ 不明点 / 質問

以下についてアドバイスをいただきたいです：

APIMでAzure AD（Entra ID）を利用したOAuth構成のベストプラクティス
- OAuthサーバー設定
- Audience / scope の設計
コストを抑えつつ実現するためのAPIM構成（具体的には今回の要件でConsumptionプランで実装可能でしょうか）

■ 制約条件

できるだけ低コストで運用したい
構成は可能な限りシンプルにしたい

Siddhesh Desai 8,210 評価のポイント Microsoft 外部スタッフモデレーター

2026-06-23T06:09:54.68+00:00

Hi @Tsuzuki Nagai 提供した回答が役に立ったかどうか確認です。もしこれで質問に答えられたなら、回答を承認 => はい をクリックして、評価してください。さらに質問があれば、お知らせください。

1 件の回答

お客様の回答

Siddhesh Desai 8,210 評価のポイント Microsoft 外部スタッフモデレーター

2026-06-23T06:09:54.68+00:00

Hi @Tsuzuki Nagai 提供した回答が役に立ったかどうか確認です。もしこれで質問に答えられたなら、回答を承認 => はい をクリックして、評価してください。さらに質問があれば、お知らせください。

Answer 1

Hi @tsuzu

Microsoft Q&Aにお問い合わせいただき、ありがとうございます。

現在採用されている、SAS（sig）を含むHTTPトリガーURLを使用してAzure Logic Apps（従量課金プラン）を呼び出すというアプローチは、機能的には動作しますが、重大なセキュリティ上の懸念を招くものです。URLに埋め込まれたSASトークンは「共有シークレット」として機能するため、そのURLにアクセスできる人物であれば誰でも、認証やID検証を経ることなくLogic Appを呼び出すことができてしまいます。

この特性により、URLがリバースエンジニアリングされたり漏洩したりする恐れのあるChrome拡張機能のような「パブリッククライアント」からの利用には、この方法は適していません。さらに、SASには呼び出し元のIDに関するコンテキスト（情報）が含まれていないため、ワークフローをトリガーしたのが具体的に誰であるかを特定することも不可能です。たとえOAuthを導入したとしても、SASを有効な状態のままにしておくと、セキュリティ上の「迂回路（バイパス）」が生じてしまいます。

これは、SASによる検証がOAuthとは独立して行われるためであり、有効なSASさえあればOAuthによる認証チェックを完全にスキップできてしまうからです。

この問題を解決するため、あるいは回避策として、以下の点をご参照ください。

SASをOAuth（Entra ID）に置き換え、SASを完全に無効化する Logic App上でOAuth 2.0認証を有効化します（認可ポリシーの設定）。セキュリティ上の迂回路を防ぐため、SAS認証を無効化します。これにより、有効なBearerトークンを提示した呼び出し元のみがLogic Appを呼び出せるようになります。 "accessControl": { "triggers": { "sasAuthenticationPolicy": { "state": "Disabled" } } }
Azure API Management（APIM）をセキュアなゲートウェイとして利用する（推奨設計） Logic AppsやFunction Appsを、Chrome拡張機能に対して直接公開しないでください。 Logic AppsやFunction Appsの前面にAPIMを配置し、認証およびルーティングの処理を一元的に担わせます。推奨される通信フローは以下の通りです。 Chrome拡張機能 → APIM → Logic App / Function App APIMがJWTポリシーを用いてトークンの検証を行い、トークンが有効である場合にのみ、後続のLogic AppやFunction Appへリクエストを転送します。ポリシーの記述例： XML<validate-jwt header-name="Authorization" failed-validation-httpcode="401"> <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" /> <audiences> <audience>api://{api-app-id}</audience> </audiences></validate-jwt> この構成を採用することで、認証処理が一元化され、セキュリティ管理や監視体制が強化されます。
OAuthを正しく設計する（アプリ登録、オーディエンス、スコープ） 2つのアプリ登録を作成します。 APIアプリ（APIM/バックエンドを表す）クライアントアプリ（Chrome拡張機能）最小限のスコープを定義します。例： api://<api-app-id>/invoke.logicapp トークンのオーディエンスがAPIアプリの登録と一致していることを確認してください。これにより、APIMはアクセストークンを適切に検証し、最小権限アクセスを強制できます。
Chrome拡張機能にはPKCEを使用した認可コードフローを使用する Chrome拡張機能はパブリッククライアントであるため、シークレットを保存できません。 PKCEを使用したOAuthフローを使用します（MSALブラウザライブラリ経由）。暗黙的フローは避けてください（非推奨で安全ではありません）。これにより、認証情報を公開することなく、安全なトークン取得が保証されます。
利用状況に基づいた費用対効果の高い導入方法を選択してください。月間呼び出し回数が100回未満の場合：オプションA（最低コスト）： Logic AppでOAuthを直接有効化 APIMは不要オプションB（バランス型／成長を見据えた推奨）： APIMを使用（従量課金制） OAuthとポリシーによる実行ごとの課金どちらの方法もSASの必要性をなくし、セキュリティを大幅に向上させます。
オプションのセキュリティ強化策 Logic Appへのアクセスを制限し、APIMのみが呼び出しできるようにします（ネットワークルールまたは認証）。可能な限り、APIMとバックエンド間でマネージドIDを使用します。 APIMでレート制限またはIPフィルタリングを適用します。