メッセージングのユーザー認証の設定

現在のプランを確認

Suite

すべてのプラン

会話型サポートを提供する場合、ユーザーは複数のデバイスやチャネルを切り替えながら会話を続けることがあります。エンドユーザーを認証することで、すべてのタッチポイントが同じエンドユーザーに確実に関連付けられます。これにより、エージェントが提供するサポートの質を向上させ、エージェントがサポートする際にエンドユーザーに提供を求める個人情報のセキュリティを高めることができます。

この記事では、以下のトピックについて説明します。

• メッセージングの認証に関する用語
• メッセージングのエンドユーザー認証の実装の概要
• 署名キーの作成と共有
• 外部IDのみによるエンドユーザーの認証
• ユーザー認証へのメールIDの組み込み
• JWTにおける外部IDとメールアドレスの競合の解決

関連記事：メッセージングのユーザー認証について

メッセージングの認証に関する用語

メッセージング認証を実装する際は、ユーザーとエージェントのメッセージング認証エクスペリエンスだけでなく、以下の用語を理解することも重要です。

• JWT：Zendeskでは、メッセージングのエンドユーザー認証に署名されたJSON Webトークン（JWT）を使用します。これらのトークンには、エンドユーザーの本人確認を行うための情報が含まれています。JWTの詳細については、jwt.ioを参照してください。
• 署名キー：Zendeskの管理者が管理センターで作成し、チーム内の開発者と共有します。開発者はこの署名キーを使用して、必要に応じてJWTに署名を行います。
• 外部ID：外部システムで使用されているIDなど、各ユーザーに一意の英数字から成る文字列。メールアドレスがJWTに含まれている場合でも、これはメッセージング認証における重要な識別子となります。
• ユーザー名：（オプション）外部IDまたはメールアドレスに関連付けられたエンドユーザーの名前。JWTに含めたユーザー名が、エージェントワークスペースに表示されます。ユーザー名の情報は、エージェントがエンドユーザーとコミュニケーションを取る際に役立ちます。
• メール：（オプション）エンドユーザーに関連付けられた一意のメールアドレス。

メッセージングのエンドユーザー認証の実装の概要

ZendeskはJSON Webトークン（JWT）を使用して、メッセージング相手のエンドユーザーを認証し、ステートレスかつ柔軟な方法でユーザーIDを検証してAPIエンドポイントを保護します。

メッセージングにエンドユーザー認証を実装するには、管理者と開発者の協力が必要です。

1. メッセージング認証のプロセスでは、まず管理者が署名キーを生成して開発者に提供します。次に、開発者は署名キーを使用してバックエンドサービスを実装し、要求に応じてユーザーの署名付きJWTを作成できるようにします。
2. 要求されると、バックエンドサービスは署名付きJWTを作成し、Webサイトやモバイルアプリに返します。このサービスによって作成されるJWTには、エンドユーザーを識別するための一意の外部IDと、オプションでメールアドレスを含める必要があります。
3. ユーザーがログインするたびに、Webサイトやアプリは、Web WidgetやモバイルSDKで利用可能な同等のログインAPIを呼び出す必要があります。その際にJWTがZendeskに渡され、ユーザーの本人確認が行われます。

開発者向けの詳しい情報については、「Enabling authenticated visitors for messaging with Zendesk SDKs」を参照するか、次のビデオをご覧ください。

Webメッセージングでのエンドユーザーの認証（17:22）

署名キーの作成と共有

署名キーは、開発者がエンドユーザー用にJWTを作成するために使用します。署名キーを作成するには、管理者であることが必要です。最大10個のキーを作成できます。上限の10個に達した後にさらにキーを作成しようとすると、未使用のキーを削除するように求められます。

署名キーを作成および共有するには

1. 管理センターで、サイドバーの「 アカウント」をクリックし、「セキュリティ」>「エンドユーザー認証」を選択します。
2. 「メッセージング」タブをクリックし、「キーを作成」をクリックします。

   初めてキーを作成する場合は、「キーを作成」がページの一番下に表示されます。一番下に表示されない場合は、右上に表示されます。

