エンドユーザーの認証は、多くのビジネス目的において重要です。会話型サポートを提供する場合、ユーザーはデバイスやチャネルを変えながら会話を続けようとするかもしれません。エンドユーザーを認証することで、すべてのタッチポイントが同じエンドユーザーに確実に関連付けられます。これにより、エージェントが提供するサポートの質を向上させ、エージェントがサポートする際にエンドユーザーに提供を求める個人情報のセキュリティを高めることができます。
メッセージングのエンドユーザー認証について
- エージェントが会話しているエンドユーザーが、本人であるという信頼性を高める。
- 複数のドメインにウィジェットを埋め込んだり、Shopifyのような外部サービスにリンクしていたりする場合に、1人のユーザーをすべてのチャネルにわたって識別できるようにする。
- 端末やブラウザが変わっても、1人のユーザーを識別できるようにする。
メッセージングの認証に関する用語
- JWT：Zendeskでは、メッセージングのエンドユーザー認証に署名されたJSON Webトークン（JWT）を使用します。これらのトークンには、エンドユーザーの本人確認を行うための情報が含まれています。JWTの詳細については、jwt.ioを参照してください。
- 署名キー：Zendeskの管理者が管理センターで作成し、チーム内の開発者と共有します。開発者はこの署名キーを使用して、必要に応じてJWTに署名を行います。
- 外部ID：外部システムで使用されているユーザー名またはIDなど、各ユーザーに一意の英数字から成る文字列。メールアドレスがJWTに含まれている場合でも、これはメッセージング認証における重要な識別子となります。
- ユーザー名：（オプション）外部IDまたはメールアドレスに関連付けられたエンドユーザーの名前。JWTに含めたユーザー名が、エージェントワークスペースに表示されます。ユーザー名の情報は、エージェントがエンドユーザーとコミュニケーションを取る際に役立ちます。
- メールアドレス：（オプション）エンドユーザーに関連付けられた一意のメールアドレス。
メッセージングのエンドユーザー認証の実装の概要
- メッセージング認証のプロセスでは、まず管理者が署名キーを生成して開発者に提供します。次に、開発者は署名キーを使用してバックエンドサービスを実装し、要求に応じてユーザーの署名付きJWTを作成できるようにします。
- 要求されると、バックエンドサービスは署名付きJWTを作成し、Webサイトやモバイルアプリに返します。このサービスによって作成されるJWTには、エンドユーザーを識別するための一意の外部IDと、オプションでメールアドレスを含める必要があります。
- ユーザーがログインするたびに、Webサイトやアプリは、Web WidgetやモバイルSDKで利用可能な同等のログインAPIを呼び出す必要があります。その際にJWTがZendeskに渡され、ユーザーの本人確認が行われます。
メッセージングのエンドユーザー認証の要件
- Zendeskエージェントワークスペースがアクティブになっている。
- メッセージングをWeb WidgetチャネルまたはモバイルSDKチャネルで使用している。
- メールIDをエンドユーザーに関連付けている。
- 認証済みユーザーに確認済みのメールIDを関連付ける場合は、エンドユーザーに発行するJWTに
emailとemail_verified: trueの両方のクレームを含める必要がある。
メッセージングのエンドユーザー認証時のエージェントエクスペリエンス
訪問者のエンドユーザーが認証されている場合、名前の横に緑色のチェックマークアイコンが表示され、エンドユーザーの外部IDがユーザープロフィールの横に表示されます。
さらに、認証後にエンドユーザーが投稿した各応答には、チェックマークのアイコンが付きます。
認証されたエンドユーザーは、デバイス間で同期的に会話に参加できます。認証されていないエンドユーザーの場合、使用するデバイスごとに個別にユーザーレコードと会話が作成されます。エンドユーザーが会話の途中で認証を行うと、認証前と後の会話が自動的に統合され、エージェントとエンドユーザーに継続性が提供されます。
メールIDを使用している場合、エンドユーザーのユーザーレコードへのマッピングは、メールIDの設定によって異なります。ほとんどの構成では、偽者は個別のユーザーレコードとして表示され、正常に認証されないため、名前の横に緑色のチェックマークは付きません。未認証のユーザーが確認済みメールアドレスの所有権を主張することを許可する場合、そのメールアドレスのIDは、アドレスの所有権を申し立てた最初のユーザーに関連付けられます。2人のエンドユーザーが同じアドレスの所有権を主張した場合、メールIDは、メールアドレスを認証および確認できるエンドユーザーのユーザーレコードに紐付けられます。
競合が発生した場合には、確認済みメールIDのほうが未確認のメールIDよりも優先されます。たとえば、未認証のユーザーから提供されたメールアドレスが、すでに認証済みのIDに関連付けられている場合、Zendeskは、認証済みユーザーになりすまそうとしている未認証のユーザーのために、メールアドレスなしで未認証のセッションとユーザーレコードを新たに作成します。同様に、未認証のユーザーから提供されたメールアドレスを確認できなかったが、後で別のユーザーがそのメールアドレスを提供して確認し、JWTでサインインできた場合、そのメールアドレスは認証されたユーザーに紐付けられ、未認証ユーザーのレコードから削除されます。
エージェントは、重複したユーザーレコードを統合したり、ユーザーレコードにメールIDを手動で追加したりすることができます。これらの操作を実行する前に、エンドユーザーに対して本人確認チェックを行うよう、エージェントをトレーニングすることをお勧めします。
メッセージングの認証時のエンドユーザーエクスペリエンス
メッセージングにエンドユーザー認証を実装しても、エンドユーザーはあまり違いを感じないはずです。Zendeskによるエンドユーザー認証で本人確認が行われた後は、メッセージングのデフォルトの応答の中で、メッセージングボットから名前やメールアドレスの入力を求められることはありません。
エンドユーザーが認証されると、認証されたエンドユーザーの会話がデバイス間で同期されます。未認証のエンドユーザーの場合、個別にユーザーレコードと会話が作成されます。エンドユーザーが会話の途中で認証を行うと、サインインする前に行なわれた匿名の会話が認証後の会話と自動的に統合され、会話の継続性が保たれます。
署名キーの作成と共有
署名キーは、開発者がエンドユーザー用にJWTを作成するために使用します。署名キーを作成するには、管理者であることが必要です。最大10個のキーを作成できます。上限の10個に達した後にさらにキーを作成しようとすると、未使用のキーを削除するように求められます。
- 管理センターで、サイドバーの「
アカウント」をクリックし、「セキュリティ」>「エンドユーザー認証」を選択します。 - 「メッセージング」タブをクリックし、「キーを作成」をクリックします。
初めてキーを作成する場合は、「キーを作成」がページの一番下に表示されます。一番下に表示されない場合は、右上に表示されます。
- キーの「名前」を入力し、「次へ」をクリックします。
- プロンプトが表示されたら、「コピー」をクリックして共有シークレットをコピーし、「キーを永久に非表示にする」をクリックします。
キーが保存され、IDが自動的に割り当てられます。キーのIDは、「エンドユーザー認証」ページの「メッセージング」タブにあるキーのリストで確認できます。
- 誰にも知られないように、キーのIDとコピーした共有シークレットを開発者に渡します。
外部IDのみによるエンドユーザーの認証
-
external_id：（必須）各ユーザーを識別するために使用できる一意の英数字文字列です。通常、これらのIDは外部システムから取得されます。IDは255文字を超えることはできません。
Zendeskは、メッセージングで認証するユーザーのメインの識別子として
external_idを使用します。有効なJWTでユーザーを認証する際、Zendeskはまずexternal_idで既存のユーザーを解決します。external_idに一致するものが見つからない場合、ユーザーは、提供されたメールアドレスを使用して特定されます。詳しくは「メールアドレスを含むJWTを発行する」を参照してください。 -
scope：（必須）呼び出し元のアクセスのスコープ。有効な値は
userのみです。 - name：（オプション）ユーザーの名前。JWTペイロードに名前を含めることで、Zendeskがエージェントワークスペースにユーザーの名前を表示できるようになり、エージェントがよりカスタマイズされたサポートを提供できるようになります。
{
"external_id": "12345678",
"scope": "user",
"name": "Jane Soap"
}メールIDをエンドユーザー認証に組み込む
- 認証済みユーザーは、署名されたJWTによって認証されます。
JWTを使用すると、署名されたJWTの内容がエンドユーザーによって改ざんされることはないため、信頼できる方法となります。なりすまし攻撃の懸念がある場合は、メールIDの使用を認証済みエンドユーザーのみに制限することをお勧めします。この方法は最も安全なオプションであり、Zendeskアカウントの新規作成時のデフォルトになっています。
- 未認証ユーザーとは、Zendeskボットのプロンプトに対してメールアドレスを提供するエンドユーザーです。
なお、未認証ユーザーにメールIDの使用を許可すると、自分のものでないメールアドレスを渡して他のユーザーになりすますおそれがあり、なりすまし攻撃に対してセキュリティが脆弱になる可能性があります。
メールIDを設定する
新しいZendeskアカウントでは、メールIDがオンになっており、確認済みのメールアドレスのみを使用するように設定されています。これが最も安全なオプションです。古いアカウントでは、認証済みのメールアドレスと未認証のメールアドレスの両方を使用するように設定されています。メールアドレスをJWTに追加する前に、オプションを確認し、必要に応じて設定を更新する必要があります。
- 管理センターで、サイドバーの「
チャネル」をクリックし、「メッセージングとソーシャル」>「メッセージング」を選択します。 - 「設定を管理」をクリックします。
- 「メールID」をクリックし、次のオプションのいずれかを選択します。
-
確認済みメールのみを使用する：メールIDは、発行されたJWTに確認済みのメールアドレスが含まれている、認証済みのユーザーに対してのみ作成されます。エージェントはユーザーレコードにメールIDを手動で追加することができます。
このオプションを使用すると、エージェントは未認証のエンドユーザーから提供されたメールアドレスをチャット履歴で確認できますが、基本情報カードでユーザーに紐づけられたメールIDを見ることはできません。未認証のユーザーをメールでフォローアップする必要がある場合、エージェントは、そのユーザーレコードにメールIDを手動で追加する必要があります。未認証ユーザーのメールアドレスがすでに別のユーザーレコードに存在する場合、エージェントは2つのユーザーレコードを1つに統合することができます。
手動でメールIDを追加したり、2つのユーザーレコードを統合したりする前に、ソーシャルエンジニアリング攻撃を防ぐために、エージェントに本人確認チェックを実行させることをお勧めします。
-
確認済みメールと未確認メールの両方を使用するにはメールIDは、JWTに確認済みのメールアドレスが含まれている認証済みユーザーと、ボットフローを通じてメールアドレスを提供する未認証のユーザーの両方に対して作成されます。このオプションを使用すると、エージェントは、基本情報カードでエンドユーザーのメールアドレスを見つけやすくなり、未認証のメールアドレスのメールIDは、エージェントワークスペースで未認証として明確にマークされます。エージェントは、補足メールを送る必要が生じた場合に備えて、エンドユーザーに認証するよう求めることができます。
競合が発生した場合には、確認済みメールIDのほうが未確認のメールIDよりも優先されます。
-
確認済みメールのみを使用する：メールIDは、発行されたJWTに確認済みのメールアドレスが含まれている、認証済みのユーザーに対してのみ作成されます。エージェントはユーザーレコードにメールIDを手動で追加することができます。
- （オプション、ただし非推奨）未認証のユーザーであっても、メールアドレスを確認済みメールアドレスとして利用できるようにしたい場合は、「未認証のユーザーが確認済みメールアドレスの所有権を主張できる」を選択します。
このオプションを選択すると、メッセージングチャネルから収集されたメールIDの確認ステータスは信頼できなくなります。なぜなら、ユーザー認証が行なわれた後に現れた偽者によって、その後のメッセージングのやりとりでそのメールのステータスが乗っ取られる可能性があるためです。これはつまり、なりすまし攻撃が成功する可能性が高くなり、エージェントはエンドユーザーが本人であるかどうかを知る手段が限られます。しかし、確認済みのメールIDは未確認のメールIDよりも優先され、確認済みのメールIDは偽者のユーザーレコードから削除されます。
- 「設定を保存」をクリックします。
メールアドレスを含むJWTを発行する
-
external_id：（必須）各ユーザーを識別するために使用できる一意の英数字文字列です。通常、これらのIDは外部システムから取得されます。IDは255文字を超えることはできません。
Zendeskは、メッセージングで認証するユーザーのメインの識別子として
external_idを使用します。有効なJWTでユーザーを認証する際、Zendeskはまずexternal_idで既存のユーザーを解決します。external_idに一致するものが見つからない場合、ユーザーは、提供されたメールアドレスを使用して特定されます。詳しくは「メールアドレスを含むJWTを発行する」を参照してください。 -
scope：（必須）呼び出し元のアクセスのスコープ。有効な値は
userのみです。 - name：（オプション）ユーザーの名前。JWTペイロードに名前を含めることで、Zendeskがエージェントワークスペースにユーザーの名前を表示できるようになり、エージェントがよりカスタマイズされたサポートを提供できるようになります。
-
email：（必須）サインインしているユーザーのメールアドレス。ユーザーに一意のものでなければなりません。
メールアドレスを、エージェントワークスペースのユーザーのメインのメールアドレスと照合するように設定します。セカンダリメールアドレスをJWTに含めることはサポートされていません。
-
email_verified：（オプション）当該エンドユーザーがメールアドレスのオーナーシップを証明したかどうか。エンドユーザーに確認済みメールIDを関連付けたい場合、発行するJWTに
emailと"email_verified": trueの両方のクレームを含める必要があります。
{
"external_id": "12345678",
"email": "janes@soap.com",
"email_verified": true,
"name": "Jane Soap",
"scope": "user"
}JWTにおける外部IDとメールアドレスの競合を解決する
Zendeskは外部IDをメインの識別子として使用し、メールアドレスは外部IDに一致するものが見つからない場合にのみ使用します。ただし、JWTで提示されたメールアドレスがすでに別の外部IDに関連付けられている場合、ZendeskはそのJWTを拒否し、エンドユーザーのログイン試行は失敗します。この場合、ユーザーは未認証状態で会話が開始されます
- JWTを更新して、異なる
external_id値またはemailアドレスを使用します。または
- 競合する
external_idを持つユーザーを削除し、別のエンドユーザーが使用できるように解放します。Sunshine Conversations APIの「Delete User」を参照してください。