サイトにログインしたusers向けにMessengerを設置している場合、usersのなりすましや不正なデータ送信を防ぐためにセキュリティを強化することが不可欠です。
セキュリティが不十分なMessengerでは、誰かがIntercom Messengerとやり取りし、メールアドレスやuser_idなどの既知の識別子を使って別のuserの身元を偽装する可能性があります。これにより攻撃者は実際のuserになりすまし、チームメンバーに対して過去の会話や機密データへのアクセスを許してしまいます。
参考になれば、こちらの機能とリスク軽減のビデオ解説をご覧ください。
ログインしたusers向けにMessenger連携をしている場合は、Messengerのセキュリティ強化を強く推奨します。
注意：
複数のusersが同じメールアドレスを共有し、連携がメールのみを識別子として使用している場合、Intercomは競合エラーでリクエストを拒否し、どのuserを使うか推測しません。認証成功のためには、JWTペイロードに安定した一意の識別子（user_id）を必ず含めてください。JWTの本人確認にはuser_idが必須であり、これがないトークンは拒否されます。
JSON Web Token（JWT）とは何ですか？
JSON Web Token（JWT）はデータに署名する業界標準の方法です。通常、ドットで区切られた3つの部分から成り、典型的なJWTはheader.payload.signatureの形をしています。
ヘッダーはトークンタイプ（JWT）と署名アルゴリズム（例：HS256）を指定します。
ペイロードにはuserやセッションに関するクレーム（例：user_id、email）が含まれます。
最後に、署名は秘密鍵やプライベートキーを使ってトークンが改ざんされていないことを保証します。
MessengerをJSON Web Tokens（JWTs）で保護する利点は何ですか？
安全なuserの本人確認：Messengerを保護することで、チームメンバーは話しているuserが本当にそのuserであることを確信できます。
強化されたuserデータのセキュリティ：Messengerを保護することで、Messenger APIを通じてuserのデータ属性を安全に送信できます。
盗まれたセッションによるリスクの軽減：JWTでMessengerを保護すると、トークンの有効期限を設定でき、usersのブラウザからトークンが盗まれた場合のデータ漏洩リスクを大幅に減らせます。短い有効期限を指定することでリスクが軽減されます。
より安全なFinとAI workflows：信頼できるuser情報が必要な複雑なプロセス、Actions、WorkflowsをFinに任せられます。
userの本人確認とデータを安全に送信し、トークンの有効期限を強制することで、JWTはIntercom Messengerを可能な限り安全な状態に保ちます。
カスタマーエクスペリエンス
Intercom MessengerでJWTを使用する場合の体験は以下の通りです：
Messenger連携は、JWTを含む
Intercom('boot')リクエストでログインしたuserを起動します。JWTにはIntercomに送信したいすべてのuserデータが含まれます。JWTの署名は設定のMessengerシークレットキーで生成されます。その後、IntercomはユーザーのブラウザにセッションCookieを提供します。このCookieのデフォルト有効期間は7日間で、ユーザー認証と更新に使用されます。
セッションが期限切れで新しいJWTが送信されない場合、userのセッションは終了します。userはログアウトしたウェブサイト訪問者として新しいMessengerを見ます。会話履歴は含まれません。
Messengerが
Intercom('boot')と有効なJWTで再起動されると、Messengerはuserを識別し、過去の会話と新しいセッションを表示します。また、同じデバイスで発生したログアウト中のアクティビティも認証済みuserのアカウントに統合されます。
userのセッションCookieの有効期間をデフォルトの7日より短くしたい場合は、session_duration Messenger属性でミリ秒単位のTTLを指定できます。
インストール：JWTの生成と送信
ステップ1：アプリケーションにMessengerをインストールする
ワークスペース固有のセットアップ手順は設定 > Messenger > セキュリティで確認できます。
安全でないMessengerセットアップと安全なセットアップの主な違いは、ユーザーリクエストに追加のintercomUserJwtフィールドを含め、それがuserの識別と更新に使われることです。
Javascriptスニペットにデータ属性を追加するオプションがあります。これはIntercomに送信したいデータを制御します。JWTでデータを送信するため、署名したくない属性（例：フロントエンド固有のデータ）のみをここに含めるべきです。
JWT以外のデータを送信したくない場合は、api_baseとapp_id以外のすべてのデータをスニペットから削除できます。app_idはIntercomワークスペースの一意の識別子です。
ステップ2：usersのためにJWTを生成し始める
業界標準のJWTライブラリを使い、Messenger API Secretを秘密鍵としてトークンを生成できます。秘密鍵はワークスペースのMessengerセキュリティ設定で生成可能です。
バックエンドとフロントエンドのフレームワークを選択して、インストールに適したコード例を取得してください。
Node.jsの例はこちらです：
注意：Messenger APIのシークレットキーやJWT生成コードはフロントエンドコードに絶対に入れないでください。必ずサーバー側に置き、シークレットキーを適切に保護してください。
usersに関する追加の属性（例：price_planやnumber_of_songs_added）を送信したい場合は、それらもJWTに追加します。user_idが唯一の必須フィールドです。カスタムデータ属性についてはこちら。
JWTはいつ含めるべきですか？
Messengerでuserを起動したり、userのデータを更新しようとするすべてのリクエストにJWTを送信してください。
どの有効期限を設定すべきですか？
JWTの有効期限は短く設定し、リクエストが完全に届き処理されるのに十分な長さにしてください。有効期限は必須ではありませんが、トークンのリプレイリスクを減らすため強く推奨されます。
ステップ3：MessengerスニペットにJWTを追加する
ログインしたuser向けにMessengerを起動する際、署名済みJSON Web Tokenを提供し、Messengerペイロードのintercom_user_jwt属性に割り当てます。
クライアント側設定例
window.Intercom("boot", {
api_base: "https://api-iam.intercom.io",
app_id: "APP_ID_CODE",
intercom_user_jwt: <YOUR_USER_JWT_TOKEN>,
};
このJWTには、userに安全に送信したい任意のuserデータ属性を含めることができます。有効なJWTが受信されると、ユーザーのブラウザにデフォルト7日間のセッションCookieが作成されます。
MessengerセッションCookieのTTLを制御するには、設定 > チャンネル > Messenger > 一般 > Messengerを安全に保つで最大値を設定できます。
ステップ4：属性の更新を無効にすることを確認する
Messenger APIのデータ属性に対して安全でない更新を有効にすることが可能で、Messenger経由のその属性の更新はすべて成功します。
JWTで安全に送信しているデータがある場合は、それらの属性に対する安全でないMessenger更新を無効にすることを確認してください。これにより有効なJWT経由のみで更新されます。注：この切り替えはbotによるleadsからの直接データ収集は妨げません。
JWTで送信する属性には、このトグルを有効にすることをお勧めします。
ステップ5：ログアウト時にユーザーセッションをシャットダウンする
Intercomは、あなたが所有する任意の公開サイト（マーケティングサイト、ドキュメントサイト、開発者ハブなど）にIntercom Messengerを設置できます。ユーザーがログインしている間、これらの異なるサブドメイン間で会話の連続性を維持するために、ユーザーのブラウザにクッキーを設定します。このクッキーは1週間で期限切れになります。
共有コンピュータとブラウザを他の誰かと使うユーザーは、クッキーが期限切れになるまで直近にログインしたユーザーの会話履歴を見ることができます。そのため、ユーザーのセッションが終了した際（手動または自動ログアウト時）にIntercomを適切にシャットダウンすることが非常に重要です。
Intercomをシャットダウンする方法は以下の通りです：
すでにIntercom JSスニペットまたは“boot”メソッドでユーザーのトラッキングを開始しているはずです。
ユーザーがIntercomからログアウトしたとき（またはアプリによって自動的にログアウトされたとき）、JavaScript APIのIntercom('shutdown');を呼び出してIntercomセッションを終了し、クッキーをクリアしてください。
🎉 最終ステップ：ワークスペースのMessengerセキュリティを強制する
統合がユーザーのJWTを正しく送信している場合、Messenger設定でトグルをオンにしてMessengerセキュリティを強制すべきです。これにより、Intercomはワークスペースのユーザーに対するリクエストが有効なJWTまたは有効なuser_hashで保護されていることを要求します。
トラブルシューティングガイダンス
インストールのデバッグに役立つ2つのツールがあります。1つは最近のエラーログを確認する方法、もう1つはトークンデバッガーです。
インストールログを確認する
ステップ6の設定 > チャンネル > Messenger > セキュリティでインストールログを確認できます。ここにはJWTインストールに関連するすべての失敗ログが表示されます。JWTが無効、期限切れなどのエラーが表示されます。「ログを見る」をクリックすると、リクエストID、タイムスタンプ、リファラー、ユーザーデータを含む完全なログが見られます。これによりリクエスト失敗の原因を理解し、自分のアプリに遡って追跡するのに役立ちます。
一般的なエラーメッセージ
HTTP 400 - "user_hash and intercom_user_jwt cannot be provided simultaneously": リクエストにJWTとuser_hashの両方が含まれていました。顧客はどちらか一方を含めるべきで、両方は含めないでください。HTTP 400 - “Missing user_id in payload”: すべてのJWTはペイロードにuser_idを含むことが期待されています。顧客が“email”を主な識別子と考える場合、ペイロードのuser_idとemailフィールドの両方にemailの値を入れるべきです。HTTP 400 - “Invalid intercom_user_jwt payload”: JWTのペイロードが無効です。顧客はペイロードが正しく形成され、エンコードされ、api_secret値を署名秘密鍵として使用したSHA256 HMACで署名されていることを確認してください。HTTP 400 - “Intercom_user_jwt expired”: JWTの‘exp’は過去のタイムスタンプです。顧客は将来の有効期限を提供するべきです。HTTP 400 - “JWT identity mismatch": JWTに提供されたユーザーIDが、アクティブなintercomセッションcookieに関連付けられたユーザーと一致しません。これは2つの競合するセッションを開始しようとしていることを示します。新しいユーザーを起動する前にIntercom('shutdown')を呼び出していることを確認してください。HTTP 400 - "Invalid intercom_user_jwt": 有効なユーザーを正しく起動していることを確認してください。
JWTデコーダー
当社のデコーダーツールはJSONウェブトークンをチェックする方法も提供します。インストールページのサイドバーで見つけられます。
ツールで生成したユーザーJWTの1つを有効性チェックできます。JWT生成に使用した関連する秘密鍵を選択し、デコードをクリックしてください。
デコード後、JWTのペイロード、ヘッダー、そして有効か無効かの注記が表示されます。ペイロードを見ることで、属性が送信されているかどうかのトラブルシューティングに役立ちます。
この例では無効な秘密鍵を使い、user_idフィールドを含めていません。どちらも失敗の原因になります。
よくある質問
なぜJWTにuser_idが必要なのですか？私のusersはメールアドレスだけです。
現在、usersの主な識別子としてuser_idを提供する必要があります。これまではuser_idかemailのどちらかを識別子としてサポートしていましたが、基本的なIdentity Verificationで製品の混乱を招いていました。
usersを識別するのにemailしかない場合、ペイロードのuser_idとemail属性の両方にemailアドレスを入れることができます。ただし、すでにIntercomにemailだけでusersがいる場合は、JWTを使う前にuser IDを持つように更新する必要があります。これはuser IDがemailよりも上位の識別子だからです。
usersにuser IDを追加するには、まずIntercom IDでユーザーを特定します。これはAPIの"Get a contact"エンドポイントで行えます。次に"Update a Contact"エンドポイントを使ってuser_idを追加します。詳細はこちら
user_idがない非ログインユーザー向けにはどう設定すればいいですか？
Messengerのセキュリティ機能は、提供された一意のuser IDを持つusersが必要です。leadsだけにMessengerを使う場合は、この方法で識別できません。Messenger APIはユーザーのトラフィックに対して無効にすべきです。このチャネルを通じてユーザートラフィックを期待していないためです。
これはMessenger > インストールで設定できます。使用しているインストール方法（web、iOS、Android）を選び、「Messengerへの接続を有効にする」トグルがusers向けにオフになっていることを確認してください。
有効期限はどのように設定すべきですか？
Messengerが起動するたびに新しいJWTを送信すべきで、トークンの有効期間はMessengerの起動間隔をサポートするだけで十分です。アプリケーションの動作に適した最小期間を選んでください。ウェブページが頻繁にリロードされる場合、JWTは短命であるべきですが、予期しない期限切れを防ぐために最低5分を推奨します。
どの署名アルゴリズムが使えますか？
HS256（SHA-256を使ったHMAC）をサポートしています。このアルゴリズムは共有秘密鍵でトークンに署名・検証し、トークン内のデータが改ざんされていないことを保証します。
user_hashとintercom_user_jwtの両方を送信できますか？
いいえ、user_hashはJWTに置き換えられるべきなので、両方を同時に送信することはサポートしていません。ただし、一部の顧客はuser_hashからintercom_user_jwtに移行する際に、user_hashとintercom_user_jwtの送信を交互に行う必要があります。
現在Identity Verificationを使いuser hashesを送信している場合は、JWT送信に切り替えるためのこのガイドを参照してください。
JWTが有効で正常に動作しているかどうかはどう確認できますか？
上記のトラブルシューティングセクションを参照してください。
ワークスペースでJWTの必須要件をどのように強制しますか？
Messenger設定で強制トグルを有効にすべきです。
どの属性を保護すべきですか？
すべての識別属性は保護マークを付け、可能であればJWTで安全に送信すべきです。これにはemail、電話番号、顧客がUserレコードに保存する可能性のあるaccount_idsが含まれます。属性は設定 > データ > Peopleで確認できます。
FinがActionやWorkflowの重要な部分で使用する属性は、悪意のあるユーザーがその値を上書きできないように保護すべきです。
JWTの外でデータを送信したい場合は、Messengerの更新を許可していれば可能ですが、ユーザー自身がこのフィールドを更新できることを念頭に置いてください。
window.intercomSettings = {
app_id: <APP_ID_CODE>,
intercom_user_jwt: <TOKEN>,
unsigned_data_attribute: 'data'
};
ユーザーが何かをしている途中でセッションが期限切れになったらどうなりますか？
クッキーが期限切れた後にMessenger内でユーザーのアクティビティがあった場合、Intercomはユーザー体験に悪影響を与えないように1時間の短期間クッキーを新たに発行します。ユーザー体験への意図しない影響を防ぐため、クッキーのセッション期間はアプリケーションのセッションタイムアウトと一致させることを推奨します。
モバイルMessengerはどうですか？
なぜペイロード全体の署名を必須にしないのですか？
お客様がアプリケーションでユーザーが操作している間に低精度のデータを送信する必要がある場合に対応するため、署名されていないAttributesの送信を許可しています。この機能が不要な場合は、すべてのUser Data Attributesを「Messengerの更新から保護」に設定し、署名済みペイロードのみを送信できます。
Messengerのシークレットキーはどのように管理・ローテーションしますか？
シークレットキーはワークスペースのMessengerセキュリティ設定で生成できます。
JWT設定ページの右側サイドバーで既存のキーを見つけてコピーできます。
キーはWorkspace > Security > Messengerでローテーションできます。
JWTに含まれる属性は単一のticketまたは会話にのみ適用されますか？
いいえ。JSON Web Token (JWT)に含めた属性は常にIntercomのユーザープロフィールを更新します。JWT属性は単一のticketや会話にのみ適用されるデータを追加するためには使えません。
Identity Verificationはどうなりましたか？これはそれに代わるものですか？
Identity VerificationはMessenger Securityの以前のバージョンで、HMACユーザーハッシュを使ってユーザーリクエストが統合から送信されたことを識別します。
user_hashesは引き続き受け入れられますが、より多くのセキュリティ利点があるため、すべてのお客様にJWTへのアップグレードを強く推奨します。Identity Verificationは今後更新されません。
JWTページからIdentity Verificationのインストールを管理することも可能です。手順はJWT設定に合わせて更新されており、変更を行う場合はJWTへの移行を強く推奨しますが、機能を無効化したりMessenger APIのシークレットキーをローテーションしたりする必要がある場合は、JWT設定ページからこれを行えます。
JWTに会社データを含めてユーザーを会社に関連付けることはできますか？
はい。JWTペイロードにcompany_idやその他の会社属性を含めて、Intercomでユーザーを会社に関連付けることができます。存在する場合、Intercomは起動時に会社を自動的に作成・関連付けします。これはIntercom('boot')で会社データを渡すのと同じ動作です。ping/bootリクエスト中にインラインで会社が作成されるため、追加の遅延は発生しません。
これは、複数のユーザーが送信したticketsが共有の会社ビューに集約されるTickets Portalのような会社レベルの機能を使う設定で特に重要です。ユーザーが会社に関連付けられていない場合は、JWTペイロードにcompany_idが含まれているか確認してください。
または、ユーザーがログインする前にサーバーサイドAPIを使って会社を作成し、ユーザーを関連付けることもできます。これは、テナント作成時に会社レコードを事前に登録するなど、最初のユーザーセッション前に会社データが存在する必要がある場合に適した方法です。
注意：JWTにcompany_idを渡しているのにIntercomで会社が作成されない場合は、bugの可能性があるためサポートチームにお問い合わせください。