Salesforce OIDC/SAML SSO のデバイス有効化に伴う仕様変更を解説してみる

2026-02-06

エヌデーデー加茂です。

直近で少し話題になっている Salesforce OIDC/SAML SSOログイン における Device Activation （デバイス有効化）について解説します。※

※本記事は 2026/02/04時点の情報のものです。

概要

SSOログインにおけるデバイスの有効化（Device Activation）の変更
https://help.salesforce.com/s/articleView?id=005237070&type=1&language=ja

お客様環境を保護するために、当社が実践する継続的なセキュリティ強化の取り組みの一環として、Salesforceは特定のシングルサインオン（SSO）ユーザーログインに対して、デバイスの有効化（Device Activation）を実施いたします。この強化は、不正なアカウントアクセスをさらに制限し、以前強化された非SSOログインユーザーに対しデバイスの有効化を適用したセキュリティ更新に加えて実施されるものです。

2026年1月26日（2026年1月20日から変更）より、Salesforceは、強力なセキュリティ対策を実装していない特定のシングルサインオン（SSO）ログインに対してデバイスの有効化を要求する変更をSSO IDプロバイダー（IdP）に段階的に適用し始めます。2026年2月3日より、SalesforceはSAML IdPに対して「デバイスの有効化」を必須とする変更のリリースを開始します。詳細については、以下の「今後の変更予定」のセクションをご参照ください。

要約すると以下の通り

• Salesforce は不正アクセス防止の強化として、SSO ユーザーにも Device Activation を要求する
• 適用開始は 2026年1月26日から（1月20日から変更）
• 2026年２月3日より SAML Idpに対して「デバイスの有効化」を必須とする変更を適用開始

影響範囲

• SAML で Salesforce を SP（Service Provider）で利用している場合
• OIDC（OpenID Connect）で Salesforce を RP (Relying Party）で利用している場合

一般的な商用IdP（Entra ID, Okta, HENNGE等)からSalesforce へのログイン SAML または OIDC を利用している全ての環境が対象です。

変更の背景

アカウントの乗っ取り（ATO）や、不正アクセスを防ぐための予防的なセキュリティ対策が目的です。
今回の仕様変更でSSOログイン時も追加の本人確認を行うことが必須となり、より安全に Salesforce を利用できるようになります。
Device Activation は SSOや Idp で十分なセキュリティを備えていない場合や、既存の対策だけでは最近の脅威に対応しきれないと判断された場合に実施されるようです。

今後のリリーススケジュール

仕様変更について

認証済み（有効化済み）デバイス

Salesforceは、ユーザーが以前そのデバイスをの有効化しているため、そのデバイスまたはブラウザを認証済みとして認識しています。（デバイスまたはブラウザは、Salesforceが sfdc_lv2_platform クッキーに保存された情報と一致させることができない場合、「未認識」と定義されます。）クッキーの有効期間は1年間です。

Salesforce で 認証済みデバイスの情報を sfdc_lv2_platform cookieに保持します（有効期限 1年）
ブラウザの cookie が一致しない場合は「未認識デバイス」として扱われ、Device Activation（デバイス有効化）が求められます。

限定された 信頼済みIPアドレス

ネットワークアクセス設定の組織レベルで構成されたIPアドレス範囲（組織の信頼済みIP範囲の設定）、およびプロファイルレベルのログインIP範囲（プロファイルでのログインIPアドレスの制限）が、 IPv4: 2^24 IP もしくは 16,777,216 アドレスの制限内であること

以下のいずれかの設定で、Device Activation （デバイス有効化）を回避できます。

• 組織の信頼済みIP範囲の設定
• プロファイル単位のログインIP制限

両方に設定している場合は 両方が条件の範囲内である点に注意してください。
例えば、「プロファイルのログインIP制限」の制限内であっても、組織の「ネットワークアクセスの信頼済みIP範囲」の制限外からアクセスした場合には要求されます。

