sub クレームによる認証

ユーザーの認証にこの方法を使用するには、まず Web チャットのセキュリティ機能を有効にする必要があります。 詳しくは、 Web チャット・セキュリティーの有効化 を参照してください。

Web チャット用の JWT を作成する場合は、ユーザーを識別する sub (サブジェクト) クレームの値を指定する必要があります。 匿名ユーザーの場合は、生成された固有 ID を使用できます。

匿名ユーザーのユーザー ID を生成する場合は、同じ顧客に対して複数回請求されないように、生成された ID を必ず Cookie に保存してください。

Web チャット統合は、この JWT で署名されたメッセージを受信すると、 sub クレームからのユーザー ID をアクションの system_integrations.channel.private.user.id およびダイアログの integrations.channel.private.user.id として保管します。 詳しくは、 統合変数 を参照してください。

顧客が Web チャット・セッションを開始する前にログインする必要がある場合は、JWT の作成時に sub クレームの値として認証済みユーザー ID を使用できます。 Web チャット統合は JWT を検証し、 sub クレームを使用してユーザー ID を設定するため、アシスタントは、許可を必要とする機能へのセキュア・アクセス制御のために、アクションの system_integrations.channel.private.user.id とダイアログの integrations.channel.private.user.id に依存できるようになりました。

Web チャット用に JWT を指定した後は、セッション中に別の sub クレームを持つ JWT に変更することはできません。 セッションの途中で認証済みログイン情報を追加する必要がある場合は、代わりにその情報をユーザー・ペイロードの一部として保管できます。 これを行う方法の例については、 チュートリアル: セッションの途中でのユーザーの認証 を参照してください。

請求およびプライバシー

ユーザーベースのプランの場合、ユーザーIDは課金目的で使用されます。 (Web チャット・セキュリティーが有効になっている場合、 updateUserID() インスタンス・メソッドを使用してユーザー ID を設定することはできません。) 同じユーザー ID がカスタマー ID としても使用されます。これを使用して、ユーザー・データを削除する要求を行うことができます。 カスタマー ID はヘッダー・フィールドで送信されるため、指定する ID は、 RFC 7230で定義されているヘッダー・フィールドの要件を満たしている必要があります。

GDPR 要件に準拠する必要がある場合は、生成された匿名ユーザー ID を永続的に保管する必要があります (特に、後でユーザー資格情報を使用してログインする匿名ユーザーの場合)。 これらのユーザー ID を保管すると、個々の顧客に関連付けられているすべてのデータを後で削除するように要求された場合に、削除することができます。

ユーザー・ベースの請求処理について詳しくは、 ユーザー・ベースのプランの説明 を参照してください。 ユーザー・データの削除について詳しくは、 データのラベル付けと削除 を参照してください。

ログアウト

お客様をログアウトするには、Web チャットを破棄する必要があります。

顧客がログアウトしたときにページを再ロードする場合は、 destroySession() インスタンス・メソッドを呼び出して、ブラウザーの Cookie およびストレージから現行セッションへの参照をすべて削除します。 このメソッドを呼び出さない場合、JWTによって保護されている情報は危険にさらされませんが、ウェブチャットは以前のセッションに接続しようとして失敗します。

お客様がログアウトしたときにフルページ再ロードを実行しない場合は、 destroy() インスタンス・メソッドを呼び出します。 destroy メソッドは、現在の userIDに設定されているウェブチャットの現在のインスタンスをDOMとブラウザのメモリから削除します。 次に、 destroySession() インスタンス・メソッドを呼び出します。