ごきげんよう、IDチームのわかなです！
先日、Salesforceのヘルプページにて、外部IdPを利用している環境におけるMFA（多要素認証）の扱いについてのアップデートがありました。
要約すると、「外部IdP側でMFAやったよ！という証拠を、ちゃんとSAMLレスポンスの中に含めて送ってね」 という仕様への変更です。
この記事では、今回の変更でキーワードとなるSAMLの「AuthnContext」について、その仕組みから確認方法、Entra IDとOktaの現時点での対応状況までを解説します。
Salesforceの要件が厳格化される背景
Salesforceは以前から全ユーザーへのMFA必須化を推し進めています。これまでは、「外部のIdP（OktaやEntra ID）でMFAをしていれば大丈夫」という比較的ルーズな評価でした。
しかし今後は、IdPから送られるSAMLレスポンスをSalesforce側がしっかり検査して、本当にMFAが行われたかを自動判定するという仕組みに変わります。
評価開始スケジュール
公式ナレッジに更新があったため、情報を反映しました。
今回は、企業のSSOで最も利用頻度が高いと思われる「SAML」の変更点（2026年開始）にフォーカスします。
- OpenID Connect (OIDC) IdP：2026年1月26日から（当初1月20日から延期）
- SAML IdP の AuthnContext：2026年2月3日から
- SAML AMRリクエスト送信：2026年2月17日から
Salesforceは、AuthnContextClassRefだけでなく、「AMR」または「authnmethodsreferences」という名前の属性も評価することが明記されました。これにより、AuthnContextClassRefを直接変更できないIdP（Okta、Entra ID）でも、AMR属性として認証方法情報を送信すれば対応できる可能性があります。
2月3日（AuthnContext評価開始）から、2月17日（AMR評価開始）までの約2週間は、IdP側の対応が追いつかない「空白期間」となる可能性があります。 この期間中、Entra IDやOktaなどのIdPでMFAを行っていても、Salesforce側がそれを認識できず、一時的に「デバイスの有効化（メールによる本人確認）」が頻発する可能性があります。
「AuthnContext」とは？
ブラウザの拡張機能である「SAML Tracer」などを使うと、実際にIdPからSalesforceへ送られているSAMLレスポンスの中に、以下のような情報が含まれます。
<AuthnStatement AuthnInstant="2026-01-26T05:43:13.524Z" SessionIndex="_d55d85ce-ca0b-4e9f-9b5d-7320c1753b00">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AuthnContextClassRef> というタグの中身で、「本当にMFAをしたのか」が判定されるということです。
Salesforceは2月以降、「MFA実施済み」を示す値が送られてこないと、Salesforce側で追加で認証するようになります。
主要IdPの現状と対応策
実際に企業のメインIdPとして使われている Entra ID と Okta は、どのような値を送っているのでしょうか？ 現時点での検証結果と認識を共有します。
Microsoft Entra ID の場合
当初の記載内容に誤りがあったため修正しました。
Entra IDの条件付きアクセスポリシーで、対象アプリに対して以下を設定しました。
前提条件
Entra IDの条件付きアクセスポリシーで、対象のSalesforceアプリに対して以下を設定します。
- アクセス権の付与を選択
- 「多要素認証を要求する」にチェック
結果
MFAを実施した状態でログインし、SAML Tracerで実際のSAMLレスポンスをキャプチャしました。
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
MFAを実施しても、AuthnContextClassRefの値はPasswordのままでした。
現時点での結論
Entra IDでSalesforceの新しいDevice Activation要件に対応するには、「高度なカスタムクレーム」機能等を使ってAuthnContextClassRefをカスタマイズする方法が考えられます。が、Microsoft Q&Aにて、Entra IDのAuthnContextClassRefはMFA・スマートカード・パスキー等を使用しても変更されないことが「既知の製品制限」として回答されています。
しかし、Salesforce側が受け入れるURI値や属性名を明示していないため、現状では具体的な対応ができません。SalesforceおよびMicrosoftからの追加情報を待つ必要があります。特に、Salesforceが2月17日から「AMR属性」の評価を開始するため、Entra ID側で無理にAuthnContextをいじらず、標準機能で対応しやすい「AMR属性での連携」で解決する可能性が高まっています。まずは2月17日の挙動を待つのが得策でしょう。
Okta の場合
公式ナレッジに更新があったため、情報を反映しました。
Oktaも同様に AuthnContextClassRef は固定値（PasswordProtectedTransport）ですが、こちらは手動で属性を追加することで回避可能であると案内されました。
対応手順
Okta管理コンソールから、以下の手順で設定を行います。
- 対象アプリケーションの選択
Salesforceアプリの管理画面を開きます。
- サインオン設定の編集
- 「サインオン（Sign On）」タブに移動し、「編集（Edit）」をクリックします。
- 属性ステートメントの追加
- 「属性（オプション）」セクションまでスクロールし、以下の通り新しい属性を追加します。
- 名前:
AMR - 名前の形式:
指定なし (Unspecified) - 値:
session.amr
- 名前:
- 「属性（オプション）」セクションまでスクロールし、以下の通り新しい属性を追加します。
この設定により、OktaでMFA（多要素認証）を完了したという情報が AMR 属性としてSalesforceに渡されます。これにより、OktaでのMFA完了情報がSalesforceへ伝わり、重複する認証をスキップできます。
2月3日〜17日の影響を最小限にするために
前述の通り、IdP側の対応が2月17日の「AMR対応」待ちとなった場合、2月3日からの約2週間は、SAMLログイン時にSalesforce側で追加認証（メール確認）が発生する可能性が高いです。
ただし、以下の対策で影響は最小限に抑えられます。
- 回避策：「信頼できるIP範囲」からのアクセス、または既に「デバイスの有効化」済み（Cookie有効）なら追加認証は出ません。
- 対処法：もし画面が出ても、「今後このメッセージを表示しない」にチェックを入れて認証すれば、以降1年間は表示されません。
- 「2月上旬、ログイン時にメール認証が求められたら、コードを入力し『今後表示しない』にチェックを入れて進めてください」と事前に社内アナウンス等で周知することを推奨します。
まとめ
本記事では、SalesforceのMFA要件変更に伴うSAML AuthnContextについて解説しました。
- 変更点： 2026年2月から、SAMLレスポンス内の「AuthnContext」でMFA実施有無が評価される予定。
- Entra ID： MFAを実施してもAuthnContextClassRefはPasswordのまま。対応方法は公式情報待ち。
- Okta：
session.amr属性を手動で追加する。
Salesforceや各IdPから正式な手順が公開され次第、このブログ記事でも改めて検証・ご案内したいと思います。
