【Okta】Salesforce 連携で今おさえておきたい重要アップデート3選: MFA 二重プロンプト・MFA 強制適用・PKCE 対応

はじめに

こんにちは、ネクストモードのゆきなわです。

ここ数か月、Okta と Salesforce の連携まわりで、ログイン時の認証やプロビジョニングに関わる重要な変更が相次いでいます。いずれも、ログイン時に追加のプロンプトが表示される、Okta から Salesforce へのユーザー連携に影響が出る、といった形で、日々の業務に直接影響しうる内容です。

本記事では、2026年6月時点で特に押さえておきたいアップデートを、何が変わるのか、自社が対象か、いま何をすべきかという観点で整理します。 今回取り上げるのは、次の3つです。

1. Salesforce SSO の MFA 二重プロンプト問題（AMR 属性での解消）: すでに解消済み
2. Salesforce の SSO 認証要件の変更（MFA 強制適用）: 2026年6月22日から段階適用
3. Salesforce プロビジョニングの PKCE 対応: 2026年6月2日現在では移行開始不要

1と2はどちらも、ログイン時に追加のプロンプトが出るという点で似ていますが、原因も対応も異なります。混同しやすいので、先に違いを整理しておきます。

3は SSO ではなく、ユーザープロビジョニング（ユーザーの作成・更新）に関わる話題です。

⚠️本記事は、2026年6月2日時点の公開情報および Okta からの案内に基づいています。適用日や対応要件は今後更新される可能性があるため、実際の対応時には本文中の公式ドキュメントで最新情報をご確認ください。

① Salesforce SSO の MFA 二重プロンプト問題（AMR 属性で解消）

まずは、すでに解消済みの話題から整理します。

Salesforce 社のセキュリティポリシー変更（デバイスアクティベーションの仕様変更）にともない、2026年2月9日以降、SAML SSO でログインするユーザーに対して追加の認証プロンプトが表示される事象が発生していました。

補足：ここでは便宜上 MFA 二重プロンプトと表現していますが、正確には Okta 側で MFA を完了した後に、Salesforce 側のデバイスアクティベーション（具体的にはメールでの確認コード入力などの追加確認）が求められる事象を指します。

対象となる環境と対応

OIN（Okta Integration Network）の公式アプリをご利用の場合は、対応は不要です。 2026年3月26日のプラットフォームアップデートにより、自動的に解消されています（対象は Salesforce.com、Salesforce Portal（Federated ID）、Salesforce（Non-Profit）など）。回避策として手動で追加していた AMR 属性が残っていても競合は発生せず、設定を整理する目的で削除しても差し支えありません。

一方、カスタムの SAML / OIDC アプリをご利用の場合は、手動での設定変更が必要です。 自動修正はカスタムアプリには適用されないため、Okta 管理者がアプリケーションの Sign-On 設定（SAML の場合は Attribute Statements）に次の属性を追加します。

いま必要な対応

• OIN 公式アプリ：対応不要（必要に応じて旧回避策の AMR 属性を整理）
• カスタム SAML / OIDC アプリ：上記 AMR 属性を設定

画面キャプチャ付きの具体的な手順は、以下の弊社ブログで解説しています。設定確認（SAML レスポンスの観測）の方法もあわせてご覧ください。

② Salesforce の SSO 認証要件の変更（MFA 強制適用）

続いて、これから段階的に適用される変更です。 ①と同じくログイン時の追加プロンプトに関わりますが、こちらは Salesforce へのアクセスに MFA を求めるという、別の仕様変更です。Salesforce への直接ログインだけでなく、SSO ログインも対象になります。

Salesforce が求める認証方式は、ユーザーの権限レベルによって分かれています。

• 一般ユーザー：標準 MFA（Okta Verify TOTP、Okta Verify Push など）が必須
• 管理者・特権ユーザー：フィッシング耐性のある MFA（FIDO2 / WebAuthn / Okta FastPass / パスキー など）が必須

ここでいう特権ユーザーとは、System Administrator プロファイル、または Customize Application / Modify All Data / View All Data / Author Apex のいずれかの権限を持つユーザーを指します。適用は、Sandbox 環境から本番環境へと段階的に進みます。

特に注意したいポイント（FastPass と claim の関係）

この変更は、フィッシング耐性のある認証方式を使えばそれで済む、という単純な話ではありません。重要なのは、Okta が送信する認証クレーム（claim）を、Salesforce が MFA 要件を満たすものとして解釈できるかどうかです。特に Okta FastPass を中心に認証設計している環境では、Okta が送信する claim と、Salesforce が MFA として認識する claim（okta_verify / fido2 / webauthn など）の対応関係を確認しておく必要があります。

特権ユーザーについては、FastPass 利用時に発行される phr（phishing-resistant）claim を、Salesforce がそのままフィッシング耐性 MFA として認識しない可能性があります。その場合、Salesforce 側でネイティブ認証器の登録を求められるリスクがあります。

一方、一般ユーザーについては、Okta Verify Push / TOTP など、Salesforce が標準 MFA として認識する方式を利用していれば、追加 MFA なしでログイン可能とされています。ただし、FastPass のみで運用している場合は、claim の扱いが今後の Okta 更新に依存する可能性があるため、最新の Okta 案内を確認することをおすすめします。

補足: 一般ユーザーで追加 MFA なしとされるのは、Okta Verify TOTP / Push など、Salesforce が標準 MFA として認識する方式を利用している場合です。

いま必要な対応

• 参考: FAQ: Mandatory MFA requirements for all Salesforce employees（Okta サポート）
• 参考: Salesforce ヘルプ（一般ユーザー向け／管理者・特権ユーザー向け）

③ Salesforce プロビジョニングの PKCE 対応

対象となる環境

• 対象：Okta の Salesforce 連携で、REST API（OAuth）によるユーザープロビジョニングを利用している環境
• 対象外：Salesforce の SSO（SAML）のみで、ユーザープロビジョニングを行っていない環境

いま必要な対応

まとめ

今回ご紹介した3つのアップデートを整理すると、次のとおりです。

いずれも Okta および Salesforce 側の案内に基づく対応が必要です。特に②と③は今後も案内が更新される可能性があるため、対応着手前に必ず公式ドキュメントの最新情報をご確認ください。

参考ドキュメント

Okta / Salesforce 公式

• Okta and the Salesforce SSO Device Activation Change - Customer FAQ
• Configure custom claims for app integrations（Okta Help Center）
• FAQ: Mandatory MFA requirements for all Salesforce employees（Okta サポート）
• Update Salesforce Provisioning Applications to Support PKCE（Okta サポート）
• Salesforce ヘルプ：MFA 要件（一般ユーザー向け／管理者・特権ユーザー向け）

ネクストモード ブログ

• 【Okta】SAML の AMR 属性を使って Salesforce の二重プロンプトを回避する

Okta に関するお問い合わせ

Okta や Salesforce 連携に関するご相談は、ネクストモードまでお気軽にお問い合わせください。弊社は引き続き、お客様の Okta 活用をサポートしてまいります。