認証イベントの配信を、署名と再送の仕組みを独自に開発せずに実現

この会社は、既存のログインの仕組みにパスキーによる認証を加えるサービスを提供しています。利用者は自らが運営するウェブサービスや業務システムに同社のサービスを組み込み、パスワードに代えて、あるいはパスワードと併せて、パスキーでログインできるようにしています。利用者の多くは、自らのサービスを提供する事業者や、社内の業務システムを運用する企業です。

認証の仕組みを外部のサービスに任せる場合、利用者は認証の場面で何が起きているかを自らのシステムでも把握したいと考えます。同社は、ログインやパスキーの登録といった認証の出来事を、Webhook Admin を通して利用者のシステムへ署名つきで届ける仕組みを整えました。認証イベントの配信を実現するまでの取り組みをご紹介します。

認証の出来事を自らのシステムで把握したいという要望

パスキーによる認証は、パスワードの使い回しや漏えいによる不正なログインを防ぐ手段として、多くのサービスで導入が進んでいます。同社のサービスを使えば、利用者は認証の仕組みを一から作らなくても、既存のログインの画面にパスキーを加えられます。

一方で、認証は利用者のサービスにとって最も重要な入口です。誰がいつログインしたのか、ログインに失敗した記録はないか、新しいパスキーが登録されたのはいつか、といった情報は、監査や不正の検知に欠かせません。同社のサービスの管理画面でもログインの記録は確認できますが、利用者からは、こうした情報を自らのシステムでも受け取り、ほかの記録と合わせて扱いたいという要望が寄せられていました。

たとえば、ある利用者は、ログインの失敗が続いた場合に自らの監視の仕組みで検知したいと考えていました。別の利用者は、パスキーが取り消されたときに、自らのサービス側でも関連する設定を見直したいと考えていました。利用者が削除されたときに、自らのデータベースの情報を整理したいという要望もありました。いずれも、認証の出来事が起きたときに、その知らせを利用者のシステムへ届ける仕組みが必要でした。

安全性に関わるイベントに求められる条件

認証のイベントは、ほかの種類の通知とは異なる重みを持っています。ログインの成功や失敗、パスキーの登録や取り消しは、いずれもサービスの安全性に直接関わる出来事です。もし第三者が偽のイベントを送り込み、利用者のシステムがそれを本物として扱えば、誤った判断につながりかねません。

そのため、イベントを受け取る側が、それが本当に同社のサービスから送られたものであり、途中で書き換えられていないことを確かめられる必要があります。そのための一般的な方法が、イベントに署名を付け、受け取る側で検証する仕組みです。署名の方式を決め、鍵を管理し、受け取る側が検証の処理を組めるよう説明を整えることは、認証のサービスとして欠かせない取り組みでした。

あわせて、イベントが確実に届くことも求められます。利用者のシステムが一時的に応答しない場合でも、認証の出来事が失われてしまえば、監査の記録に欠けが生じます。届かなかったイベントを送り直す仕組みと、配信の結果を記録として残す仕組みが必要でした。

署名と再送を独自に開発する負担

同社は当初、こうした配信の仕組みを社内で独自に開発することも検討しました。しかし、検討を進めるにつれて、必要な作り込みの多さが明らかになりました。

署名の仕組みでは、署名の方式の選定、署名に使う鍵の発行と管理、受け取る側が古いイベントを繰り返し送り込まれることへの備えなど、考えるべき点が多くあります。再送の仕組みでは、送り直す間隔や回数の決め方、利用者のシステムが長く応答しない場合の扱いを決めなければなりません。配信の記録を残し、利用者からの問い合わせに応じて確かめられるようにする必要もあります。

これらはいずれも、パスキーによる認証という同社のサービスの中心とは別の領域です。作った後も、配信の状況を見守り、不具合に対応し、仕様の変化に合わせて手を入れ続けなければなりません。認証のサービスとして安全性と信頼性を高める開発に力を注ぎたい同社にとって、配信の仕組みを自ら抱え込むことは大きな負担になると判断しました。

利用者に定期的に記録を取りに来てもらう方法も考えられましたが、この方法では、利用者が出来事に気づくまでに時間がかかります。不正の検知のように早く知らせることに意味がある用途には向きません。出来事が起きたときに利用者のシステムへ知らせを届ける形が、利用者の要望に最もよく応えると考えました。

署名・再送・記録をそのまま使える配信の基盤

そこで同社が選んだのが、Webhook Admin です。Webhook Admin は、公開された仕様である Standard Webhooks に沿った署名を付けてイベントを配信し、届かなかったイベントを送り直し、配信の結果を記録として残します。イベントの種類の登録や、送信先ごとの管理も備えています。

公開された仕様に沿った署名であることは、同社にとって重要な点でした。受け取る側の利用者は、仕様に沿って検証の処理を組めます。署名の方式を独自に定めて利用者に説明する必要がなく、利用者にとっても、検証の手順を理解しやすくなります。

