MENU
  1. ホーム
  2. ソフトウェア
  3. Teams
  4. Teamsタブアプリで発生するSSOエラーを解消！「App resource defined in manifest and iframe origin do not match」の原因と対策

Teamsタブアプリで発生するSSOエラーを解消！「App resource defined in manifest and iframe origin do not match」の原因と対策

Teams

さまざまな企業で採用が広がるMicrosoft Teamsタブアプリの開発では、Azure ADとの連携を通じたシングルサインオン(SSO)が非常に重要です。ところが、設定を一通り済ませたはずなのに「App resource defined in manifest and iframe origin do not match」というエラーに直面することも珍しくありません。本記事では、具体的な対策や設定手順のポイントを分かりやすく解説します。

目次
  1. SSOエラーが発生する背景
    1. リソースURIとiframeオリジンの関連性
  2. ReactとFluent UIによる実装のポイント
    1. Teams ToolkitやMSALの活用
  3. Azure ADでのアプリ登録と設定
    1. Teamsのmanifest設定
  4. 具体的なエラー原因と対策
  5. 最終的な解決策の手順
  6. ローカル開発と本番環境での注意点
  7. SSOトークン取得フローのデバッグ
  8. 実際の成功事例: 「api://mydomain.com/{AppID}」への変更
  9. ベストプラクティスとまとめ

SSOエラーが発生する背景

SSOエラー「App resource defined in manifest and iframe origin do not match」は、Teams上で動作するタブアプリのドメイン情報やアプリ登録時のリソースURIに齟齬があるときに起こりやすい現象です。特に、Azure AD側で設定したApplication ID URIとTeamsのmanifestファイル内のwebApplicationInfo.resourceの設定が一致しない場合に頻発します。

また、Teamsタブアプリで表示されるページはiframeとして埋め込まれますが、iframeのオリジン(ドメイン＋ポート)とAzure ADのアプリに登録された情報が微妙に異なる場合もエラーを引き起こす原因となります。ローカル開発環境でポート番号が変わる、またはSSL証明書を導入していないなど、設定の相違によって起こるケースが多々存在します。

リソースURIとiframeオリジンの関連性

Teamsタブアプリでは、下記のフローでユーザーの認証情報が取得されます。

  1. ユーザーはTeams上でタブを開く
  2. タブ内で埋め込まれたiframeを通じてアプリが表示される
  3. ReactやFluent UIなどで構築されたフロントエンドが、SSOトークンを取得しようとする
  4. Azure ADに登録されたアプリケーション情報をもとにトークンが返却される

この際、Azure ADに登録したApplication ID URIと、Teamsのmanifestファイルに記載のwebApplicationInfo.resourceが一致しないと、正当なリソースとして認識できず「App resource defined in manifest and iframe origin do not match」といったエラーが返ってきます。

ReactとFluent UIによる実装のポイント

Microsoft TeamsタブアプリでSSOを実装する場合、多くのプロジェクトではフロントエンドにReactとFluent UIを組み合わせることが一般的です。UIパーツを素早く整えられるメリットがありますが、SSO部分は別途Azure ADアプリ登録の正確な設定が不可欠です。

Teams ToolkitやMSALの活用

  • Teams Toolkit: Visual Studio Code上での開発をスムーズに進めるための拡張機能。Azure ADアプリ登録などを自動的に行ってくれるケースもありますが、複数の環境(開発/ステージング/本番)で異なる設定が必要になる際は、手動での微調整が必要です。
  • MSAL (Microsoft Authentication Library): フロントエンドからトークンを取得するときに利用されるライブラリ。Teams SDKと組み合わせて使われることが多く、例えば@azure/msal-browserなどが代表的です。clientIdやauthority、そしてredirectUriの設定に注意が必要になります。

関連パッケージの確認

以下に、ReactやFluent UIのセットアップに加えて確認しておきたい主要パッケージを示します。これらが正しくインストールされ、バージョンが互いに適切であるかもチェックポイントとなります。

パッケージ名役割メモ
@microsoft/teams-jsTeamsのSDK。タブアプリ内部での各種操作をサポート。現在は@microsoft/teams-jsのv2などが推奨
@azure/msal-browserブラウザ環境でのMSAL実装。SSOでトークン取得に利用。バージョンアップが頻繁なため更新に注意
reactフロントエンドフレームワークバージョン差異に注意
@fluentui/reactMicrosoftが提供するUIコンポーネント群アプリケーションのUI一貫性を保つ

Azure ADでのアプリ登録と設定