組織の信頼済みIP範囲の設定　

[ユーザー] -> [プロファイル] -> [該当プロファイル] -> [ログインIPアドレスの制限]

※上記の画像内のIPアドレスはイメージです。

プロファイルレベルのログインIP範囲（各プロファイル）

[ユーザー] -> [プロファイル] -> [該当プロファイル] -> [ログインIPアドレスの制限]

現実的な対応としては「組織の信頼済みIP」に拠点のグローバルアドレス、またはVPNゲートウェイアドレスを登録して、範囲外アドレスのデバイスアクティベーションを許容する形になると思います。

Salesforce が セキュアな認証方式と判断する評価プロセス

Salesforceで OIDC/SSO Idp からのSSOが「セキュアな認証方式で実行された」であることを判断する評価プロセスが以下のように変更になります。

Salesforce は、SSO ID プロバイダ (IdP) から提供される ID シグナルを検査することで、SSO ログインの強度を評価します。Salesforce は、OIDC プロトコルと SAML プロトコルの両方で強力な認証シグナルを認識する評価ロジックを使用します。

評価プロセス

評価プロセスとしては SSO Response に特定の認証シグナル（※）の存在を確認し、セキュアな認証方式と判断された場合に Device Activation（デバイス有効化） を回避します。
※ログインユーザーが誰であり、アクセスが安全かを判断するために収集・分析する認証情報や証跡のこと

OIDC / SAML の評価プロセスは以下の通りです。

相互運用性

OIDCで「強固」と認識される値（例：face, pop, hwk）は、OIDCとSAML AMR属性内で送信される場合に受け入れます。

部分文字列判定

属性名、属性名共に大文字、小文字区別せず、部分文字列として一致するか評価されます。

属性名： AMR または authnmethodsreferences　

属性値： 下表の通り

検証不能の場合

IdPが「値を省略」 または「未指定」等の値を送信する場合は認証強度の検証に失敗、 Device Activation のプロンプトが表示されます。

SAML 認証コンテキスト（AuthnContext）

今回の仕様変更で SAML 認証コンテキストの指定を Salesoforceからの要求値で指定する必要があります。

SAML標準値（既定URI）

MobileTwoFactorContract
PublicKey
PGP
Smartcard
TimeSyncToken
PKI

IdP固有のカスタムクレーム（固定値）

Mfa
Fido
multipleauthn

実際に要求する認証方法と設定値を整理します。

上記何れかの値が SAML Response の認証コンテキスト要素（AuthnContextClassRef） に設定されている必要があります。

1/30以前は “X509" や “Certificate-based" が該当する記載がありましたが、
1/30の公開情報でデバイス有効化を回避する条件としては認められない旨、訂正されています。

注記：「x.509」、「Certificate-based」、および「otp」という値は、デバイスの有効化をスキップする条件としては認められません。これらの方式は以前、誤って本ナレッジ記事に記載されていましたが、強固な認証に関する業界標準に準拠するため削除されました。

2/4に Microsoft環境向けの MFAカスタムクレーム（"multipeauthn"）が追加されました。

一般的なSAML認証コンテキスト

Salesoforce へ SAML でパスワード認証した場合の SAML Response を確認してみます。

 <AuthnStatement AuthnInstant="2026-01-22T11:35:08.115Z"
                 SessionIndex="*******************************"
                 >
     <AuthnContext>
     　　<AuthnContextClassRef>
       　　urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </AuthnContextClassRef>
     </AuthnContext>
 </AuthnStatement>

SAMLの認証コンテキスト（AuthnContextClassRef）は以下の値が渡されています。

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

これは SAMLでパスワード認証で利用されており、TLS/SSLで保護されていることを意味しています。

旧仕様では SAML でパスワード認証 が利用されている場合でも、IdP側の認証方法として MFA が実装済であることを前提にSalesforceはセキュアな認証方式として扱ってきました。

