ごきげんよう、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の場合、SAMLアサーションで送信される AuthnContextClassRef は、デフォルトで以下に固定されています。
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
これは、「実際にOkta VerifyやFastPassを使ったかどうか」に関わらず、固定値が送信される仕様です。また、Okta Integration Network（OIN）カタログにあるSalesforceアプリの設定画面には、これを変更する項目が存在しません。
今後の対応について
現状、Oktaの管理画面だけで「MFAの証跡を送る」設定を完結させることは難しい状況です。
ただ、Okta公式ヘルプのPayPal向けの事例などでは、session.amr（認証メソッド参照）という値を属性として渡す方法が案内されています。
Salesforceに関しても、2026年2月の評価開始に向けて、同様の設定手順が案内される可能性があります。また、OINカタログにあるSalesforceアプリが対応するようアップデートされる可能性も視野に入れておく必要があります。こちらもEntra ID同様、AuthnContextの変更は難易度が高いため、2月17日の「AMR属性」評価開始に合わせて、Oktaから「AMRをSAML属性として送る公式手順」が案内されるシナリオが濃厚です。
- 結論：現時点ではSalesforceおよびOktaからの「公式手順の公開待ち」となります。公式情報の更新を注視しつつ、適切なタイミングで対応を検討することが推奨されます。
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： デフォルトでは固定値。Salesforce向けの具体的な設定手順の公開を待つ必要がある。
2026年2月とまだ時間はありますが、ID管理者としては「将来的に対応が必要になるタスク」として頭の片隅に置いておきましょう！
Salesforceや各IdPから正式な手順が公開され次第、このブログ記事でも改めて検証・ご案内したいと思います。