TeamsタブアプリのSSOを確立するうえで、Azure AD上での設定が最も重要です。必要となる設定項目は以下のとおりです。

  1. アプリケーションの登録
    Azure AD管理ポータルで新しいアプリケーションを登録します。名前、リダイレクトURIなどを指定し、本番用と開発用で分けて作成すると管理しやすくなります。
  2. リダイレクトURI
    ローカル環境ならhttps://localhost:ポート、本番環境ならhttps://myproductiondomain.comなど、実際にiframeのオリジンとなるドメインを設定します。間違ってHTTPやポート番号を省略すると、SSOトークンが正しく返されません。
  3. Application ID URI
    Azure AD上で指定するリソースURIです。SSO実装時はここが特に重要です。
    例： api://mydomain.com/{AppID}
    多くのチュートリアルではapi://で始まるURIを推奨しています。ドメイン＋AppIDなどユニークになる形で指定することが推奨されています。
  4. 認証の種類(Access tokens, ID tokens)
    「アクセストークンを有効にする」「IDトークンを有効にする」のチェックボックスを必要に応じてオンにします。タブアプリからはIDトークンを使うケースが多いですが、バックエンドと連携させる場合はアクセストークンも必要になります。

Teamsのmanifest設定

Teamsアプリを登録する際のmanifestファイル内では、下記のようにwebApplicationInfoを定義します。

{
  "webApplicationInfo": {
    "id": "my-aad-app-client-id",
    "resource": "api://mydomain.com/my-aad-app-client-id"
  }
}
  • id: Azure ADポータルで取得したクライアントID(アプリケーションID)
  • resource: Azure ADで設定したApplication ID URI

これらが食い違うとTeamsのSSO認証時にエラーが発生します。また、ここで指定したresourceの文字列と、Azure ADアプリ登録画面で設定したApplication ID URIが完全一致している必要がある点が最大の注意事項です。

具体的なエラー原因と対策

本題である「App resource defined in manifest and iframe origin do not match」エラーについて、ありがちな原因と対策を以下の表にまとめます。

原因想定するミス対応策メモ
Azure ADのApplication ID URIとTeams manifestのwebApplicationInfo.resourceが一致していない誤ってapi://{AppID}、またはapi://localhost/{AppID}などを設定してしまった本番ドメインの場合はapi://mydomain.com/{AppID}のように、FQDNを含む形で両方を合わせる一文字でもずれると認証に失敗
リダイレクトURIの設定ミスHTTPSをHTTPで登録している、ポート番号が合っていないAzure ADポータル上で正しいプロトコルとポート番号を設定。例：https://localhost:53000ローカル開発時と本番環境で複数のリダイレクトURIを設定する必要がある場合が多い
iframeで表示されるドメインとAzure AD登録が食い違っているlocalhostと127.0.0.1を混在させてしまったり、別ドメインを指定してしまったlocalhostで開発する場合も本番ドメインに合わせたFQDN形式の設定が必要な場合がある。TeamsのSSOデバッグ時は特に注意SSLを導入していないとエラーになるケースもある
id（クライアントID）が誤っている複数のアプリ登録を行った結果、別のアプリのクライアントIDを配置しているmanifestファイルとAzure ADポータルの「アプリケーション(クライアント)ID」が対応するか要確認桁数が同じでも文字列が違うため注意
MSALやTeams SDKの設定に不備があるauthorityやclientIdが誤っている、あるいは許可されたスコープの設定が正しくないMSALの初期化部分とTeams SDKからの呼び出し箇所で設定の整合性を確認スコープ設定が不足しているとトークンが取得できない

最終的な解決策の手順

本番ドメインを踏まえた設定例をもとにした、具体的な解決策のフローを整理します。

  1. Azure AD上でFQDN形式のApplication ID URIを設定
    例：api://mydomain.com/{AppID}
    開発環境を切り替える際は、api://dev.mydomain.com/{AppID}のようにステージング専用のアプリ登録を行うのも一案です。
  2. Teams manifestのwebApplicationInfo.resourceを合わせる
    例：
{
     "webApplicationInfo": {
       "id": "xxxxx-xxxxx-xxxxx", 
       "resource": "api://mydomain.com/xxxxx-xxxxx-xxxxx"
     }
   }

ここでidの値はAzure ADの「アプリケーション(クライアント)ID」を正確に入力します。

  1. リダイレクトURIを正しく登録
  • ローカル環境ならhttps://localhost:53000
  • 本番環境ならhttps://mydomain.comなど
    チーム内で複数の開発者が異なるポートを使う場合は、各自が使うポートごとにAzure ADに登録するか、極力ポートを固定しておくと混乱が少なくなります。
  1. MSAL/Teams SDKの設定確認
    authorityやclientId、スコープなどが正しく設定されているか最終チェックを行います。特にスコープでapi://mydomain.com/{AppID}/.defaultのように指定するケースでは、URIと一致している必要があります。
  2. Teamsアプリを再インストール/更新
    manifestを修正した後は、一度Teams上で更新手続きを行う必要があります。特に組織内で公開しているアプリであれば、管理者承認プロセスが走る場合もあるため、更新のタイミングを慎重に計画します。

