パスキーを使用したユーザー登録の仕組み

新しいユーザーを登録する際は、最終的に認証するための認証情報を作成する必要があります。認証情報の登録はWebAuthnセレモニー（手続き）であり、ユーザー（あなた）がクライアント（ユーザーのWebブラウザ）とやりとりして、認証器（セキュリティキー、Googleパスワードマネージャー、iCloudキーチェーンなど）に認証情報（ユーザーのパスキー）を作成します。

この新しい認証情報は、特定のRelying Party（Webアプリケーション）に利用範囲が限定されているため、ユーザーはそのWebアプリケーションのドメインでのみ認証情報を使用できます。また、Relying Partyは、認証情報をユーザーのアカウントに関連付けます。

まず、一意でランダムなユーザー名と表示名を選択して、ユーザーのRelying Partyアカウントを作成します。このアカウントは、後に認証情報に関連付けます。

認証器には、Relying Partyのセキュリティ要件を満たすための新しい認証情報の属性を指定するパラメータ（認証オプション）が必要です。

登録オプションには、チャレンジとアカウントの一意のユーザーIDを含める必要があります。チャレンジは、リプレイ攻撃を回避するために、サーバー側などの信頼できる環境でRelying Partyによってランダムに生成される必要があります。

さらに、登録オプションでは、ユーザー名や表示名などのユーザーアカウント属性を指定する必要があります。

このデモでは、前に選択したユーザーデータをRelying Partyサーバーに送信し、必要な登録オプションを含むオブジェクトを取得します。

Relying Partyは、登録オプションをパラメータとして使用して、クライアントのWebAuthn APIからnavigator.credentials.create()メソッドを呼び出します。

次に、クライアントは使用可能な認証器に接続し、登録オプションを渡します。認証器は、登録オプションで定義された基準を満たすことができる場合にのみ、認証情報を作成できます。

さらに、ユーザーは認証情報を作成して登録セレモニーを続行することに同意する必要があります。そのため、認証器はユーザーがボットではなく、存在していることを確認するため、認証器との物理的なやりとり（タップや生体認証の入力など）となる認可ジェスチャを提供するようにユーザーに求めるUIを表示します。

画面に表示されるプロンプトに従って、認証器を操作します。

Relying Partyであるクライアントアプリケーションは、認証情報の公開鍵、認証情報ID、署名されたチャレンジ、および認証器の来歴や特性に関するアテステーションなどの追加情報を含むアテステーション レスポンスをRelying Partyサーバーに送信する必要があります。

Relying Partyサーバーは、アテステーション レスポンスを検証するため、署名されたチャレンジをチェックし、正当なデバイスが認証情報を作成したことを確認する必要があります。

アテステーションを検証したRelying Partyサーバーは、認証情報の公開鍵、認証情報ID、その他のアテステーション レスポンスのデータをデータベースに格納します。サーバーはデータをuser.idやuser.nameなどのユーザーアカウント属性にリンクし、これによってユーザーがパスキーを使用してアカウントにサインインできるようになります。

認証器は、認証情報の秘密鍵にアクセスできる唯一の要素です。認証情報の秘密鍵は、今後、Relying Partyで認証してアカウントにアクセスするために必要です。

パスキーを使用してこのユーザー登録デモを完了すると、認証情報の公開鍵がPEM形式で表示されます。