新仕様では SMAL認証コンテキストにはSAML仕様（oasis）の SAML標準値（既定URI） かカスタムクレーム（固定値）を要求しています。
この要求が満たされない場合、Salesforceはセキュアな認証方式ではないと判断します。

例を挙げると以下の値を要求しています。
ex) IdPでクライアント証明書が使用された場合

     <AuthnContext>
     　　<AuthnContextClassRef>
       　　urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
         </AuthnContextClassRef>
     </AuthnContext>

ex) IdpでMFAが使用された場合

    <AuthnContext>
     　　<AuthnContextClassRef>
       　　Mfa
         </AuthnContextClassRef>
     </AuthnContext>

この Salesforceの要求に対して 商用Idpの慣例とギャップがあるため、混乱を招いています。

一般的な商用IdP（Entra ID, Okta, HENGE, GWS）は SAMLの認証コンテキストを以下の値で返すのが慣例です。

パスワード認証

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

パスワード認証＋MFA

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

→　MFAの場合は unspecified（未指定）とし、MFA認証済であることを SAML属性として送信するか、 IdP 側の認証強度で担保する設計が一般的です。

証明書認証

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
または
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

証明書認証でも urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportや urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified を返す商用 IdPも存在します。
加えて、 Salesforce は「カスタムクレーム（固定値）も設定可能」としていますが、このカスタムクレームを SAML AuthnContextClassRef として返せる商用 IdP は私の知る限りでは存在しません。

カスタムクレームの対応可能なのは以下の構成を採用している場合に限られます。

• 自社で独自の認証基盤を構築している
• Keycloak の様な AuthnContext を自由に制御できる OSS IdP を採用している

なお、AD FS も 認証コンテキスト のカスタムクレームには未対応で、SAML AMRは対応可です。

なぜギャップが起きているか？

SAML 認証コンテキスト（AuthnContext）は SAML 2.0（2005年）の古い仕様で当時の認証モデルに対応しており、現在主流の認証方式（Password, MFA, デバイス認証、証明書, パスキー）には未対応の仕様です。

よって、多くの商用Idpでは

• 認証コンテキスト（AuthContextClassRef） を固定値で返す
• 認証強度は IdP側で制御し、SPに認証強度に関する細かい情報は返さない

という設計が慣例になっています。

SP側の都合で 認証コンテキスト（AuthContextClassRef） を要求するとフェデレーション構成が破損するリスクがあり、IdP側では互換性重視で 特定のSAML標準値 で返すケースが多いです。

今回、Salesforceは IdPの慣例から外れる形で、SAML標準値を厳格に要求するような仕様へ変更します。

AMR（Authenticaton Method Reference）

AMRに関しては2/4時点においても都度仕様変更が入っている状況です。

01/26 SAML AMRに関しての仕様公開
01/30 SAML AMR訂正アナウンス
02/04 他Idpからのカスタムクレーム追加

OIDC及びSAML AMRには以下の認証方式と属性値が設定されている必要があります。

上記の認証方法がセキュアな認証方式と判断されます。
OIDCはRFC準拠なのでIdP側で適切な認証方法が選択されていれば問題ありません。
SAML AMRで認証方法に対応した属性値を渡す必要があります。

02/04公開情報では 他Idp（Entra ID）から送信されるカスタムクレームについては Salesforce側で標準対応したようです。

SAML AMR

認証コンテキストの値を変更できない場合は SAML AMR属性で対応可能です。

SAML AMR では SAMLの AuthnContextClassRef 要素 および XML応答内の「AMR」または「authnmethodsreferences」という属性名及び属性値が適切な値かを評価します。

Salesforceは、SAMLレスポンス内の「AMR」または「authnmethodsreferences」という名前の属性を認識します。Salesforceは厳密なXMLフォーマットよりも属性値を優先します。値が存在し、「強固」（例：mfa、hwk）であると認識される限り、デバイス有効化はスキップされます。

