はじめに
こんにちは、ネクストモードのゆきなわです。
ここ数か月、Okta と Salesforce の連携まわりで、ログイン時の認証やプロビジョニングに関わる重要な変更が相次いでいます。いずれも、ログイン時に追加のプロンプトが表示される、Okta から Salesforce へのユーザー連携に影響が出る、といった形で、日々の業務に直接影響しうる内容です。
本記事では、2026年6月時点で特に押さえておきたいアップデートを、何が変わるのか、自社が対象か、いま何をすべきかという観点で整理します。 今回取り上げるのは、次の3つです。
- Salesforce SSO の MFA 二重プロンプト問題（AMR 属性での解消）: すでに解消済み
- （2026年6月11日更新）Salesforce の SSO 認証要件の変更（MFA 強制適用）: 2026年6月22日から段階適用
- （2026年6月8日更新）Salesforce プロビジョニングの PKCE 対応: Preview（プレビュー） org は2026年6月3日以降6月5日以降、Production（本番）org は 2026年6月9日6月11日以降に移行可能
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月4日時点の公開情報および 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）に次の属性を追加します。
| 設定項目 | 値 |
|---|---|
| Name | AMR |
| Name format | Unspecified |
| Value | session.amr |
いま必要な対応
- OIN 公式アプリ：対応不要（必要に応じて旧回避策の AMR 属性を整理）
- カスタム SAML / OIDC アプリ：上記 AMR 属性を設定
画面キャプチャ付きの具体的な手順は、以下の弊社ブログで解説しています。設定確認（SAML レスポンスの観測）の方法もあわせてご覧ください。
②（2026年6月11日更新）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 環境から本番環境へと段階的に進みます。
| 対象 | Sandbox 環境 | 本番環境 |
|---|---|---|
| 特権ユーザー（フィッシング耐性 MFA） | 2026年6月22日〜（約7日間で段階適用） | 2026年7月1日〜（約30日間で段階適用） |
| 一般ユーザー（標準 MFA） | 2026年6月22日〜（約7日間で段階適用） | 2026年7月20日〜（約30日間で段階適用） |
特に注意したいポイント（FastPass と claim の関係）
この変更は、フィッシング耐性のある認証方式を使えばそれで済む、という単純な話ではありません。重要なのは、Okta が送信する認証クレーム（claim）を、Salesforce が MFA 要件を満たすものとして解釈できるかどうかです。特に Okta FastPass を中心に認証設計している環境では、Okta が送信する claim と、Salesforce が MFA として認識する claim（okta_verify / fido2 / webauthn など）の対応関係を確認しておく必要があります。
（2026年6月11日更新）当初、FastPass 利用時に発行される
phr(phishing-resistant) claim を Salesforce がフィッシング耐性 MFA として認識しない可能性を懸念点として挙げていましたが、この懸念は解消されました。最新状況は以下のとおりです。
- Salesforce 側：2026年6月5日付で Salesforce ヘルプ（管理者・特権ユーザー向け）が更新され、フィッシング耐性 MFA として受け入れる AMR / ACR 値に
phrが正式に追加されました。これにより、FastPass の認証で Salesforce 側のフィッシング耐性要件を満たすことが可能です。 - Okta 側：Okta Identity Engine 本番 (Production) org のリリースノート Version 2026.05.0（2026年6月8日リリース）にて、「AMR claim updates weren't applied to the Salesforce (Federated ID) app integration.（OKTA-1164030）」の修正がリリースされています。
- 検証情報：Admin Console でセキュリティ > 一般 から「AMR値形式を使用を無効」に設定している環境では、FastPass 認証時に AMR claim として
hwk（こちらもフィッシング耐性 MFA として受け入れられる値）が送信されることが確認されています。
phr / hwk など）は標準 MFA の要件も自動的に満たすため、FastPass で運用している場合も追加 MFA は不要となる見込みです。いま必要な対応
phr 受け入れにより大枠の懸念は解消されましたが、実際に自社環境から送信される claim が要件を満たしているかは、適用開始日前に確認しておくことをおすすめします。- Salesforce アプリ統合 (OIN) のバージョン確認：Okta 管理画面でアプリ統合が最新バージョンにアップグレードされているかを確認します。
- AMR claim の実値確認：SAML トレーサーなどで SAML レスポンスを確認し、AMR claim に
phr（またはhwk/fido2等）が含まれていることを確認します。SAML の AMR 値は現時点で Salesforce のログイン履歴には記録されないため、クライアント側での確認が確実です。 - 特権ユーザーの認証ポリシー確認：Okta FastPass や FIDO2 / WebAuthn など、フィッシング耐性のある MFA を利用できる状態になっているかを確認します。
- フォールバック準備：万一に備え、Salesforce が標準 MFA として認識する Okta Verify Push / TOTP を利用できるようにしておくと安心です。
- 参考: FAQ: Mandatory MFA requirements for all Salesforce employees（Okta サポート）
- 参考: Salesforce ヘルプ（一般ユーザー向け／管理者・特権ユーザー向け）
※管理者・特権ユーザー向け記事は 2026年6月5日に更新され、認証強度ティア表（AMR / ACR の受け入れ値一覧）と評価ロジックの解説が追加されています
③（2026年6月8日更新）Salesforce プロビジョニングの PKCE 対応
対象となる環境
- 対象：Okta の Salesforce 連携で、Connected App を利用した REST API（OAuth）によるユーザープロビジョニングを利用している環境 ※
- 対象外：Salesforce の SSO（SAML）のみを利用しており、Okta から Salesforce へのユーザープロビジョニングを行っていない環境
いま必要な対応
- Salesforce 側: Okta プロビジョニング用の Connected App で、Require Proof Key for Code Exchange (PKCE) Extension を有効化します。
- Okta 側: Salesforce アプリのプロビジョニング > 統合 設定画面で PKCE Enabled を有効化し、Salesforce への再認証を行います。
まとめ
今回ご紹介した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 対応 | Preview orgは2026年6月5日から、本番 org は2026年6月11日から移行可能予定。Salesforce 適用日は 2026年6月25日 |
REST API（OAuth）プロビジョニング利用環境 | Salesforce 側で PKCE を有効化し、Okta 側で PKCE Enabled を有効化して再認証 |
いずれも 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 に関するお問い合わせ
Okta や Salesforce 連携に関するご相談は、ネクストモードまでお気軽にお問い合わせください。弊社は引き続き、お客様の Okta 活用をサポートしてまいります。