3. キーの「名前」を入力し、「次へ」をクリックします。
4. プロンプトが表示されたら、「コピー」をクリックして共有シークレットをコピーします。

   キーが保存され、IDが自動的に割り当てられます。キーのIDは、「エンドユーザー認証」ページの「メッセージング」タブにあるキーのリストで確認できます。

5. 誰にも知られないように、キーのIDとコピーした共有シークレットを開発者に渡します。
6. 「キーを永久に非表示にする」をクリックします。

外部IDのみによるエンドユーザーの認証

エンドユーザーを認証するには、ユーザーに発行するJWTに外部IDを含める必要があります。ZendeskはJWTで提供される外部IDを、メッセージングにおけるユーザー認証の主要な識別子として使用します。ユーザー認証を行う際、Zendeskはまず外部IDに一致する既存のユーザーを解決します。外部IDに一致するユーザーが存在しない場合に限り、JWTにメールアドレスが含まれていれば、そのアドレスを使用してユーザーIDを解決します。

外部IDのみでJWTに署名する

管理者が署名キーを作成した後、チームの開発者はそのキーを使用して、エンドユーザーのためにJWTを生成するサービスを作成できます。開発者が外部IDを使用してJWTを作成する場合、JWTペイロードには以下の情報を含める必要があります。

• external_id：（必須）各ユーザーを識別するために使用できる一意の英数字文字列です。詳しくは「ユーザーに発行するJWTで使用する外部IDを選択する」を参照してください。
• scope：（必須）呼び出し元のアクセスのスコープ。有効な値はuserのみです。
• name：（オプション）ユーザーの名前。JWTペイロードに名前を含めることで、Zendeskがエージェントワークスペースにユーザーの名前を表示できるようになり、エージェントがよりカスタマイズされたサポートを提供できるようになります。

以下はその例です。

{
    "external_id": "12345678",
    "scope": "user",
    "name": "Jane Soap"
}

ユーザーに発行するJWTで使用する外部IDを選択する

ユーザーに発行するJWTの外部IDを決定する際は、以下の要件と期待を考慮してください。

• 外部IDは英数字から成る文字列であること。
• 外部IDは最大255文字まで。
• 各ユーザーの外部IDが、アカウントレベルでグローバルに一意であること。

  アカウントに複数のブランドがある場合、外部IDはすべてのブランドで一意でなければなりません。

• ユーザーの外部IDは決して変更してはならない。
• ユーザーに割り当てられる外部IDは1つだけ。

外部IDの適切な選択例としては、最初のコンタクト時に割り当てられるインクリメントIDまたはランダム化ID（例：usr_12345）、あるいは、複数のブランドについては、ブランド固有の識別子とインクリメンタルIDまたはランダム化IDを組み合わせたもの（例：brand1_a8dedg）などがあります。

ユーザーのメールアドレスと電話番号は、時間の経過とともに変更されることがあり、複数の値を持つ場合もあるため、使用は避けてください。また、ユーザー名も一意でない可能性があるので避けてください。

ユーザー認証へのメールIDの組み込み

外部IDに加えて、認証済みユーザー、未認証ユーザー、またはその両方でメールIDを使用することを選択できます。

• 認証済みユーザーは、署名されたJWTによって認証されます。

  JWTを使用すると、署名されたJWTの内容がエンドユーザーによって改ざんされることはないため、信頼できる方法となります。なりすまし攻撃の懸念がある場合は、メールIDの使用を認証済みエンドユーザーのみに制限することをお勧めします。この方法は最も安全なオプションであり、Zendeskアカウントの新規作成時のデフォルト設定になっています。

• 未認証ユーザーとは、Zendeskボットのプロンプトに対してメールアドレスを提供するエンドユーザーです。

  なお、未認証ユーザーにメールIDの使用を許可すると、自分のものでないメールアドレスを渡して他のユーザーになりすますおそれがあり、なりすまし攻撃に対してセキュリティが脆弱になる可能性があります。

ヒント：コミュニティメンバーThomas Verschoren氏によるブログ記事：メッセジング認証：メールアドレスを確認し、メールアドレスに基づいて既存のユーザーをマージする

