メインコンテンツまでスキップ

MFA 信頼済みデバイス

MFA 信頼済みデバイスを利用すると、ユーザーは信頼するブラウザで繰り返し MFA プロンプトをスキップできます。対象となる MFA の認証 (Authentication) またはセットアップ後、ユーザーはサインインやサインアップの最後に表示される このデバイスを信頼する ページでブラウザを信頼することを選択できます。Logto は、その後、期間限定の認証情報をファーストパーティ Cookie に保存します。後のサインイン時に有効な認証情報があれば、ユーザーの操作なしで MFA 認証 (Authentication) ステップを完了できます。

信頼済みデバイスは新しい MFA 要素ではなく、Logto が MFA を要求するタイミングを変更しません。サインインフロー内の MFA ステップのみを満たすことができます。アイデンティティ認証 (Authentication)、直近の認証 (Authentication)、アカウント復旧、MFA 要素管理、その他の機密性の高いアカウント操作を満たすことはできません。

信頼済みデバイスの仕組み​

サインインが MFA 認証 (Authentication) ステップに到達した際、Logto は以下を行います:

  1. 現在の MFA ポリシーを評価し、MFA が必要かどうかを判断します。
  2. 信頼済みデバイスがテナントで有効化されており、ユーザーが所属するすべての組織 (Organizations) で許可されているかを確認します。
  3. ブラウザ Cookie を、特定されたユーザーのアクティブなサーバー側レコードと照合します。
  4. 認証情報が有効な場合は自動的に MFA を完了します。有効でない場合は無効な認証情報をクリアし、通常の MFA フローを継続します。

サインインまたはサインアップ時にデバイスを信頼する​

組み込みのサインイン体験では、必要なプロフィール入力や MFA ステップの後、対象となるサインインまたはサインアップフローの最後に このデバイスを信頼する ページが個別に表示されます。ブラウザを信頼するかどうかはこのページで明示的に選択でき、MFA 認証 (Authentication) やセットアップとは別の操作です。

このページは、信頼済みデバイスがテナントで有効化され、ユーザーが所属するすべての組織 (Organizations) で許可されており、かつ現在の操作で対象となる MFA 証明がある場合のみ表示されます:

  • 有効な認証アプリ OTP、パスキー (WebAuthn)、メール認証コード、または SMS 認証コードによる MFA 認証 (Authentication) に成功した場合
  • サインアップ時を含む MFA セットアップ中に認証アプリまたはパスキーのバインディングに成功した場合

パスワードリセット時や、対象となる MFA 証明がない場合はこのページは表示されません。バックアップコードによる認証や既存の信頼済みデバイス認証情報のみでは対象外のため、すべてのサインインやサインアップでページが表示されるわけではありません。以前に スキップ を選択した場合も、下記の通りページ表示が抑制されます。

このページでユーザーは次の選択ができます:

  • このデバイスを N 日間信頼する:設定された信頼期間でオプトインします。Logto は、操作がすべて完了した後にのみ信頼済みデバイスレコードと Cookie 認証情報を作成します。
  • スキップ:信頼済みデバイスを作成せずに続行します。このページをスキップしても、必要な MFA 認証 (Authentication) やセットアップはスキップされません。

ユーザーが スキップ を選択した場合、Logto はそのテナントとユーザーにスコープされた別のオプトアウト Cookie を現在のブラウザに保存します。その有効期間はスキップ時点の信頼期間と同じです。この Cookie がブラウザに残っている間は、後のサインイン時にページは再表示されません。Cookie の有効期限切れや削除後は、再度対象となるフローでページが表示されます。オプトアウト Cookie はデバイス信頼や MFA の認証 (Authentication) を満たしません。

スキップ後にデバイスを信頼する場合:

ユーザーが スキップ を選択した後、現在のブラウザを信頼したい場合は、ブラウザの Cookie 設定や開発者ツールで Logto ドメインの該当オプトアウト Cookie を削除するのが推奨方法です。Cookie 名は __Host-logto-device-trust-opt-out- で始まります。

または、Logto ドメインのすべての Cookie を削除してください。

いずれかの方法の後、再度サインインし、対象となる MFA 認証 (Authentication) またはセットアップを完了し、ページが表示されたら このデバイスを N 日間信頼する を選択してください。

信頼済みデバイスの作成やサインイン後のメタデータ更新はベストエフォートで行われるため、失敗しても他の認証 (Authentication) 操作が失敗することはありません。

信頼済みデバイスポリシーの設定​

グローバルポリシー​