同社は、署名・再送・配信の記録を備えた配信の仕組みをそのまま利用できることを評価し、Webhook Admin の採用を決めました。配信の基盤を任せることで、同社は認証のイベントとして何を、どのような内容で送るかという設計に集中できます。

イベントの種類の設計と、アプリごとの送信先

導入の最初の作業は、配信するイベントの種類を決めることでした。同社は、利用者からの要望を踏まえ、ログインの成功、ログインの失敗、パスキーの登録、パスキーの取り消し、利用者の削除を、それぞれイベントの種類として Webhook Admin に登録しました。出来事ごとに種類を分けておくことで、受け取る側は種類を見ただけで、どのような処理をすべきかを判断できます。

イベントに含める内容も、種類ごとに整理しました。認証のイベントには、どの利用者に関する出来事か、いつ起きたかといった情報が含まれます。受け取る側が処理に必要な情報をそろえつつ、認証に関わる秘密の情報が含まれることのないよう、項目を一つずつ確かめながら決めています。

送信先は、利用者が同社のサービスの管理画面で、アプリの設定として URL を入力する形にしました。同社のサービスでは、利用者が自らのサービスごとにアプリを作成します。アプリごとに送信先を登録できるため、複数のサービスを運営する利用者でも、それぞれのサービスの出来事をそれぞれのシステムで受け取れます。登録された URL は Webhook Admin 上でアプリごとの送信先として管理され、認証の出来事が起きると、同社のサービスから送られたイベントを Webhook Admin が届けます。

検証の手順の案内と、段階を踏んだ公開

認証のイベントを受け取るには、利用者の側でイベントを受け取る処理と、署名を検証する処理を用意する必要があります。同社は、利用者向けの説明の中で、イベントの種類ごとの内容と、署名を検証してから処理する手順を示しました。検証に失敗したイベントは処理しないことを、受け取る側の基本の扱いとして案内しています。

利用者が送信先を登録した後は、配信の記録を確かめることで、イベントが届いているかどうかを判断できます。利用者のシステムが一時的に応答しなかった場合も、Webhook Admin が送り直すため、出来事が失われることを防げます。送り直しても届かない状態が続けば、その結果が記録に残り、同社のサポートの担当者は記録をもとに利用者の設定の確認を依頼できます。

同社は、認証のイベントの配信を一度にすべての利用者へ広げるのではなく、段階を踏んで公開しました。まず社内で運用している自らのアプリに送信先を登録し、ログインやパスキーの登録といった操作を実際に行いながら、イベントが期待どおりの内容で届くことを確かめました。署名の検証の手順も、利用者向けの説明に沿って社内で組んでみることで、説明に抜けや分かりにくい点がないかを点検しています。

確認の過程では、テスト送信も活用しました。テスト送信を使えば、実際の認証の出来事を起こさなくても、送信先にイベントを届けて受け取りの動作を確かめられます。利用者にも、送信先の URL を登録した後にテスト送信で受け取りと署名の検証を確認してから、本来の処理に組み込む流れを案内しています。

社内での確認を終えた後、要望を寄せていた利用者から順に配信を案内しました。利用者が受け取りの処理を用意するまでの間は、これまでどおり管理画面でログインの記録を確かめられるため、配信の開始を急ぐ必要はありません。利用者は、自らの準備が整った時点で送信先を登録し、配信を受け始められます。

開発を認証の機能に集中できる体制へ

Webhook Admin の導入により、認証のイベントは署名つきで利用者のシステムへ届くようになりました。利用者は受け取ったイベントの署名を検証したうえで処理できるため、監査の記録や不正の検知の仕組みに、安心して取り込めます。届かなかった場合は送り直されるため、記録の欠けも起こりにくくなりました。

利用者の側では、認証の出来事をきっかけに自らのシステムで処理を進められるようになりました。ログインの失敗が続けば自らの監視の仕組みで気づき、パスキーが取り消されれば関連する設定を見直し、利用者が削除されれば自らのデータベースの情報を整理する、といった対応を、管理画面を確かめに行かなくても進められます。

同社にとっては、配信の仕組みを独自に持つ必要がなくなりました。署名の鍵の管理や再送の規則、配信の記録といった機能を Webhook Admin に任せたことで、開発の担当者はパスキーによる認証の使いやすさや安全性を高める取り組みに時間を使えるようになっています。

配信の記録が残ることは、同社のサポートにとっても意味があります。利用者からイベントが届かないという相談を受けたときに、いつ、どの送信先へ、どのような結果で配信されたかを記録から確かめられるため、受け取る側の処理の問題なのか、送信先の設定の問題なのかを利用者とともに切り分けられます。

今後も同社は、利用者のニーズに合わせて配信するイベントの種類を充実させていく予定です。認証の場面で起きる出来事を、署名と再送に支えられた確実な形で届けることで、利用者が自らのサービスの安全性を高められるよう支えていきます。