Salesforceが要求する SAML AMRの一例を挙げてみます。
MFA（カスタムクレーム設定）の場合

　<AttributeStatement>
 　　…(省略)　
   　<Attribute Name="authnmethodsreferences">
        <AttributeValue>mfa</AttributeValue>
     </Attribute>
  </AttributeStatement>
  <AuthnStatement AuthnInstant="2026-01-27T08:36:18.783Z"
                  SessionIndex="*******************"
                  >
     <AuthnContext>
         <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
     </AuthnContext>
   </AuthnStatement>

authnmethodsreferences という属性名と属性値に mfa を設定されていれば Device Activation（デバイス有効化）を回避します。

属性名・属性値は SAML AMRリストから大文字、小文字を区別せず部分一致で評価されます。

face
fpt
hwk
iris
mfa
retina
sc
pop
swk
multipleauthn
Okta_verify

SAML Responseの確認（Entra ID）

Entra ID で パスワード認証＋MFA を利用する際の SAML Response が Salesforce の SAML AMR でセキュアな認証方法として評価されるか確認します。

　<AttributeStatement>
 　　…(省略)　
   　<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreference">
        <AttributeValue>
　　　　　　　http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
　　　　 </AttributeValue>
        <AttributeValue>
             http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509
        </AttributeValue>
        <AttributeValue>
             http://schemas.microsoft.com/claims/multipleauthn
        </AttributeValue>
     </Attribute>
  </AttributeStatement>
  <AuthnStatement AuthnInstant="2026-01-27T08:36:18.783Z"
                  SessionIndex="************************"
                  >
     <AuthnContext>
         <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
     </AuthnContext>
   </AuthnStatement>

属性名の評価

属性名には http://schemas.microsoft.com/claims/authnmethodsreferences が渡されています。
authnmethodsreferences の属性名の指定が必要のため、部分一致で条件を満たしています。

属性値の評価

Entra ID では 属性値は複数渡されますので、1つずつ確認してみます。

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password

パスワード認証を意味しています。SAML AMR要求値の条件を満たしません。

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509

Entra IDは SAML Response 内で X.509が出現する固有の挙動があります。SAML AMR要求値の条件を満たしません。

http://schemas.microsoft.com/claims/multipleauthn

Microsoft環境下（Entra ID, AD FS）では MFA で追加認証されたことを意味します。multipleauthn は SAML AMR要求値の条件を満たしています。※

※2/4以前は Entra IDでMFA認証済の場合は、SAML AMRの要求値を満たさない仕様でした。

2/4公開情報で multipleauthn が SAML AMRの要求値に追加されたため、Entra IDはSalesforce側で標準対応となっています。

回避策

Salesforce と商用 IdP の仕様にギャップがあります。

Device Activation を回避するには以下の実装を検討します。

1. 信頼済みIP範囲の登録
2. SAML認証コンテキストの実装
3. SAML AMR属性の実装
4. OIDC 認証強度の強い認証方法の実装

1. 信頼済みIP範囲の登録

• 社内ネットワーク（固定IP / VPN）を Salesforce の信頼済みIP に登録
  • 信頼済みIP範囲内のアドレスは Device Activation（デバイス有効化） を回避し、範囲外アドレスは Device Activation（デバイス有効化） を許容します。
  • 許可対象のIP範囲
    • 本社、支社などの固定グローバルIP
    • VPNゲートウェイのグローバルIP
    • ゼロトラスト機器、サービスのゲートウェイIP
• プロファイル単位のログインIP制限は登録しない
  • ログインIP制限を利用している場合の未検討する。

2. SAML認証コンテキストの実装

• IdP に Salesforce が要求する 認証コンテキスト を設定
  • 多くの 商用IdPでは Salesforce の要求を満たせないため、原則対応しません。
  • IdP側でSalesforce向けの個別対応（仕様変更）がリリースされた場合のみ対応する程度で良いと思います。
  • IdP側で認証コンテキストで実装可能な場合でもフェデレーション構成が破損するリスクがあるため慎重に検討します。

