Data connectorsの新しい認証方法を設定するには、設定 > 統合 > 認証に移動し、トークンを追加をクリックします。
トークンを設定する主な方法は2つあります：事前設定済みプロバイダーに接続するか、カスタムトークンを作成するかです。
事前設定済みプロバイダー（OAuth）に接続する
Salesforce、HubSpot、Attioなどのサポートされているプロバイダー向けに、認証を迅速かつシームレスにする3段階のOAuthフローを提供しています。
これらのプロバイダーのいずれかに接続するには：
設定 > 統合 > 認証に移動し、トークンを追加をクリックします。
ドロップダウンから希望のプロバイダーを選択します。
プロバイダーの認可ページにリダイレクトされます。要求された権限を確認し、接続を許可するために確認（または許可）をクリックします。
OAuthフローが完了すると、新しいアクセストークンが自動的にトークンリストに表示されます。
新しく作成したトークンをクリックすると、その設定が表示されます。これは事前設定済みの統合のため、名前と説明のフィールドのみ編集可能です。以下も表示されます：
API URL: Data connectorsでこのプロバイダーにAPIコールを行う際に使用する基本URLです。クリップボードにコピーアイコンで簡単にコピーできます。
スコープ: トークンに付与された権限の読み取り専用リスト。
トークンの再認証
トークンがプロバイダー側で無効化または破損した場合、削除して再設定する必要はありません。トークンの詳細を開き、右上の再認証ボタンをクリックしてください。これによりOAuthフローが再度実行され、既存のトークンが自動的に更新され、Data connectorsの接続が手動更新なしで継続されます。
カスタムトークンの作成
事前設定リストに含まれていないサービスに接続する必要がある場合：
設定 > 統合 > 認証に移動し、トークンを追加をクリックします。
カスタムを選択します。
次に、ドロップダウンから作成したいトークンのタイプを選択します。
テキストトークン
テキストトークンは静的トークンです。トークンの名前、説明、値、トークンプレフィックス、およびトークンを含むリクエストヘッダーのキーを設定でき、Data connectorリクエストに挿入されます。
HTTPリクエストトークン
HTTPリクエストトークンは動的です。必要に応じてトークンを更新するために認証エンドポイントへのHTTPリクエストを設定します。これらのトークンは保存前に認証トークンUIからテストする必要があります。トークンの名前、説明、およびリクエスト自体に影響するフィールド（HTTPリクエストメソッド、URL、HTTPヘッダー、キーと値のペア）を設定できます。
テストリクエストをクリックしてトークンをテストし、レスポンス内のトークンの位置、トークンプレフィックス、およびリクエストヘッダーのキーを指定してください。
HTTPリクエストトークンがData Connectorに割り当てられている場合、コネクタは最新の取得済みトークンをリクエストに使用します。リクエストが400、401、または403のレスポンスを返した場合、指定された認証エンドポイントURLにHTTPリクエストを送信してトークンを更新します。その後、元のData Connectorリクエストは新しいトークンを使って再試行されます。
HTTPリクエストトークンはIntercomによって自動的に更新され、Data connectorsの動作を維持します。これらの更新は人の操作なしにバックグラウンドで行われ、「System」または「Fin」として更新されたように表示されることがあります。
注意：サーバーがアクセス拒否のレスポンスに200を返す場合、トークンは更新されません。この場合、サーバーを400、401、または403を返すように更新する必要があります。
トークンの更新に問題がある場合、その問題はData connectorの「ログ」タブに記録されます。
OAuthリクエストトークン
OAuthリクエストは、OAuthクライアントクレデンシャルズグラント形式でPOSTリクエストを行い、トークンの取得と更新を可能にします。
url、client_id、client_secret、およびオプションのscopeを提供してください。トークンサーバーの設定に基づき、JSONまたはフォームエンコードのリクエスト形式を選択します。
リクエストヘッダーとボディのプレビューが表示されます。
すべての必須フィールドを入力したら、テストリクエストをクリックします。
Intercomはレスポンスのパスaccess_tokenでトークンを探します。
テストが成功したらトークンを保存します。
HTTPリクエストトークンと同様に、データコネクターのリクエストが400、401、または403のレスポンスを受け取った場合、システムはトークンの更新を行います。
OAuthリクエストトークンは必要に応じてシステムによって自動的に更新されます。これらの更新は管理者によるものではなく、「System」または「Fin」として更新されたように表示されることがあります。
ユーザートークン
ユーザートークンは、ユーザー定義のトークンを使用してData connectorsを認証します。これらのトークンはサードパーティシステムによって作成および更新されます。最も一般的な例の1つはJSON Web Tokens（JWT）です。
JWTはユーザーの身元を安全に検証する方法です。この新しいタイプの認証トークンを使用してData connectorsを保護できます。これにより、システムとIntercom間の通信がより柔軟かつ安全になります。
Data connectorでトークンを使用する
トークンタイプが作成されたら：
設定 > 統合 > Data connectorsに移動し、設定したいコネクタを開きます。
APIタブを選択します。
Authentication tokensセクションで、ドロップダウンからトークンを選択します。
ユーザートークンの作成と更新
すべてのユーザートークン管理はサードパーティシステムによって行われます。
Intercom('boot', {
app_id: 'abc12345',
email: 'john.doe@example.com',
created_at: 1234567890,
name: 'John Doe',
user_id: '9876',
auth_tokens: {
security_token: 'abc...' // JWT
}
});
これらのサードパーティシステムはセキュリティトークンの更新と定期的なリフレッシュも担当します。
Intercom('update', {
app_id: 'abc12345',
auth_tokens: {
security_token: 'bcd...' // JWT
}
});
Intercom('setAuthTokens', {
security_token: 'abc...' // JWT
});
# Swift
Intercom.setAuthTokens({
security_token: 'abc...' // JWT
});
# Kotlin
Intercom.client().setAuthTokens({
security_token: 'abc...' // JWT
});
マルチトークンサポート
1つのData connectorに複数のトークンを添付できます。添付されるすべてのトークンは一意のヘッダーキー（例：Authorization、X-API-Key）で設定する必要があります。すべてのトークンはリクエストと共に送信されます。
この設定により、そのトークンを使ってData connectorsをWorkflowsまたはFin経由でトリガーできます。トークン値が更新されても、リアルタイムでリフレッシュされるため認証が途切れません。
Data connectorでユーザーごとのJWTを使用するには、「User」認証トークンを作成し、Messengerのintercom_user_jwtに頼るのではなく、auth_tokens（例：Intercom('setAuthTokens')）を通じて現在の値を提供してください。
ワンタイムパスコード（OTP）によるメール認証
OTPによるData connectorsのメール認証は、Data connector使用前に顧客がメールで送信された一意で時間制限のあるコードで本人確認を行う追加の検証ステップを提供します。
この方法はユーザー認証トークン（例：JWT）の上に追加のセキュリティ層を加えます。有効にすると、顧客はData connectorを進める前にメールベースの認証プロセスを完了する必要があります。これにより、認可されたユーザーのみが機密操作を実行でき、自動化されたWorkflowsの誤用を防ぎます。
Data connectorsの顧客認証
顧客認証は、Data connectorが実行される前に顧客の身元を確認します。APIトークン認証（サーバー間通信を保護）とは異なり、顧客認証はエンドユーザーの身元を確認し、認可された顧客のみが機密コネクタをトリガーできるようにします。
認証ルールは設定 > ワークスペース > セキュリティ > 顧客認証で設定され、認証が有効なすべてのData connectorsに適用されます。ルールはチャネルおよびオーディエンスごとに設定可能です。
フォールバックルールは、他に指定されていないすべてのチャネルとオーディエンスをカバーし、すべての認証済みコネクタを常に保護します。
新しいワークスペース
新しいワークスペースが作成されると、フォールバック認証ルールは自動的にEmail OTPに設定されます。これは、より具体的なルールで指定されていないすべてのチャネルとオーディエンスをカバーします。
ルールの追加
新しいチャネルまたはオーディエンスルールを作成すると、チャネルタイプに基づいてデフォルトの認証方法が適用されます：
チャネル | デフォルトの検証方法 |
Messenger（ウェブ、iOS、Android） | Messengerセキュリティ（JWT） |
その他すべてのチャネル | 検証なし（フォールバックルールが適用されます） |
検証方法
2つの検証方法があります：
Email OTP — 顧客のメールアドレスにワンタイムパスコードを送信します。顧客はコネクタが実行される前にこのコードを入力する必要があります。設定の詳細はワンタイムパスコードでData connectorsを保護するを参照してください。
Messengerセキュリティ（JWT） — 既存のMessengerの本人確認（User token）を使用します。MessengerセキュリティのJWT設定が必要です。詳細は上記のユーザートークンを参照してください。
ヒント：Messengerセキュリティ（JWT）は最も強力な本人確認を提供し、Messengerベースの会話に推奨される方法です。顧客に負担をかけずに本人確認を行います。
コネクタで認証を有効にする
認証は、適用したい各Data connectorで個別にオンにする必要があります：
設定 > 統合 > Data connectorsに移動し、コネクタを開きます。
セキュリティタブを選択します。
顧客認証をオンに切り替えます。
セキュリティチェックを完了し、保存してコネクタをライブに設定します。
有効にすると、コネクタは着信会話のチャネルとオーディエンスに適用されるワークスペースの認証ルールを強制します。
認証情報
認証情報ページ（設定 > 統合 > 認証情報）では、Data connectorsで使用されるすべての認証情報を一元的に確認できます。テーブルには名前、タイプ、作成者、最終更新者が表示され、外部システムへのアクセス監査が容易になります。
ロジック
テキストベースのトークンはシンプルです。Data connectorはテスト時やライブリクエスト時に割り当てられたトークン値を使用します。
HTTPリクエストトークンはより複雑なフローに従います。テストおよびライブのData connectorsでは、最新の取得済みトークンを最初に使用します。リクエストが失敗した場合、更新リクエストを送信し、新しいトークンで再試行します。この再試行は無限ループを避けるため1回のみ行われます。
更新リクエストの失敗によりData connectorが継続的に失敗すると、回路遮断器が作動し、繰り返し失敗するData connectorと同様の動作をします。
既知の制限事項
現在、テキストおよびHTTPリクエスト認証トークンタイプは顧客ごとに異なる認証リクエスト詳細をサポートしていません。通常、これは完全なOAuthフローとして要求されます。
認証トークンが作成されると、削除はできません。
自動生成されたStripeアプリトークンを使用するData connectorsは、ヘッダーが読み取り専用状態に固定されているため、マルチトークン機能をサポートしていません。変更するには、まずStripeトークンを削除または置換する必要があります。
Stripeトークンが選択されると、HTTPヘッダーセクションに新しいキーと値のペアを追加できません。