こんにちは、ネクストモードのゆきなわです。
ここ数か月、Okta と Salesforce の連携まわりで、ログイン時の認証やプロビジョニングに関わる重要な変更が相次いでいます。いずれも、ログイン時に追加のプロンプトが表示される、Okta から Salesforce へのユーザー連携に影響が出る、といった形で、日々の業務に直接影響しうる内容です。
本記事では、2026年6月時点で特に押さえておきたいアップデートを、何が変わるのか、自社が対象か、いま何をすべきかという観点で整理します。 今回取り上げるのは、次の3つです。
1と2はどちらも、ログイン時に追加のプロンプトが出るという点で似ていますが、原因も対応も異なります。混同しやすいので、先に違いを整理しておきます。
| 項目 | ① Device Activation 由来 | ② MFA 強制適用由来 |
|---|---|---|
| 原因 | Salesforce のデバイスアクティベーション仕様変更 | Salesforce の MFA 要件の強化 |
| 主な影響 | Okta の MFA 完了後に、Salesforce 側の追加確認（デバイスアクティベーション）が出る | Salesforce が MFA 要件を満たす claim として解釈できない場合に、追加の認証器登録を求められる |
| 対応状況 | OIN 公式アプリは解消済み | 2026年6月22日以降、段階的に適用 |
| 主な対応 | AMR / session.amr 属性の設定 | Okta のクレーム更新・アプリ設定の確認 |
3は SSO ではなく、ユーザープロビジョニング（ユーザーの作成・更新）に関わる話題です。
⚠️本記事は、2026年6月2日時点の公開情報および Okta からの案内に基づいています。適用日や対応要件は今後更新される可能性があるため、実際の対応時には本文中の公式ドキュメントで最新情報をご確認ください。
まずは、すでに解消済みの話題から整理します。
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）に次の属性を追加します。
| 設定項目 | 値 |
|---|---|
| Name | AMR |
| Name format | Unspecified |
| Value | session.amr |
画面キャプチャ付きの具体的な手順は、以下の弊社ブログで解説しています。設定確認（SAML レスポンスの観測）の方法もあわせてご覧ください。
続いて、これから段階的に適用される変更です。 ①と同じくログイン時の追加プロンプトに関わりますが、こちらは Salesforce へのアクセスに MFA を求めるという、別の仕様変更です。Salesforce への直接ログインだけでなく、SSO ログインも対象になります。
Salesforce が求める認証方式は、ユーザーの権限レベルによって分かれています。
ここでいう特権ユーザーとは、System Administrator プロファイル、または Customize Application / Modify All Data / View All Data / Author Apex のいずれかの権限を持つユーザーを指します。適用は、Sandbox 環境から本番環境へと段階的に進みます。
| 対象 | Sandbox 環境 | 本番環境 |
|---|---|---|
| 特権ユーザー（フィッシング耐性 MFA） | 2026年6月22日〜（約7日間で段階適用） | 2026年7月1日〜（約30日間で段階適用） |
| 一般ユーザー（標準 MFA） | 2026年6月22日〜（約7日間で段階適用） | 2026年7月20日〜（約30日間で段階適用） |
この変更は、フィッシング耐性のある認証方式を使えばそれで済む、という単純な話ではありません。重要なのは、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 として認識する方式を利用している場合です。
今回ご紹介した3つのアップデートを整理すると、次のとおりです。
| # | テーマ | 時期 | 対象 | いま必要な対応 |
|---|---|---|---|---|
| ① | SSO の追加プロンプト（Device Activation / AMR 属性） | 2026年3月26日以降、OIN 公式アプリは解消済み | カスタム SAML/OIDC アプリ利用環境 | AMR / session.amr 属性を追加（OIN 公式アプリは不要） |
| ② | SSO 認証要件の変更（MFA 強制適用） | 2026年6月22日〜段階適用 | SSO で Salesforce を利用する環境（特に特権ユーザー） | 独自判断で大きく変更する前に、Okta の案内に沿ってアプリ設定／claim 更新を確認。特権ユーザーのフィッシング耐性 MFA を準備 |
| ③ | プロビジョニングの PKCE 対応 | Okta 側コネクタ更新後に対応 | REST API（OAuth）プロビジョニング利用環境 | 現時点では移行開始不要。Okta サポートページで最新情報を確認 |
いずれも Okta および Salesforce 側の案内に基づく対応が必要です。特に②と③は今後も案内が更新される可能性があるため、対応着手前に必ず公式ドキュメントの最新情報をご確認ください。
Okta や Salesforce 連携に関するご相談は、ネクストモードまでお気軽にお問い合わせください。弊社は引き続き、お客様の Okta 活用をサポートしてまいります。