3. SAML AMR属性値の実装

IdPでSAML AMRが対応可能であれば実装を検討します。

• 現在のSAML Responseを確認
  • SAML Tracer等で AttributeStatementに「authnmethodsreferences」または「AMR」を含む属性名があるかを確認します。
  • MFA実施済を示す属性値を確認します。（大文字・小文字区別なし/部分一致でOK）
    • Entra ID or AD FS："multipleauthn"
• 現状でSAML AMRの要求を満たさない場合
  • IdP側でSAML AMRの要求を満たす属性名（authnmethodsreferences または AMR）を追加します。
  • 認証方法に応じて、SAML AMR属性値リストにある属性値を設定します。（大文字・小文字区別なし/部分一致でOK）
  • ex) face, fpt, hwk, iris, mfa, retina, sc, pop, swk, multipleauthn, Okta_verify
• 何れの要求を満たさない場合は Device Activation （デバイス有効化）を許容します。

4. 認証強度の強い認証方法の実装（OIDC）

• OIDCを利用している場合は Salesforceが要求する認証方法が実施されていれば対応不要です。
• 単一認証でパスワード認証を利用している場合は、MFAや生体認証等の追加認証を設定します。

各IdPの対応状況

一部のIdPでは本件に関するアナウンスが出ています。

まとめ

今回の仕様変更に伴う対応をまとめてみます。

OIDCを利用中

• Salesforceが要求する認証方法が選択されていれば対応不要です。
• 要求を満たしていない場合は適切な認証方法を選択します。

SAMLを利用中

SAML認証コンテキストによる対応

• Salesforceが要求するSAML認証コンテキストは多くの商用IdPでは標準対応しておらず、現時点では要件を満たせません。
• 今後の仕様変更やIdP側のアップデートがあった際に改めて検討します。

SAML AMRによる対応（代替案）

• SAML認証コンテキストが対応不可の場合は、IdP側でSAML AMR（Authentication Methods References）を利用できるか検討します。
• IdP側でSAML属性（AMR​ または authnmethodsreferences​）を追加し、適切な値を設定することで、Device Activation の回避が可能です。
• IdP（Entra ID）は MFA実装済であれば、Salesforceの SAML AMR に標準対応しています。

信頼済IP範囲による対応（最終案）

• SAML認証コンテキスト及びSAML AMRも対応不可の場合は、信頼済みIP範囲の登録で対応します。
• IP範囲内からのアクセスのみDevice Activationを回避し、範囲外からのアクセスについては Device Activation が発生することを許容する運用とします。

今回は、Salesforce Device Activation の有効化に伴う OIDC／SAML SSO の仕様変更について解説しました。
リリース直前期（1/26–2/4）の SAML AMR に関するアナウンスが重なり、システム管理者や情シスの皆様には混乱が生じたかと思います。

当初、Salesforceは他IdpからMFA認証済のSAML AMRに該当する属性を渡されても対応しない方針を貫いており、多くの環境では信頼済み IP 範囲の登録でデバイス有効を回避する方向だったかと思います。

上記の仕様が直近で変更となり、 Microsoft環境（Entra ID, AD FS）は Idp から送信されるカスタムクレームに対応する方針に転じたようです。OktaもOkta専用のカスタムクレームが追加されたことから標準対応すると考えられます。

2月に入ってからSalesforceがIdp側の仕様へ寄せてきたこともあり、1月内に先んじて対応された方々損してしまった状況です。

認証基盤の仕様変更は追従する側の多大な工数負担が伴います。

サービス提供元の度重なる仕様変更はユーザーや開発者に重い負担を強いることになります。

ユーザーや開発者への影響を十分に予見した、一貫性のある設計や実装と十分な猶予期間を強く期待したいところです。

本記事が皆様の対応指針としてお役立てば幸いです。