以下のフローチャートに、メッセージング認証でメールIDをどのように使用できるかを示します。

フルサイズを表示

メールIDを設定する

Web Widgetやモバイルアプリを利用する際、ユーザーはフォームやAIエージェントのプロンプトに応じてメールアドレスを提供できます。このようなシナリオでは、悪意のあるユーザーが他人のメールアドレスを提供してなりすますことを防ぐ仕組みがありません。しかし、外部IDとメールアドレスの両方でユーザーを認証するためにJWTを使用することは、単にユーザーにメールアドレスを割り当てるよりも信頼性の高い方法です。

設定によっては、エージェントはフォームから収集したメールアドレスとJWTから提供されたメールアドレスの両方をユーザープロフィールで見ることができます。新しいZendeskアカウントでは、メールアドレスが有効になっており、確認済みのメールアドレスのみを使用するように設定されています。これが最も安全なオプションです。古いアカウントでは、認証済みのメールアドレスと未認証のメールアドレスの両方を使用するように設定されています。

メールIDを有効にするには

1. 管理センターで、サイドバーの「 チャネル」をクリックし、「メッセージングとソーシャル」>「メッセージング」を選択します。
2. 「設定を管理」をクリックします。
3. 「メールID」をクリックし、次のオプションのいずれかを選択します。
   • 確認済みメールのみを使用する：（デフォルト）メールIDは、発行されたJWTに確認済みのメールアドレスが含まれている、認証済みのユーザーに対してのみ作成されます。
   • 確認済みメールと未確認メールの両方を使用する：認証されたユーザーのメールアドレスがユーザープロフィールに表示されることに加え、AIエージェントフローを通じてユーザーから提供された未確認のメールアドレスもユーザープロフィールに追加されます。
4. （非推奨）未認証のユーザーであっても、メールアドレスを確認済みメールアドレスとして利用できるようにしたい場合は、「未認証のユーザーが確認済みメールアドレスの所有権を主張できる」を選択します。
5. 「設定を保存」をクリックします。

確認済みメールのみを使用する

メールIDは、発行されたJWTに確認済みのメールアドレスが含まれている、認証済みのユーザーに対してのみ作成されます。

このオプションを使用すると、エージェントは未認証のエンドユーザーから提供されたメールアドレスを会話履歴で確認できますが、そのユーザーに紐づけられたメールIDを見ることはできません。未認証のユーザーをメールでフォローアップする必要がある場合、エージェントは、そのユーザーレコードにメールIDを手動で追加する必要があります。

メモ：手動でメールIDを追加したり、2つのユーザーレコードを統合したりする前に、ソーシャルエンジニアリング攻撃を防ぐために、エージェントに本人確認チェックを実行させることをお勧めします。

確認済みメールと未確認メールの両方を使用する

認証されたユーザーのメールアドレスがユーザープロフィールに表示されることに加え、AIエージェントフローを通じてユーザーから提供された未確認のメールアドレスもユーザープロフィールに追加されます。

このオプションは、悪意のあるユーザーがまだなりすまし攻撃を試みる可能性があるため、セキュリティ面で劣ります。ただし、エージェントはユーザープロフィールを検査し、メールアドレスが確認済みかどうかを判断することができます。未確認のメールアドレスは、エージェントワークスペースで目立つように表示されます。エージェントが補足メールを送信する必要がある場合、エンドユーザーの身元の信頼性を高めるために、セキュリティ質問を使用して本人確認を行うよう指示できます。

競合が発生した場合には、確認済みメールIDの方が未確認のメールIDよりも優先されます。これにより、なりすましによる未確認メールアドレスの不正使用を防ぎます。たとえば、未認証のユーザーがメールアドレスを提供し、それが後に認証されたユーザーによって確認済みメールアドレスとしてJWTで提供された場合、メールIDは確認済みメールに移動します。