コンソール > 多要素認証 (MFA) に移動し、信頼済みデバイス を設定します:

  • テナント単位で信頼済みデバイスを有効または無効にします。デフォルトでは無効です。
  • 1~365 日の整数で信頼期間を設定します。デフォルトは 30 日です。

信頼済みデバイス作成時に期間が固定されます。デバイスを使用しても有効期限は延長されず、期間を変更しても以降に作成されるデバイスにのみ反映されます。

グローバルポリシーを無効にすると、既存の信頼済みデバイスで MFA を満たすことはできなくなりますが、削除はされません。再度有効化すると、有効期限内または未削除のレコードは再び利用可能になります。

組織レベルの制限​

組織 (Organizations) ごとに、メンバーに対して信頼済みデバイスの利用を許可または禁止できます。この設定はテナントレベルのポリシーを厳格化するのみです:

  • グローバルポリシーが無効な場合、組織 (Organizations) で信頼済みデバイスを有効にすることはできません。
  • ユーザーが所属するいずれかの組織 (Organizations) で信頼済みデバイスが禁止されている場合、そのユーザーの信頼済みデバイス認証情報では MFA を満たせません(その組織 (Organizations) で MFA が必須かどうかは関係ありません)。
  • 組織 (Organizations) ごとに信頼期間を個別設定することはできません。グローバル期間が適用されます。

組織 (Organizations) で信頼済みデバイスを禁止すると、該当メンバーの利用が停止されますが、レコードは削除されません。また、ユーザーや管理者が一覧表示や削除を行うことも妨げません。

信頼済みデバイスの再利用には、同じ Logto エンドポイントで永続的なファーストパーティ Cookie を保持・返却できるブラウザコンテキストが必要です。これは物理デバイスではなく、ブラウザプロファイル単位で管理されます。

WebView、システムブラウザ、カスタムタブ、プライバシーモード、Cookie 無効ブラウザ、その他一時的なコンテキストでは、Cookie ストアが認証情報を永続化できる場合のみ信頼済みデバイスを利用できます。後のサインイン時に Cookie が利用できない場合、Logto は認証 (Authentication) 失敗とはせず、通常の MFA フローを継続します。異なるブラウザ、ブラウザプロファイル、Logto ドメイン、テナント、ユーザー間で信頼済みデバイス認証情報は共有されません。

注記:

Logto はブラウザフィンガープリントを使用せず、クライアントが Cookie を永続化するか事前検出しません。ネイティブアプリやカスタムサインインフローでは、信頼済みデバイス作成はベストエフォートとして扱い、通常の MFA フローも利用可能にしてください。

信頼済みデバイスの管理​

expiresAt が将来のアクティブなレコードのみが一覧表示されます。デバイス名は最新のユーザーエージェントから生成され、国や都市は最新リクエストコンテキストからの概算メタデータです。生の IP アドレスは UI や公開 API で表示・返却されません。

管理者による管理​

コンソール > ユーザー管理 でユーザーを開き、その信頼済みデバイスを表示・削除できます。信頼済みデバイスを削除しても、今後のサインインにのみ影響し、現在のアクティブセッションは終了しません。

Management API も利用できます:

  • GET /api/users/{userId}/trusted-devices でユーザーのアクティブな信頼済みデバイスを一覧表示
  • DELETE /api/users/{userId}/trusted-devices/{trustedDeviceId} でユーザー所有の信頼済みデバイスを 1 件削除

レスポンスには id, userAgent, country, city, createdAt, lastUsedAt, expiresAt が含まれます。

curl https://[tenant-id].logto.app/api/users/[user-id]/trusted-devices \
-H "Authorization: Bearer [management-api-access-token]"

curl -X DELETE \
https://[tenant-id].logto.app/api/users/[user-id]/trusted-devices/[trusted-device-id] \
-H "Authorization: Bearer [management-api-access-token]"

Management API で認証 (Authentication) する方法 を参照してください。

アカウントセンターでのセルフサービス管理​

コンソール > サインイン & アカウント > アカウントセンター で 信頼済みデバイス フィールドを設定します:

  • オフ:ユーザーは信頼済みデバイスの一覧表示や削除ができません。
  • 閲覧のみ:ユーザーは信頼済みデバイスを一覧表示できますが、削除はできません。
  • 編集:ユーザーは信頼済みデバイスの一覧表示と削除ができます。

組み込みのアカウントセンターでは、セキュリティページにアクティブな信頼済みデバイスが表示され、現在のブラウザの Cookie 認証情報が有効な場合はマークされます。現在のブラウザを削除すると、その信頼済みデバイス Cookie はクリアされますが、現在のログインセッションは維持されます。他のブラウザのレコードを削除しても、そのブラウザの Cookie を即座にクリアすることはできません。古い Cookie は次回提示時に拒否・クリアされます。