ローカル開発と本番環境での注意点

SSOの設定は、ローカル開発と本番環境で大きく異なる部分があります。ローカル開発時はlocalhostを使うことが多いですが、本番環境では独自ドメイン＋HTTPS化が必須になるケースが多いです。下記の点を意識すると移行のトラブルを減らせます。

  • HTTPS対応
    本番ではHTTPSが基本です。Azure ADもHTTPS以外のリダイレクトURIを受け付けない設定を推奨しています。ローカル環境でも自己署名証明書を使うなどしてHTTPSで開発を行うと、本番とのギャップが埋まりやすくなります。
  • ポート番号
    ローカル開発で53000番ポートを使っている場合、本番では標準の443にするなど切り替えが発生します。複数のリダイレクトURIを登録していても、余計なURIはなるべく整理しておくとエラーリスクが軽減します。
  • ドメイン名
    ローカルでlocalhost、本番でmydomain.comとなるため、Application ID URIやwebApplicationInfo.resourceも都度変更が必要です。テスト環境でも独自ドメインを用意している場合は、別々のアプリ登録を作るのが安全です。

SSOトークン取得フローのデバッグ

TeamsタブアプリでSSOのデバッグを行う場合、以下の方法が役立ちます。

  1. ブラウザの開発者ツール
    ネットワークタブでトークンリクエストが成功しているか、レスポンスはどうなっているかを確認できます。エラーがあれば詳しいメッセージが返されることが多いです。
  2. TeamsのDeveloper Previewモード
    開発者プレビューを有効にすると、最新のTeams機能が利用できたり、エラー発生時の詳細情報が表示されやすくなります。
  3. MSALのログレベル調整
    MSALにはログのレベルを指定する設定があるため、詳細ログを出すことで原因特定がスムーズになります。

実際の成功事例: 「api://mydomain.com/{AppID}」への変更

あるプロジェクトで、当初は以下のように設定していたために「App resource defined in manifest and iframe origin do not match」エラーが頻発しました。

  • Azure ADアプリ登録画面 → Application ID URI: api://{AppID}
  • Teams manifest → webApplicationInfo.resource: api://{AppID}
  • 実際の運用ドメイン: https://mydomain.com

ここで本番ドメインを加味し、Azure ADのApplication ID URIをapi://mydomain.com/{AppID}に変更し、manifestも同じURIに修正しました。その結果、エラーが解消し、SSOトークンを正常に取得できるようになりました。

ベストプラクティスとまとめ

SSOエラーを回避するためには、以下のベストプラクティスを押さえておくと安心です。

  1. ドメインとURIを厳格に管理
    開発・テスト・本番と複数の環境がある場合は、それぞれに対応したApplication ID URIを用意し、Teams manifestのresourceも揃えておく。
  2. HTTPSとFQDNの早期導入
    ローカル開発でもHTTPSとFQDNサブドメインを設定しておくと、本番移行時のトラブルを減らせる。
  3. MSAL/Teams SDKのバージョン管理
    バージョンアップによりパラメータや関数の仕様が変わる場合があるため、ドキュメントを定期的に確認しながらメンテナンスする。
  4. トラブルシューティングのログ活用
    開発者ツールやMSALのログ出力などを駆使し、どのタイミングでエラーが発生しているのかを詳細に調べることが大切。
  5. 最終チェックとしての再インストール
    manifestを修正したら、Teams上のタブアプリを再インストールまたは更新する。更新が反映されずに古いmanifestのままテストをしてしまうと、正しい結果を得られない。

以上の対策を講じることで、TeamsタブアプリにおけるSSO実装時の「App resource defined in manifest and iframe origin do not match」エラーを効率よく解消できます。FQDNを用いたApplication ID URIの設定が最も肝心なポイントなので、環境ごとにURIを管理しやすい仕組みづくりを進めておくとよいでしょう。社内ポータルや外部サービスとの連携など、今後ますます需要が高まるTeamsタブアプリを円滑に運用するためにも、早めの対策が重要です。

Teams
Teams React SSO Azure AD

コメント

コメントする

目次
  1. SSOエラーが発生する背景
    1. リソースURIとiframeオリジンの関連性
  2. ReactとFluent UIによる実装のポイント
    1. Teams ToolkitやMSALの活用
  3. Azure ADでのアプリ登録と設定
    1. Teamsのmanifest設定
  4. 具体的なエラー原因と対策
  5. 最終的な解決策の手順
  6. ローカル開発と本番環境での注意点
  7. SSOトークン取得フローのデバッグ
  8. 実際の成功事例: 「api://mydomain.com/{AppID}」への変更
  9. ベストプラクティスとまとめ