データコネクタの新しい認証方法を設定するには、設定 > Integrations > Authentication に移動し、トークンを追加をクリックします。

トークンを設定する主な方法は2つあります：事前設定されたプロバイダーに接続するか、カスタムトークンを作成するかです。

テキスト
HTTPリクエスト
OAuthリクエスト
ユーザー

事前設定されたプロバイダー（OAuth）に接続する

Salesforce、HubSpot、Attioなどのサポートされているプロバイダー向けに、認証を迅速かつシームレスにする3段階のOAuthフローを事前設定で提供しています。

これらのプロバイダーのいずれかに接続するには：

設定 > Integrations > Authentication に移動し、トークンを追加をクリックします。
ドロップダウンから希望のプロバイダーを選択します。
プロバイダーの認可ページにリダイレクトされます。要求された権限を確認し、接続を許可するために確認（または許可）をクリックします。

OAuthフローが完了すると、新しいアクセストークンが自動的にトークンリストに表示されます。

新しく作成したトークンをクリックすると、その設定が表示されます。これは事前設定された統合のため、名前と説明のフィールドのみ編集可能です。以下も表示されます：

API URL: データコネクタでこのプロバイダーにAPIコールを行う際に使用する基本URLです。クリップボードにコピーアイコンで簡単にコピーできます。
スコープ: トークンに付与された権限の読み取り専用リスト。

トークンの再認証

トークンがプロバイダー側で無効化または破損した場合、削除して再作成する必要はありません。トークンの詳細を開き、右上の再認証ボタンをクリックしてください。これによりOAuthフローが再度実行され、既存のトークンが自動的に更新され、接続されたデータコネクタが手動更新なしで動作し続けます。

カスタムトークンの作成

事前設定リストに含まれていないサービスに接続する必要がある場合：

設定 > Integrations > Authentication に移動し、トークンを追加をクリックします。
カスタムを選択します。
次に、ドロップダウンから作成したいトークンのタイプを選択します。

テキストトークン

テキストトークンは静的トークンです。トークンの名前、説明、値、トークンプレフィックス、およびトークンを含むリクエストヘッダーのキーを設定でき、これがデータコネクタのリクエストに挿入されます。

HTTPリクエストトークン

HTTPリクエストトークンは動的です。認証エンドポイントへのHTTPリクエストを設定し、必要に応じてトークンを更新します。これらのトークンは保存前に認証トークンUIからテストする必要があります。トークンの名前、説明、およびリクエスト自体に影響するフィールド（HTTPリクエストメソッド、URL、HTTPヘッダー、キーと値のペア）を設定できます。

テストリクエストをクリックしてトークンをテストし、レスポンス内のトークンの位置、トークンプレフィックス、およびリクエストヘッダーのキーを指定してください。

HTTPリクエストトークンがデータコネクタに割り当てられている場合、コネクタは最新の取得済みトークンをリクエストに使用します。リクエストが400、401、または403のレスポンスを返した場合、指定された認証エンドポイントURLにHTTPリクエストを送信してトークンを更新し、元のデータコネクタリクエストを新しいトークンで再試行します。

HTTPリクエストトークンはIntercomによって自動的に更新され、データコネクタの動作を維持します。これらの更新はバックグラウンドで行われ、人の操作なしに「System」または「Fin」として更新されたように表示されることがあります。

注意：サーバーがアクセス拒否のレスポンスに200を返す場合、トークンは更新されません。この場合、サーバーを400、401、または403を返すように更新する必要があります。

トークンの更新に問題がある場合、その問題はデータコネクタの「ログ」タブに記録されます。

OAuthリクエストトークン

OAuthリクエストは、OAuthクライアントクレデンシャルズグラント形式でPOSTリクエストを行い、トークンの取得と更新を可能にします。

url、client_id、client_secret、およびオプションのscopeを提供してください。トークンサーバーの設定に基づき、JSONまたはフォームエンコードのリクエスト形式を選択します。

リクエストヘッダーとボディのプレビューが表示されます。

必須フィールドをすべて入力したら、テストリクエストをクリックしてください。

Intercomはレスポンスのパスaccess_tokenでトークンを探します。

テストが成功したらトークンを保存します。