カスタムアカウントセンターの場合は、urn:logto:scope:trusted_devices スコープをリクエストし、有効なアイデンティティ認証 (Authentication) レコードとともに Account API を利用してください:

  • GET /api/my-account/trusted-devices でサインイン中ユーザーのアクティブな信頼済みデバイスを一覧表示し、各項目に isCurrent を追加
  • DELETE /api/my-account/trusted-devices/{trustedDeviceId} でサインイン中ユーザー所有の信頼済みデバイスを 1 件削除(削除はファーストパーティアプリのみ可能)
curl https://[tenant-id].logto.app/api/my-account/trusted-devices \
-H "Authorization: Bearer [account-api-access-token]" \
-H "logto-verification-id: [verification-record-id]"

curl -X DELETE \
https://[tenant-id].logto.app/api/my-account/trusted-devices/[trusted-device-id] \
-H "Authorization: Bearer [account-api-access-token]" \
-H "logto-verification-id: [verification-record-id]"

Account API リファレンス および セキュリティ認証 (Authentication) ガイド で認可 (Authorization) と認証 (Authentication) フローを確認してください。

セキュリティモデル​

信頼済みデバイス認証情報は、レコード ID と暗号的にランダムな 32 バイトシークレットの 2 部構成の不透明トークン (Opaque token) です。

  • 本番環境では、Logto は __Host- プレフィックス、HttpOnly、Secure、SameSite=Lax、Path=/ 属性付きのホスト限定 Cookie に保存します。アプリケーションの JavaScript からは読み取れません。
  • サーバー側ではシークレットの SHA-256 ハッシュのみを保存し、認証情報の比較はタイミングセーフで行います。
  • すべての認証情報検索はテナントとユーザーに限定され、expiresAt が将来である必要があります。
  • 有効期限は作成時に固定されます。期限切れレコードのクリーンアップは後から行われる場合がありますが、クリーンアップのタイミングはセキュリティ制御には利用されません。
  • 明示的な削除操作はサーバー側レコードを即時削除します。コピーされた Cookie や古い Cookie は、レコード削除後は認証 (Authentication) に失敗します。

認証情報のシークレットやハッシュは UI、公開 API、監査ログ、Webhook で公開されません。公開デバイス ID は物理デバイス識別子ではなく、認証 (Authentication) には不十分です。Cookie はベアラートークン (Opaque token) であるため、完全な Cookie をコピーすれば、レコードの有効期限切れや削除まで同じテナント・ユーザーで信頼を再現できますが、信頼済みデバイスはハードウェアによるデバイス認証 (Authentication) を提供しません。

監査ログと Webhook​

信頼済みデバイス固有の監査ログには次が含まれます:

  • TrustedDevice.Created:成功した操作後に信頼済みデバイスレコードと Cookie 認証情報が作成された
  • TrustedDevice.Used:信頼済みデバイス認証情報で MFA を満たし、サインインが成功した

これらのデータ変更 Webhook を購読できます:

  • TrustedDevice.Created:信頼済みデバイスレコードが作成された
  • TrustedDevice.Deleted:ユーザーまたは管理者が信頼済みデバイスレコードを削除した

イベントデータには信頼済みデバイスの id, userId, expiresAt が含まれます。Cookie 認証情報、シークレットハッシュ、リクエスト IP は含まれません。成功利用の Webhook はイベント量が多くなるためありません。また、ポリシー変更はレコードを変更しないため、信頼済みデバイスのライフサイクルイベントは発行されません。

自然失効には TrustedDevice.Expired Webhook はありません。失効はアプリケーション操作ではなく時間経過で発生し、物理的なクリーンアップは後から行われる場合があります。統合で有効期限を推定する必要がある場合は TrustedDevice.Created の expiresAt を利用してください。

自然失効時にも信頼済みデバイス固有の監査ログは作成されません。

監査ログイベントタイプ および Webhook イベント でイベントカタログを確認してください。

ライフサイクルに関する注意事項​

  • 通常のサインアウトでは信頼済みデバイスは削除されません。
  • MFA 要素の追加・削除・リセットでも信頼済みデバイスは削除されません。
  • 信頼済みデバイスを削除してもアクティブセッションは終了しません。
  • ユーザー削除時はユーザーデータのライフサイクルに従い信頼済みデバイスレコードも削除されます。
  • 信頼済みデバイスの件数制限や自動削除はありません。