本人確認は、あなたとあなたのusers間の会話がプライベートに保たれ、悪意のある第三者がusersをなりすますことを防ぎます。ログイン済みusersとのMessenger連携がある場合は、本人確認の使用を強く推奨します。
⚠️ 本人確認は現在廃止されています。
本人確認は廃止され、本人確認のシークレットキーはもはや公開されていません。アプリクライアントシークレットを使ってuser_hashを生成すると無効なuser_hashエラーになります。Messengerのセキュリティには現在JWT（JSON Web Token）が推奨されています。最新のベストプラクティスについてはJWTセットアップガイドをご覧ください。
本人確認は必要ですか？
簡単に言うと、ログイン済みMessenger連携がある場合は、本人確認を設定して適用すべきです。
ログインしないウェブサイト訪問者向けにIntercomを使用している場合は、本人確認は不要です。これはemailアドレスやuser_idなどの識別子を持つusersにのみ適用されます。
詳細はIntercomにおける訪問者、leads、usersの仕組みをご覧ください。
ユーザーなりすまし攻撃とは何ですか？
本人確認がないワークスペースでは、悪意のある第三者がusersをなりすます可能性があります。これにより、悪意のある第三者がusersの過去の会話を見たり、チームメンバーにそのusersとして見せかけて、そのusersのアカウントで行動を起こさせることができます。
例えば、本人確認がない場合、誰かがIntercom Messengerとやり取りし、emailアドレスやuser_idなどの既知の識別子を提供して別のusersの身元を偽装できます。これにより攻撃者は実際のusersになりすまし、チームメンバーに過去の会話や機密データへのアクセスを与える可能性があります。
本人確認はどのように私のワークスペースを保護しますか？
本人確認では、emailアドレスやuser_idとあなたのワークスペースの本人確認シークレット（Intercomセキュリティ設定で入手可能）に基づいて、各usersのために一意のuser hashを生成します。あなたの連携はこれらのハッシュをMessengerのリクエストごとに生成・送信し、ユーザーリクエストが本当にあなたからのものであることを信頼できるようにします。
本人確認を適切に有効にすると、ウェブMessengerのリクエストがなりすましからどのように保護されるかを説明します。
本人確認は、シークレットにアクセスできない第三者がusersの識別子を偽装してIntercomに送信しようとしても、そのusersの有効なuser hashを送信できないため、ワークスペースでのクロスユーザーなりすましを防ぎます。
本人確認が適用されると、Intercom Messengerは有効なuser hashなしでログイン済みusersのリクエストを読み込んだり受け入れたりしません。
本人確認はユーザー体験に影響しますか？
本人確認が正しく設定されていれば、お客様への影響はありません。UsersとLeadsは通常通りMessengerを利用できます。認証やMessengerの使用に追加の操作は不要です。
LeadsとUsersの違いは何ですか？
Intercomは以下のように明確に区別しています：
Visitors - あなたのサイトにログインせず、会話履歴のない未知の顧客、
Leads - あなたと会話を始めたりメッセージに返信した顧客。例えば「Charcoal Umbrella from Paris」のような名前で識別され、会話履歴を記憶するためのIntercomクッキーを受け取ります。
Users - あなたの製品にサインアップし、既存アカウントにログインした顧客。通常emailアドレスやuser IDで識別します。
詳細はIntercomにおける訪問者、leads、usersの仕組みをご覧ください。
LeadsはいつUsersになりますか？
LeadsがUsersに変わるのは、以下のいずれかのアクションが発生したときです：
Leadsがあなたの製品にサインアップしたとき。
Leadsが既存アカウントにログインしたとき。この移行時に、Leadsのすべてのやり取り履歴は保持されUsersのプロフィールに統合されます。ただし、メールスレッドの参加者としてLeadsを追加するなどの操作は自動的にUsersへの変換にはなりません。
なぜ重複したLead IDが作成されることがありますか？
IntercomはLeadsを追跡するためにクッキーを使用しています。以下のような場合に同一人物に対して重複したLead IDが生成されることがあります：
プライベート／シークレットブラウジングの使用。
VPN（仮想プライベートネットワーク）を通じてシステムにアクセスする場合。
クッキーの有効期限切れや手動でのクリア。識別子（emailなど）が一貫していない場合、同一人物に複数のプロフィールが作成されることがあります。
訪問者に対して本人確認を設定する必要がありますか？
ログインしないウェブサイト訪問者向けにIntercomをインストールしている場合は、本人確認は不要です。これはemailアドレスやuser_idなどの識別子を持つusersにのみ適用されます。
言い換えれば、ワークスペースで本人確認を有効にすると、Messengerがusers向けに読み込まれるときのみuser_hashが必要になります。ただし、ログアウトしたvisitor/lead向けにMessengerが読み込まれる場合は、user_hashは不要です。
なぜすべてのプラットフォームで共通のシークレットを持たないのですか？
各プラットフォームごとにユニークなシークレットを作成したのは、それぞれを個別にローテーションしたり本人確認を有効にしやすくするためです。
以前はMessengerのセキュリティ設定からキーの管理やローテーションが可能でした。本人確認のシークレットキーはもはや公開されていません。Messengerのセキュリティには現在JWTが推奨されています。セットアップにはJWTセットアップガイドをご覧ください。
すべてのusersに同じバックエンドを使う場合、プラットフォームごとにユニークなハッシュをどう生成しますか？
ハッシュを生成してデータベースに保存すべきではありません。代わりに、ユーザーをIntercomに識別するときに動的に生成して送信すべきです。これにより、シークレットを変更したりユーザーが異なるプラットフォームを使う場合でも、正しいハッシュが送信されます。
ハッシュを保存して送信すると、シークレット変更時に大量の再生成が必要になり、手間が増えます。
rails gemでIntercomをインストールしている場合、サーバーでハッシュを生成してユーザーデータと一緒に送信する必要はありません。UIに記載されたシークレットに関する手順に従えば、gemがハッシュ生成を処理します。
本人確認はuser_idとemailアドレスの両方を保護しますか？
いいえ、本人確認ではシークレットとusersのuser_idかemailアドレスのいずれかを使って一意のハッシュを作成する必要があります。Messengerリクエストにuser_idを送る場合はこの識別子でハッシュを作成し、送らない場合はemailアドレスで生成します。
✅ 本人確認は属性を保護しませんが、JWTを使うことで全属性を保護できる改善機能があります。
詳細はこちら：
「ログイン済みUsersとのアクティブな連携」にあるすべてのdomainは何ですか？見覚えがありません。
これらは、あなたのワークスペースIDでUserリクエストを受け取ったdomainです。テストのために他のdomainにIntercomをインストールしている場合は追加のdomainが含まれることがあります。見覚えのないdomainがある場合は、信頼できるdomainリストの追加を推奨します。
現時点ではこのリストからdomainを削除することはできませんが、ここにdomainが表示されている場合は、いつかそのdomainからpingを受け取ったことを意味します。Messengerが一部のusersで動作しなくならないよう、連携を正しく設定しているか確認してください。
ウェブとモバイルでの本人確認の設定と有効化方法を確認してください。