HTTPリクエストトークンと同様に、データコネクタのリクエストが400、401、または403のレスポンスを受け取った場合、システムはトークンを更新します。

OAuthリクエストトークンは必要に応じてシステムによって自動的に更新されます。これらの更新は管理者による操作ではなく、「System」または「Fin」として更新されたように表示されることがあります。

ユーザートークン

ユーザートークンは、ユーザー定義のトークンを使用してデータコネクタを認証できます。これらのトークンはサードパーティシステムによって作成および更新されます。最も一般的な例の一つはJSON Web Tokens（JWT）です。

JWTはユーザーの身元を安全に検証する方法です。この新しいタイプの認証トークンを使用してデータコネクタを保護できます。これにより、システムとIntercom間の通信がより柔軟かつ安全になります。

データコネクタでトークンを使用する

トークンタイプを作成したら：

設定 > Integrations > Data connectors に移動し、設定したいコネクタを開きます。
APIタブを選択します。
認証トークン セクションで、ドロップダウンからトークンを選択します。

ユーザートークンの作成と更新

すべてのユーザートークン管理はサードパーティシステムによって処理されます。

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 connectorをトリガーできます。WorkflowsまたはFin経由での利用が可能です。トークンの値が更新されても、リアルタイムでリフレッシュされるため、認証が途切れることなくData connectorは動作し続けます。

Data connectorでユーザーごとのJWTを使用するには、「User」認証トークンを作成し、その現在の値をauth_tokens（例：Intercom('setAuthTokens')）経由で提供してください。Messengerのintercom_user_jwtに依存しないでください。

ワンタイムパスコード（OTP）によるメール認証

OTPを使ったData connectorのメール認証は、Data connectorの使用前に、顧客がメールで送信される一意で時間制限のあるコードで本人確認を行う追加の検証ステップを提供します。

この方法は、ユーザー認証トークン（例：JWT）の上に追加のセキュリティ層を加えます。有効にすると、Data connectorを実行する前に顧客はメールベースの認証プロセスを完了する必要があります。これにより、権限のあるユーザーのみが機密操作を実行でき、自動化されたworkflowsの誤用を防ぎます。

Data connectorの顧客認証

顧客認証は、Data connectorが実行される前に顧客の本人確認を行います。APIトークン認証（サーバー間通信の保護）とは異なり、顧客認証はエンドユーザーの身元を確認し、権限のある顧客だけが機密性の高いconnectorをトリガーできるようにします。

認証ルールは設定 > ワークスペース > セキュリティ > 顧客認証で設定され、認証が有効なすべてのData connectorに適用されます。ルールはチャネルおよびオーディエンスごとに設定可能です。

フォールバックルールは、他に指定されていないすべてのチャネルとオーディエンスをカバーし、すべての認証されたconnectorが常に保護されるようにします。

新しいワークスペース

新しいワークスペースが作成されると、フォールバック認証ルールは自動的にEmail OTPに設定されます。これは、より具体的なルールで指定されていないすべてのチャネルとオーディエンスをカバーします。

ルールの追加

新しいチャネルまたはオーディエンスルールを作成すると、チャネルタイプに基づいてデフォルトの認証方法が適用されます：

チャネル	デフォルトの検証方法
Messenger（ウェブ、iOS、Android）	Messengerセキュリティ（JWT）
その他すべてのチャネル	検証なし（フォールバックルールが適用されます）

検証方法

2つの検証方法があります：

Email OTP — 顧客のメールアドレスにワンタイムパスコードを送信します。顧客はconnectorが実行される前にこのコードを入力する必要があります。設定の詳細はワンタイムパスコードによる安全なData connectorを参照してください。
Messengerセキュリティ（JWT） — 既存のMessengerの本人確認（User token）を使用します。Messengerセキュリティ（JWT）の設定が必要です。詳細は上記のUser tokensを参照してください。

ヒント：Messengerセキュリティ（JWT）は最も強力な本人確認を提供し、Messengerベースの会話に推奨される方法です。顧客に余計な手間をかけずに本人確認を行います。

connectorで認証を有効にする

認証は、適用したい各Data connectorで個別にオンにする必要があります：

