メインコンテンツにスキップ

本人確認とは?【非推奨】

⚠️ 本人確認は現在非推奨です

本人確認は非推奨となり、本人確認のシークレットキーはもはや公開されません。アプリクライアントシークレットを使ってuser_hashを生成すると無効なuser_hashエラーが発生します。 Fin Messengerのセキュリティには現在JWT(JSON Web Token)が推奨されています。最新のベストプラクティスについてはJWTセットアップガイドをご覧ください。

本人確認は、あなたとあなたのusers間の会話がプライベートに保たれ、悪意のある第三者がusersをなりすますことを防ぎます。

ログインしないウェブサイト訪問者にのみIntercomを使用している場合、本人確認は必要ありません。これはemailアドレスやuser_idなどの識別子を持つusersにのみ適用されます。


ユーザーなりすまし攻撃とは何ですか?

ログインしたusersがいるワークスペースでは、本人確認がないと悪意のある第三者がusersをなりすます可能性があります。つまり、悪意のある第三者がusersの過去の会話を見たり、あなたのチームメンバーにそのusersとして見せかけて、そのusersのアカウントで行動を取らせることができるのです。

例えば、本人確認がない場合、誰かがFin Messengerとやり取りし、emailアドレスやuser_idなどの既知の識別子を提供することで別のusersの身元を偽装できます。これにより攻撃者は実際のusersになりすましてチームメンバーにアクセスし、過去の会話や潜在的に機密性の高いデータにアクセスできるようになります。


本人確認はどのように私のワークスペースを保護しますか?

本人確認では、emailアドレスやuser_id、そしてワークスペースの本人確認シークレット(Fin Messenger for hand over to Zendeskのインストール手順で入手可能)に基づいて、各usersに固有のuser hashを生成します。統合はこれらのハッシュをすべてのMessengerリクエストと共に生成・送信し、ユーザーリクエストが本当にあなたからのものであることを保証します。

本人確認を正しく有効にすると、ウェブMessengerのリクエストがなりすましからどのように保護されるかを示します。

本人確認は、シークレットにアクセスできない限り、第三者がusersの識別子を偽装してIntercomに有効なuser hashを送信できないため、ワークスペースでのクロスユーザーなりすましを防ぎます。

本人確認が強制されると、Fin Messengerは有効なuser hashなしでログインしたusersのリクエストを読み込んだり受け付けたりしません


本人確認はユーザー体験に影響しますか?

本人確認が正しく設定されていれば、お客様への影響はありません。UsersとLeadsは通常通りMessengerを利用できます。認証やMessengerの使用に追加の操作は必要ありません。


LeadsとUsersの違いは何ですか?

Intercomは以下のように明確に区別しています:

  • 訪問者 - ログインしておらず、あなたとの会話履歴がないサイトの未知の顧客、

  • Leads - 会話を開始したりメッセージに返信した顧客。彼らは「Charcoal Umbrella from Paris」のような名前で識別され、会話履歴を記憶するためのIntercomクッキーを受け取ります。

  • Users - 製品にサインアップし、既存のアカウントにログインした顧客。通常、emailアドレスやuser IDで識別します。


訪問者に対して本人確認を設定する必要がありますか?

ログインしないウェブサイト訪問者にIntercomをインストールしている場合、本人確認は不要です。これはemailアドレスやuser_idなどの識別子を持つusersにのみ適用されます。

つまり、ワークスペースで本人確認を有効にすると、Messengerがusers向けに読み込まれる場合にのみuser_hashが必要になります。しかし、ログアウトした訪問者やlead向けにMessengerが読み込まれる場合はuser_hashは不要です。


なぜすべてのプラットフォームで共通のシークレットを持たないのですか?

各プラットフォームごとに固有のシークレットを作成したのは、それぞれを個別にローテーションしたり、本人確認を独立して有効にしやすくするためです。


すべてのusersに同じバックエンドを使う場合、プラットフォームごとに固有のハッシュをどう生成しますか?

ハッシュを生成してデータベースに保存すべきではありません。代わりに、ユーザーをIntercomに識別する際に動的に生成して送信すべきです。これにより、シークレットを変更したりユーザーが異なるプラットフォームを使う場合でも、正しいハッシュが送信されます。

ハッシュを保存して送信すると、シークレット変更時に大量の再生成が必要になり、手間が増えます。


本人確認はuser_idとemailアドレスの両方を保護しますか?

いいえ、本人確認ではシークレットとuser_idまたはemailアドレスのいずれかを使って固有のハッシュを作成する必要があります。Messengerリクエストにuser_idを送信する場合は、その識別子を使ってハッシュを作成します。user_idを送信しない場合はemailアドレスで生成します。

こちらの回答で解決しましたか?