イベントの順序	イベント	結果のメールID
1	認証されていないユーザーが、フォーム収集されたメールアドレスを提供する。例：[e-mail]	Zendeskは未認証の新規ユーザー（id:12345）を作成し、未確認のメールID（[e-mail]）を使用する。
2	認証されたユーザーには、以下のクレームを持つJWTが発行される。 external_id：1A23B email：[e-mail] email_verified：true	Zendeskは未認証の新規ユーザー（id:22345）を作成し、確認済みのメールID（[e-mail]）を使用する。 確認済みのメールIDに置き換えられたため、未認証のユーザー（id:12345）は未確認のメールIDを失う。

未認証ユーザーが確認済みメールアドレスの所有権を主張できるようにする（非推奨）

他のメールIDオプションとは対照的に、この設定では、プロンプトが表示されたときにそのユーザーのメールアドレスを入力するだけで、ユーザーが確認済みユーザーのIDを引き継ぐことができます。このオプションを選択すると、確認済みのメールアドレスが未確認のメールアドレスに優先されなくなります。

この方法は安全性が最も低く、なりすまし攻撃を受けやすいオプションです。AIエージェント機能が一時停止しているときに、プロアクティブメッセージをAIエージェント用から人間のエージェント用に更新した場合、アカウントで自動解決が再び利用可能になったときに手動でメッセージを再開する必要があります。

このオプションを選択すると、メッセージングチャネルで収集されたメールIDの確認ステータスは信頼できなくなります。これは、ユーザー認証後に現れたなりすましによって、その後のメッセージングのやりとりでそのメールのステータスが乗っ取られる可能性があるためです。これはつまり、なりすまし攻撃が成功する可能性が高くなり、エージェントはエンドユーザーが本人であるかどうかを知る手段が限られます。しかし、確認済みのメールIDは未確認のメールIDよりも優先され、確認済みのメールIDはなりすましのユーザーレコードから削除されます。

メールアドレスを含むJWTを発行する

メールIDを使用している場合、エンドユーザーに発行するJWTに以下の2つのクレームを追加する必要があります。つまり、JWTには以下のフィールドが含まれることになります。

• external_id：（必須）各ユーザーを識別するために使用できる一意の英数字文字列です。詳しくは「ユーザーに発行するJWTで使用する外部IDを選択する」を参照してください。
• scope：（必須）呼び出し元のアクセスのスコープ。有効な値はuserのみです。
• name：（オプション）ユーザーの名前。JWTペイロードに名前を含めることで、Zendeskがエージェントワークスペースにユーザーの名前を表示できるようになり、エージェントがよりカスタマイズされたサポートを提供できるようになります。

• email：（必須）サインインしているユーザーのメールアドレス。ユーザーに一意のものでなければなりません。

  メールアドレスを、エージェントワークスペースのユーザーのメインのメールアドレスと照合するように設定します。セカンダリメールアドレスをJWTに含めることはサポートされていません。

• email_verified：（オプション）当該エンドユーザーがメールアドレスのオーナーシップを証明したかどうか。エンドユーザーに確認済みメールIDを関連付けたい場合、発行するJWTにemailと"email_verified": trueの両方のクレームを含める必要があります。

以下はその例です。

{
    "external_id": "12345678",
    "email": "[e-mail]",
    "email_verified": true,
    "name": "Jane Soap",
    "scope": "user"
}

JWTにおける外部IDとメールアドレスの競合の解決

Zendeskは外部IDをメインの識別子として使用し、メールアドレスは外部IDに一致するものが見つからない場合にのみ使用します。

メッセージング認証は、競合を回避できるよう考慮して実装するのが最善です。たとえば、外部IDとZendeskのメール設定が競合しないように選択します。ただし、JWTで提示されたメールアドレスがすでに別の外部IDに関連付けられている場合、ZendeskはそのJWTを拒否し、エンドユーザーのログイン試行は失敗します。この場合、ユーザーは未認証状態で会話が開始されます

JWTで外部IDとメールの競合を解決するには

• JWTを更新して、異なる external_id 値または email アドレスを使用します。

  または

• 競合する external_id を持つユーザーを削除し、別のエンドユーザーが使用できるように解放します。Sunshine Conversations APIの「Delete User」を参照してください。