Outlook デスクトップの Office アドインで SSO を使うと、取得したトークンの amr から "mfa" が消えてしまい、バックエンドで Microsoft Graph 検証が失敗する――そんな現場の“あるある”を、原因から恒久対策、実装テンプレート、運用の勘所まで一気通貫で整理しました。OWA では通るのにデスクトップだけ落ちる理由と、条件付きアクセス（CA）/PRT/Office.js の挙動を絡めて、再現・検証・修復の具体手順を提示します。
前提と想定読者
本記事は、Outlook 用 Office アドイン（Office.auth.getAccessToken() を使用）で、サーバー側（バックエンド）にて受け取った SSO トークンをもとに Microsoft Graph（OBO フローなど）へ進む設計を採用している組織・開発者を対象にしています。Microsoft Entra ID（旧 Azure AD）、条件付きアクセス（Conditional Access: CA）、Windows の PRT（Primary Refresh Token）、WAM（Web Account Manager）の基礎知識がある方を想定しています。
事象の要約（症状）
- Outlook アドイン内で
Office.auth.getAccessToken()を呼び、得たトークンをバックエンドへ送信して検証。 - OWA（Outlook on the Web）では成功するが、Outlook デスクトップでは AADSTS50076（MFA が必要）などのエラーで失敗。
- 差分を確認すると、デスクトップで得られるトークンの
amr（Authentication Methods References）配列に"mfa"が含まれない。一方 OWA 側のトークンには"mfa"が入っている。
| 環境 | ユーザー操作 | トークンの amr | バックエンド検証 |
|---|---|---|---|
| OWA（ブラウザ） | 通常アクセス | ["pwd","mfa"] 等 | 成功（MFA 満たす） |
| Outlook デスクトップ | 同一ユーザー | ["pwd"] / ["wia"] など（"mfa" なし） | 失敗（サーバーが "mfa" を必須として拒否） |
結論（まず答え）
| 課題 | 結論・ポイント |
|---|---|
| 失敗の直接原因 | バックエンドがトークンの amr に "mfa" を要求しており、デスクトップで得られたトークンに "mfa" が入っていないため、検証で拒否される。 |
なぜデスクトップのみ "mfa" が欠落？ | Outlook デスクトップは Windows の PRT によるサイレント SSO（WAM）を多用。過去に パスワードのみ で発行された PRT を保持していると、その性質を引きずったトークンが払い出され、amr に "mfa" が反映されない。ブラウザ（OWA）はインタラクティブ認証が発生しやすく、MFA が都度適用されやすい。 |
| CA で MFA を必須にすれば直る？ | はい。条件付きアクセスで MFA（もしくは認証強度）を必須にし、対象（Office 365 / 当該アドインのエンタープライズアプリ / 該当ユーザー）を適切にスコープすると、PRT の更新を契機にデスクトップでも同等強度のトークンが付与される。 |
内部メカニズムの整理：OWA と Outlook デスクトップの違い
同じユーザーでも SSO を開始する起点 が異なれば、得られるトークンの amr が変わり得ます。
| 観点 | OWA（ブラウザ） | Outlook デスクトップ（WAM + PRT） |
|---|---|---|
| SSO の土台 | ブラウザのセッション／クッキー | Windows サインインで取得済みの PRT（デバイスバウンド） |
| インタラクティブ認証の発生しやすさ | 高い（チャレンジ時に即プロンプト） | 低い（サイレント取得を最優先） |
amr に "mfa" が入りやすい？ | 入りやすい | PRT の作成時の強度に依存（古い/弱い PRT だと欠落しやすい） |
| 代表的な失敗 | 同意不足/権限不足 | AADSTS50076/50079 等の MFA 要求 |
トークン獲得の流れ（簡易図）
ユーザー（Outlook デスクトップ）
└─ Windows サインイン（PRT 取得）
└─ Outlook + WAM が PRT からトークン取得
└─ Office アドインの SSO（getAccessToken）
└─ バックエンドへトークン送付
└─ Graph/OBO へ（サーバー側）このチェーンの最初の「PRT」が MFA で作られていないと、下流のトークンの amr からも "mfa" が消えがちです。
"mfa" 欠如は本当に失敗の直接原因？
多くの組織では、API ゲートウェイやバックエンドで 「amr に "mfa" を含むこと」を明示条件にしています。そのため "mfa" がなければ 意図通り 拒否されます。Graph 側も、より強い認証を要求したい場合に 401 とともに claims challenge を返却しますが、Outlook デスクトップの SSO（サイレント取得）では即時の再認証に乗れず、ユーザーが“何もしていない”のに連鎖的に失敗する構図が生まれます。
言い換えると、失敗の直接原因は「サーバー側のポリシー（amr に "mfa" 必須）」と「クライアントが出すトークンの強度不一致」です。
恒久対策の全体像（優先度順）
- 条件付きアクセス（CA）で MFA / 認証強度を必須化
対象ユーザー、クラウドアプリ（Office 365 とアドインのエンタープライズアプリ）を正しくスコープし、アクセス制御で「多要素認証を要求」または「認証強度（例：多要素 / フィッシング耐性）」を必須にします。 - PRT の更新を確実に発生させる
CA 変更後も、古い PRT を持つ端末はしばらく弱いままです。Windows からの再サインイン、職場アカウントの再接続、Windows Hello for Business（WHfB）の再登録などで PRT を作り直します。 - サーバー側の検証を「amr 直読み」から段階的に改善
amrのみに依存せず、claims challenge をハンドリングする設計や、CA の認証強度（Authentication Strength）基準に合わせた判定へ進化させます。
| 対策 | 効き目 | 副作用/留意点 |
|---|---|---|
| CA で MFA 必須（または認証強度） | 高（最優先） | 適切なスコープ設計が必須。既存ワークロードへの影響評価を忘れない。 |
| PRT 再発行（再サインイン/WHfB 再登録） | 中〜高（即効性あり） | ユーザー周知・手順整備が必要。リモート端末は計画的に。 |
| バックエンドの柔軟化（claims challenge 対応） | 中（将来耐性） | クライアントとの追加往復を設計。UI/UX とセキュリティの両立が鍵。 |
実装手順（代表例・詳細）
1) 条件付きアクセスを新規作成
- 割り当て（対象）：影響ユーザー／グループ
- クラウドアプリ：Office 365 と、アドインのエンタープライズ アプリ（Azure ポータルで登録済みのアプリ）
- 条件：デバイス・場所はまず制限なし（段階的に厳格化）
- アクセス制御：「多要素認証を要求」
※認証強度ポリシーを使う場合は「多要素」や「フィッシング耐性」を選択
公開前にパイロットグループで検証し、既存アプリやサービスに与える影響を確認します。
2) 既存 PRT の更新を促す
CA を変更しても、端末に保持された“古い” PRT は自動で即更新されません。以下のいずれかを実施してユーザー側で PRT を再取得させます。
- Windows の「アカウント」から職場/学校アカウントをいったんサインアウト→サインイン
- Windows を完全サインアウト→サインイン（機器再起動を推奨）
- Windows Hello for Business の再登録（PIN 再設定など）
確認には dsregcmd /status でデバイス結合状態をチェックし、Outlook 側は「ファイル > Office アカウント」でサインインのやり直しを案内すると確実です。
3) SSO トークンの検証強化（サーバー側）
amr 直読みは分かりやすい反面、実装依存です。段階的に以下へ移行します。
- claims challenge の取り込み：Graph などから 401 + WWW-Authenticate が来たら、クライアントへ“より強い認証が必要”の事実を返し、再取得フローへ誘導。
- 認証強度ベースの設計：CA 側の認証強度（多要素/フィッシング耐性）に合わせ、満たさない場合は UI で追加認証を促す。
4) クライアント（アドイン）側の実装ポイント
Office.auth.getAccessToken()の呼び出しは、必要に応じ インタラクティブ許可（サインイン/同意プロンプト許可）を有効化。- サーバーからの「追加強度が必要」応答を受け取ったら、ダイアログ API 等を用いて明示的な再認証導線を出す。
- Outlook デスクトップで失敗→OWA にフォールバックできる一時的 UI（ユーザー教育とセット）も現場では有効。
コード例（サーバー側：Node.js）
以下は amr に "mfa" が無い場合に 403 を返し、クライアントで追加認証を促す最小構成の例です。
// verifyToken.js（概念コード）
const jwt = require("jsonwebtoken");
function hasMfaAmr(decoded) {
const amr = decoded.amr || [];
return amr.includes("mfa");
}
module.exports = function verify(req, res, next) {
const token = (req.headers.authorization || "").replace(/^Bearer\s+/i, "");
try {
const decoded = jwt.decode(token, { complete: false }) || {};
if (!hasMfaAmr(decoded)) {
// ここで claims challenge を返してもよい（簡略化のため省略）
return res.status(403).json({
error: "MFA_REQUIRED",
message: "この操作には多要素認証が必要です。再サインインしてください。"
});
}
// 以降、OBO で Graph アクセスなど
next();
} catch (e) {
return res.status(401).json({ error: "INVALID_TOKEN" });
}
};より厳密には、Graph からの claims challenge をパススルーして、クライアントが再取得時に強制的に高強度でのサインインに乗れるよう実装します（組織の UX 方針に合わせて調整）。
検証・運用の実務手順（チェックリスト）
- 再現性の確認：同一ユーザーで OWA は成功 / デスクトップで失敗か？
amr差分を記録。 - PRT の状態確認：端末で
dsregcmd /status。職場アカウント結合・SSO 状態・WHfB が有効か。 - CA 適用の可視化：パイロットグループに CA 適用 → サインインログで適用結果を確認。
- トークン検証ログ：バックエンドで
amr/auth_time/tid/oidをログ出力。 - ユーザー周知：「Windows へ再サインイン」「Office アカウントのサインアウト/サインイン」を周知。
- ロールバック計画：CA 導入の影響時に即時切替できるよう段階公開。
| 確認観点 | 見る場所 | 期待/判定 |
|---|---|---|
| デバイス結合 | dsregcmd /status | AzureAdJoined/Enterprise 各種が YES |
| PRT 由来トークン | Outlook デスクトップ SSO | amr に "mfa" が入る |
| CA の効き | サインインログ / 実機 | MFA が強制され、OWA/デスクトップで同等結果 |
よくある誤解と正しい理解
| よくある誤解 | 正しい理解 |
|---|---|
「amr の "mfa" さえ入っていれば安全」 | 安全性は 全体設計 依存。CA の認証強度・デバイス準拠・セッション制御と合わせて評価する。 |
| 「Outlook デスクトップは OWA より弱い」 | 弱いわけではない。PRT の作成時強度を踏襲しやすいだけ。PRT を作り直せば同等以上の強度を得られる。 |
| 「MFA 必須にすると業務が止まる」 | パイロットと段階展開をすれば影響最小化可能。WHfB/FIDO2 等のフィッシング耐性 MFA は UX も良い。 |
「サーバーで amr を見る以外に方法がない」 | claims challenge の活用や CA の認証強度と連動させるなど、より堅牢な選択肢がある。 |
トラブルシューティングの実践テクニック
- トークンの中身を可視化：
amr、auth_time、idp、tidを確認。再発時に備えてスクリーンショットや JSON をナレッジに蓄積。 - Outlook の更新：最新チャネルを適用。WAM/モダン認証が確実に使われる状態に。
- プロキシ/SSO 競合：企業プロキシや認証アドオンが WAM のトークン取得を阻害しないか検証。
- 最小構成での再現：新規プロファイル・クリーンなテスト端末で PRT を作り直して挙動差を切り分け。
ログ収集の観点
- サーバー：リクエスト ID、ユーザー/テナント、
amr、応答コード、Graph からの claims 指示、再試行回数。 - クライアント：
getAccessTokenのオプション、失敗イベント、ユーザープロンプト表示有無。 - 端末：イベントビューアの AAD/WAM ログ（エラー/警告）。
一時回避策（暫定）
- OWA フォールバック：業務継続を優先し、デスクトップで失敗した場合は OWA へ誘導（CA 適用後は撤廃）。
- 追加チャレンジの UI：
"mfa"欠如時は、即 403 で落とすのではなく、「再サインインしてください」 を返却。ユーザーが自身で PRT を更新できる導線を整備。
ただし、暫定策は永続化せず、CA による恒久対策へ早期に移行することを推奨します。
開発者向け補足：Office アドインとトークン設計
- SSO トークンの役割：
Office.auth.getAccessToken()が返すトークンは、バックエンドで OBO に進むための“足がかり”。アドインから直接 Graph を叩かず、サーバーで集中管理する方が監査・回収が容易。 - プロンプトの許可：ユーザー体験とセキュリティの両立には、アドイン側で「必要に応じたインタラクティブ」を許容する設計が鍵。
- テナント間動作：B2B 来訪者やマルチテナント構成では、
tidと CA の適用境界に注意。テナント外ユーザーにも CA を適用する設計が必要。
セキュリティ設計のベストプラクティス
- ゼロトラスト前提：常に検証 を基本に、強い認証・デバイス準拠・セッション制御を併用。
- フィッシング耐性 MFA：WHfB / FIDO2 / 証明書ベースなどの強固な要素を優先。ユーザー体験も向上。
- 最小権限：Graph のスコープを最小化し、同意の範囲と有効期限を厳格に運用。
ケーススタディ：段階導入の進め方
- フェーズ 0（観測）：失敗ケースを収集し
amr差分をカタログ化。対象ユーザー/端末/ネットワークを可視化。 - フェーズ 1（小規模 CA）：パイロットに CA（MFA 必須）を適用し、PRT 再発行を手順化。
- フェーズ 2（本番 CA）：全体へ展開。バックエンドは claims challenge 対応を完了。
- フェーズ 3（最適化）：認証強度を「フィッシング耐性」へ引き上げ、
amr依存から脱却。
まとめ（要点の再掲）
- 失敗の直接原因は、サーバーが
"mfa"を必須とし、Outlook デスクトップがamrに"mfa"を含まないトークンを出す不一致。 - 根本は PRT の強度に起因。CA で MFA/認証強度を必須化し、PRT を作り直すのが王道。
- 短期は UI/運用でしのぎ、長期は claims challenge と認証強度ベースへ移行して堅牢化。
付録：実務に使えるテンプレート（運用文面）
ユーザー向け通知例：
【重要】Outlook アドイン利用前の再サインインのお願い
以下の手順で Windows への再サインインを実施してください。
1) Windows をサインアウトし、もう一度サインイン（PC 再起動を推奨）
2) Outlook を開き、［ファイル > Office アカウント］で組織アカウントを一度サインアウト→サインイン
3) アドインを起動してサインインし直す
※所要数分。作業は勤務時間内に実施してください。開発チーム用チェックリスト：
- CA：対象/クラウドアプリ/アクセス制御のスコープ定義は完了している。
- PRT 切替：再サインインの手順書とヘルプデスク対応を準備。
- サーバー：
amrログ、有事の claims challenge パススルー実装がある。 - クライアント：インタラクティブ再認証の UI を備える。
- 品質保証：OWA/デスクトップで同一テストを回し、
amrと結果を突合。
Q&A（ピンポイント）
Q. Windows Hello でサインインしているのに "mfa" が入らないことがあるのは？
認証方法の表現（amr の値）は環境や時期により差があります。CA の「認証強度」を基準にすることで、amr 値の揺らぎに引きずられない運用が可能です。
Q. amr 以外の見るべきクレームは？auth_time（最終インタラクティブ認証時刻）、tid/oid（テナント/ユーザー）、必要に応じ scp/roles。監査にはサインインログも活用します。
Q. Outlook 以外の Office（Teams/Excel）のアドインにも関係する？
はい。WAM/PRT を使うクライアントでは同様の傾向が見られます。CA と PRT の設計で横断的に解決します。
参考実装：サーバーの段階的応答デザイン
| 判定 | サーバー応答 | クライアント動作 |
|---|---|---|
amr に "mfa" あり | 200（処理続行） | 通常フロー |
amr に "mfa" なし | 403（MFA_REQUIRED） | UI で再サインイン導線（OWA フォールバックを案内可） |
| Graph から claims challenge | 401 + claims をクライアントへパススルー | ダイアログで強制再認証 → 再取得 |
最後に（運用のコツ）
- PRT の寿命感：おおむね長寿命・自動更新ですが、ポリシー切替の反映にはユーザー操作が近道。
- ナレッジの共通化：
amr差分と再現条件を記録し、ヘルプデスクの初動手順に落とし込む。 - 一貫性：Exchange/SharePoint/他 SaaS を横断して CA を統一し、抜け漏れを作らない。
“OWA は通るのにデスクトップで落ちる”――このギャップは、PRT × CA × 実装の三位一体で必ず埋められます。今日からパイロットを始め、段階的に“強いが使いやすい” SSO 体験へ育てましょう。
コメント