JSONウェブトークン（JWT）は、第三者がログイン中のusersになりすましたり、その会話を覗き見したりするのを防ぎます。すべてのFin顧客にJWT認証の強制を強く推奨します。
サイトにログイン中のusers向けにFin Messengerを設置している場合、悪意ある者がusersになりすましたり不正なデータを送信したりするのを防ぐために、必ずセキュリティを強化してください。
セキュリティが不十分なMessengerでは、誰かがFin Messengerとやり取りし、メールアドレスやuser_idなどの既知の識別子を使って別のuserの身元を偽装する可能性があります。これにより攻撃者は実際のuserになりすましてチームメイトにアクセスし、過去の会話や機密データにアクセスできる恐れがあります。
JSONウェブトークン（JWT）とは何ですか？
JWTはデータに署名する業界標準の方法です。通常、ドットで区切られた3つの部分から成り、典型的なJWTはheader.payload.signatureのような形をしています。
ヘッダーはトークンの種類（JWT）と署名アルゴリズム（例：HS256）を指定します。
ペイロードにはuserやセッションに関するクレーム（例：user_id、email）が含まれます。
最後に、署名は秘密鍵やプライベートキーを使ってトークンが改ざんされていないことを保証します。
JSONウェブトークン（JWT）でMessengerを保護する利点は何ですか？
ユーザーIDの安全性: Messengerを保護することで、チームメイトは話しているuserが本当にそのuserであることを確信できます。
ユーザーデータのセキュリティ強化: Messengerを保護することで、Messenger APIを通じてuserに関するデータ属性を安全に送信できます。
盗まれたセッションによるリスク軽減: JWTでMessengerを保護するとトークンの有効期限を設定でき、userのブラウザからトークンが盗まれた場合のデータ漏洩リスクを大幅に減らせます。短い有効期限を指定することでリスクが軽減されます。
より安全なFinとAI workflows: 信頼できるuser情報が必要な複雑なプロセス、Actions、WorkflowsをFinに任せられます。
userのIDとデータを安全に送信し、トークンの有効期限を強制することで、JWTはFin Messengerを最も安全な状態に保ちます。
カスタマーエクスペリエンス
Fin MessengerでJWTを使う場合の体験は以下の通りです。
Messengerの統合は、JWTを含む
Intercom('boot')リクエストでログイン中のuserを起動します。このJWTの署名は設定のMessenger秘密鍵で生成されます。その後、workspaceはuserのブラウザにセッションクッキーを提供します。このクッキーのデフォルト有効期間は7日間で、ユーザー認証や更新に使用されます。
セッションが切れ、新しいJWTが送信されない場合、userのセッションは終了します。userはログアウトしたウェブサイト訪問者として新しいMessengerを見ます。会話履歴は含まれません。
Messengerが
Intercom('boot')と有効なJWTで再起動されると、Messengerはuserを識別し、過去の会話と新しいセッションを表示します。同じデバイスでのログアウト中の活動も認証済みuserのアカウントに統合されます。
ヒント:
userのセッションクッキーの有効期間をデフォルトの7日より短くしたい場合は、session_duration Messenger属性でミリ秒単位のTTLを指定できます。
Fin MessengerからZendesk ticketsを作成し、特定の組織にticketsをルーティングしたい場合は、JWTにcompanyフィールドを含めることができます。
idの値はZendesk組織のexternal ID（内部Zendesk IDではありません）と一致させてください。
インストール：JWTの生成と送信
ステップ1：アプリケーションにMessengerをインストールする
workspace固有のセットアップ手順は設定 > Messenger > セキュリティで確認できます。
安全でないMessengerセットアップと安全なセットアップの主な違いは、ユーザーリクエストに追加のintercomUserJwtフィールドを含め、それがuserの識別と更新に使われることです。
Javascriptスニペットにデータ属性を追加するオプションがあります。これはFin workspaceに送信したいデータを制御します。JWTでデータを送信するため、署名したくない属性（例：フロントエンド固有のデータ）のみをここに含めるべきです。
JWT以外にデータを送信したくない場合は、api_baseとapp_id以外のデータをスニペットから削除できます。app_idはFin workspaceの固有識別子です。
user_idやemailなどのuser固有の識別子がない訪問者には、App IDのみを含むログアウト状態のMessengerスニペットを設定してください。匿名訪問者向けに軽量で安全な構成を維持するため、user属性は追加しないでください。
ステップ2：usersのためにJWTを生成し始める
業界標準のJWTライブラリを使い、Messenger API Secretを秘密鍵としてトークンを生成できます。秘密鍵はworkspaceのセキュリティ設定のmessengerタブで生成可能です。
注意：JWTトークンは各userセッションごとに一意に生成する必要があります。トークンにはuser_idなどの識別クレームを含め、Messenger API Secretで署名して正しいuserに安全に紐付けられるようにしてください。
インストールに適したコード例を得るために、バックエンドとフロントエンドのフレームワークを選択してください。
Node.jsの例はこちらです：
usersに関する追加属性（例：price_planやnumber_of_songs_added）を送信したい場合は、それらもJWTに追加します。user_idは唯一の必須フィールドです。JWTペイロード内のフィールド名と属性は大文字小文字を区別します。例えば「user_id」は小文字の'i'で書く必要があり、「user_Id」では正しいユーザー識別ができません。
注意：Fin生成のJWKでJWTトークンに署名する場合、subクレームはFinが割り当てたUser IDがデフォルトで一意のuser識別子として機能します。JWK機構を使うとsub値は固定でカスタマイズ不可であり、互換性と誤設定防止を保証します。
ステップ3：MessengerスニペットにJWTを追加する
ログイン中のuser向けにMessengerを起動する際、署名済みJSON Web Tokenを提供し、Messengerペイロードのintercom_user_jwt属性に割り当てられます。あるいは、ログイン前にIntercom.setUserJwt(jwt)を使って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の任意のデータ属性を安全に送信できます。有効なJWTが受信されると、userのブラウザにデフォルト7日間のセッションクッキーが作成されます。
MessengerセッションクッキーのTTLを制御するには、Messengers一般設定の「Messengerを安全に保つ」ドロップダウンで最大値を設定できます。
ステップ4：属性の更新を無効にすることを確認する
Messenger APIのデータ属性に対して安全でない更新を有効にすることが可能で、Messenger経由のその属性の更新はすべて成功します。
JWTで安全に送信しているデータがある場合は、それらの属性に対する安全でないMessenger更新を無効にし、有効なJWT経由のみで更新されるようにしてください。注：この切り替えはbotでleadsから直接データ収集することは妨げません。
JWTで送信している属性には、この切り替えを有効にすることを推奨します。
ステップ5：ログアウト時にuserセッションを終了する
所有する公開サイト（マーケティングサイト、ドキュメントサイト、開発者ハブなど）にFin Messengerを設置できます。usersがログイン中に異なるサブドメイン間で会話の継続性を保つため、userのブラウザにクッキーを設定します。このクッキーは1週間で期限切れになります。
共有コンピュータとブラウザを他のユーザーと使用する場合、クッキーが有効な間は直近にログインしたユーザーの会話履歴が見られます。そのため、ユーザーのセッション終了時（手動または自動ログアウト）にFin Messengerを適切にシャットダウンすることが非常に重要です。
Fin Messengerのシャットダウン方法はこちらです：
すでにIntercom JSスニペットまたは“boot”メソッドでユーザーのトラッキングを開始しています。
ユーザーがFin Messengerからログアウトする（またはアプリによって自動ログアウトされる）際には、JavaScript APIのIntercom('shutdown');を呼び出してセッションを終了し、クッキーをクリアしてください。
最終ステップ：ワークスペースのMessengerセキュリティを強制する
統合がユーザーのJWTを正しく送信している場合、Messenger設定でセキュリティをオンにしてMessengerセキュリティを強制してください。これにより、Fin Messengerはワークスペースのユーザーに対するリクエストが有効なJWTまたは有効なuser_hashで保護されていることを要求します。
注意：JWT認証は現在、Fin MessengerのiOSおよびAndroid SDKではサポートされていません。モバイル実装では、SDKのサポートが利用可能になるまでJWTの代わりにIdentity Verification（HMAC-SHA256）を使用し続けてください。
トラブルシューティングガイダンス
インストールのデバッグに役立つ2つのツールがあります。1つは最近のエラーログを確認する方法、もう1つはトークンデバッガーです。
インストールログを確認する
設定 > Channels > Messenger > Securityのステップ6でインストールログを確認できます。ここにはJWTインストールに関連するすべての失敗ログが表示されます。JWTが無効、期限切れなどのエラーが記録されます。「View log」をクリックすると、リクエスト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”を主な識別子と考える場合、emailの値をuser_idと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セッションのクッキーに関連付けられたユーザーと一致しません。これは競合する2つのセッションを開始しようとしていることを示します。新しいユーザーを起動する前にIntercom('shutdown')を呼び出していることを確認してください。HTTP 400 - "Invalid intercom_user_jwt": 有効なユーザーを正しく起動していることを確認してください。JWTトークンの検証に失敗した場合（例：クレームの不一致や不適切な署名）、会話は自動的に閉じられ、問題のデバッグに役立つAPIエラーログにエラーが記録されます。
JWTデコーダー
デコーダーツールではJSON Web Tokenをチェックできます。設定 > Messenger > Securityのサイドバーで見つけられます。
ツールで生成したユーザーJWTの有効性を確認できます。JWTを生成する際に使用した関連する秘密鍵を選択し、Decodeをクリックしてください。
デコード後、JWTのペイロードからユーザー詳細、ヘッダー、有効か無効かのメモが表示されます。
この例では無効な秘密鍵を使用し、user_idフィールドを含めていません。どちらも失敗の原因となります。
よくある質問
なぜJWTにuser_idが必要なのですか？
現在、ユーザーの主な識別子としてuser_idを提供する必要があります。これまではuser_idまたはemailのどちらかを識別子としてサポートしていましたが、基本的なIdentity Verificationで大きな混乱を招いていました。emailだけでユーザーを識別する場合は、ペイロードのuser_idとemail属性の両方にemailアドレスを入れてください。
user_idがない非ログインユーザーにはどう設定すればいいですか？
Messengerセキュリティ機能は、ユーザーに一意のuser_idを提供することを要求します。リード用にMessengerを使用している場合は、この方法で識別できません。ただし、REST APIやCSVなど他の統合でuser_idを持つユーザーがワークスペースにいる場合は、JWT Messengerセキュリティを有効にして、そのユーザーのMessenger起動を防止してください。ログアウトした訪問者には、認証なしで動作する軽量版Messengerを設定できます。App IDのみでMessengerスクリプトを読み込み、ユーザーデータやJWTトークンを渡さないようにしてください。これにより、ユーザーフレンドリーさを保ちつつシステムの機能性とデータの整合性を維持できます。
要するに、ワークスペースに推測可能な識別子（email、user_id）を持つ任意のusersがいる場合は、Messengerセキュリティを有効にしてください。ログイン済みとログアウト済みの両方のユーザーをサポートする場合は、セキュリティと使いやすさのために混合戦略を採用してください。ログイン済みユーザーセッションにはJWT認証を使用して機密情報を保護し、ログアウト済み訪問者にはユーザー固有のトークンやデータなしで簡易Messenger設定を許可します。
有効期限はどう設定すればいいですか？
Messengerが起動するたびに新しいJWTを送信する必要があるため、トークンの有効期間はMessenger起動間の時間をサポートすれば十分です。アプリの動作に適した最短期間を選択してください。ウェブページが頻繁にリロードされる場合はJWTを短命にすべきですが、予期しない期限切れを防ぐために最低5分を推奨します。常にJWTに有効期限（exp）クレームを含めて、盗まれたトークンの影響を減らしセキュリティを確保してください。
どの署名アルゴリズムが使えますか？
以下をサポートしています：
HS256（SHA-256を用いたHMAC）。このアルゴリズムは共有秘密鍵でトークンを署名・検証し、トークン内のデータが改ざんされていないことを保証します。
JWT用のRS256は非対称鍵ペアを使用し、署名にプライベート鍵、検証にパブリック鍵を使い、セキュリティ強化の代替手段を提供します。
JSON Web Key（JWK）構成は、Fin生成の鍵とシームレスに統合でき、トークン管理を効率化します。
user_hashとintercom_user_jwtの両方を送れますか？
いいえ、user_hashはJWTに置き換えられるべきなので、両方を同時に送信することはサポートしていません。ただし、移行中の顧客がuser_hashとintercom_user_jwtを交互に送信することは可能です。
JWTが有効で正常に動作しているかどうかはどう確認できますか？
上記のトラブルシューティングセクションを参照してください。
ワークスペースでJWTの必須化をどう強制しますか？
Messenger設定で強制トグルを有効にしてください。
どの属性を保護すべきですか？
すべての識別属性は保護マークを付け、可能な限りJWTで安全に送信してください。これにはemail、電話番号、顧客がUserレコードに保存する可能性のあるaccount_idが含まれます。属性は設定 > People Dataで確認できます。
FinがActionやWorkflowの重要部分で使用する属性は保護すべきで、悪意あるユーザーがその値を上書きできないようにします。
JWT外でデータを送信する場合はMessengerの更新を許可している必要がありますが、ユーザー自身がこのフィールドを更新できる可能性があることに注意してください。
window.intercomSettings = {
app_id: <APP_ID_CODE>,
intercom_user_jwt: <TOKEN>,
unsigned_data_attribute: 'data'
};
ユーザーが操作中にセッションが切れたらどうなりますか？
クッキーの有効期限切れ後にMessengerでユーザーのアクティビティがある場合、Intercomはユーザー体験への悪影響を避けるために1時間の短期クッキーを新たに発行します。ユーザー体験への影響を防ぐため、クッキーのセッション期間はアプリのセッションタイムアウトに合わせることを推奨します。
なぜペイロード全体の署名を要求しないのですか？
ユーザーがアプリケーションで操作を行っている間に、ユーザーに関する低精度のデータを送信する必要がある場合に対応できるよう、署名されていない属性の送信を許可しています。この機能が不要な場合は、すべてのUser Data Attributesを「Messengerの更新から保護」に設定し、署名付きペイロードのみを送信できます。
Messengerの秘密鍵はどのように管理およびローテーションしますか？
秘密鍵はワークスペースのMessengerセキュリティ設定で生成できます。
JWT設定ページの右側サイドバーで既存の鍵を見つけてコピーできます。
Workspace > Security > Messengerで鍵をローテーションできます。
Identity Verificationはどうなりましたか？JWTがそれに代わるものですか？
Identity Verificationは、HMACユーザーハッシュを使用してユーザーリクエストが統合によって送信されたことを識別するMessenger Securityの以前のバージョンです。
ユーザーハッシュは引き続き受け入れられますが、より多くのセキュリティ利点があるため、すべてのユーザーにJWTへのアップグレードを強く推奨します。Identity Verificationは今後更新されません。
JWTページからIdentity Verificationのインストールを管理する必要がある場合は、引き続き可能です。手順はJWT設定に合わせて更新されており、変更を行う場合はJWTへの移行を強く推奨しますが、機能を無効にしたりMessenger APIの秘密鍵をローテーションしたりする必要がある場合は、Settings > Security > Messengerから引き続き実行できます。