設定 > 統合 > Data connectorに移動し、connectorを開きます。
セキュリティタブを選択します。
顧客認証をオンに切り替えます。
セキュリティチェックを完了し、保存してconnectorをライブに設定します。

有効にすると、connectorは受信会話のチャネルとオーディエンスに適用されるワークスペース認証ルールを強制します。

注意：Identity Verificationを必要とせずにData connectorを実行したい場合は、顧客認証を完全に無効にできます。connectorを開き、セキュリティタブを選択し、顧客認証をオフに切り替えてください。

セキュリティチェック

Data connectorを保存すると、Intercomは設定の潜在的なセキュリティリスクを自動的に表示します。これらはセキュリティタブの警告として表示され、connectorをライブに設定する前に確認する必要があります。各警告はリスクの説明と対処方法の推奨を提供します。

警告	意味	対処方法
顧客データ属性が検証されていません	顧客データ属性は、顧客が本人確認を行う前にFinによって更新される可能性があります。	このconnectorで顧客認証を有効にし、属性の更新が検証済みの本人に紐づくようにしてください。
このconnectorでFinが収集するデータは確認が必要です	Finは顧客から情報を収集してからAPIを呼び出します。この入力が検証されていない場合、バックエンドで未検証または改ざんされたデータが処理される可能性があります。	Finから受け取ったすべての入力をバックエンドで処理または保存する前に検証してください。サーバー側のチェックなしに顧客提供の値に依存しないでください。
このData connectorを使用するWorkflowsは確認が必要です	このコネクタを使用する1つ以上のWorkflowsが、十分なバックエンド検証なしに機密顧客データを公開している可能性があります。	フラグが立てられたWorkflowsを確認し、機密データの公開や誤用を防ぐためにバックエンド検証を追加してください。
このデータコネクタのリクエストヘッダーを確認する必要があります。	顧客の詳細（例えばメールアドレス）がリクエストヘッダーとして送信されています。例：`X-Intercom-Verified-Email`。バックエンドがこの値を検証しない場合、偽装や誤用の可能性があります。	バックエンドAPIが受け取るヘッダー値をそのまま信用せず、必ず検証するようにしてください。

注意：個別のコネクタ属性に表示される「Insecure」バッジ（例：検証されていないFin収集値）は、セキュリティタブの解決可能な警告とは異なります。これは未検証・安全でない値に対する恒久的な指標であり、コネクタ編集画面での解除操作では消えず、属性を確認して安全と判断しても再表示されます。これは解決や恒久的な解除ができるアラートではなく、値が顧客認証を通じて検証されていないことを示すものです。この属性のフラグを止めたい場合は、コネクタで顧客認証を有効にし（上記参照）、値を検証済みのIDに紐づける必要があります。

認証情報

認証情報ページ（設定 > 統合 > 認証情報）では、すべてのデータコネクタで使用される認証情報を一元的に確認できます。テーブルには名前、タイプ、作成者、最終更新者が表示され、外部システムへのアクセス監査が容易になります。

ロジック

テキストベースのトークンは単純です。Data connectorはテスト時やライブリクエスト時に割り当てられたトークン値を使用します。

HTTPリクエストトークンはより複雑なフローに従います。テストおよびライブのData connectorでは、まず最新の取得トークンを使用します。リクエストが失敗した場合、リフレッシュリクエストを送り、新しいトークンで再試行します。この再試行は無限ループを避けるため1回だけ行われます。

リフレッシュリクエストの失敗によりData connectorが継続的に失敗すると、繰り返し失敗したData connectorと同様にサーキットブレーカーが作動します。

既知の制限事項

現在、TextおよびHTTP Request認証トークンタイプは顧客ごとに異なる認証リクエスト詳細をサポートしていません。通常これは完全なOAuthフローとして要求されます。
認証トークンが作成された後は、削除できません。
自動生成されたStripeアプリトークンを使用するData connectorsは、ヘッダーが読み取り専用状態に固定されているため、マルチトークン機能をサポートしていません。変更するには、まずStripeトークンを削除または置き換える必要があります。
Stripeトークンが選択されると、HTTPヘッダーセクションに新しいキーと値のペアを追加できません。

データコネクタの認証設定