証明書利用者向けパスキー デベロッパー ガイド

パスキーをサービスに統合する方法について説明します。

パスキー システムの構造

パスキー システムは、いくつかのコンポーネントで構成されています。

  • リライング パーティ: パスキーのコンテキストでは、リライング パーティ（RP）がパスキーの発行と認証を処理します。RP は、クライアント（パスキーを作成するか、パスキーで認証するウェブサイトまたはアプリ）と、クライアントのパスキーで生成された認証情報を登録、保存、検証するサーバーを運用する必要があります。パスキー モバイル アプリケーションは、デジタル アセット リンクなどの OS 提供の関連付けメカニズムを使用して、RP サーバー ドメインにバインドする必要があります。
  • Authenticator: オペレーティング システムが提供する画面ロック機能を使用してパスキーを作成し、検証できるコンピューティング デバイス（スマートフォン、タブレット、ノートパソコン、デスクトップ パソコンなど）。
  • パスワード マネージャー: エンドユーザーのデバイスにインストールされ、パスキーの提供、保存、同期を行うソフトウェア（Google パスワード マネージャーなど）。

登録フロー

ウェブサイトで WebAuthn API を使用するか、Android アプリで Credential Manager ライブラリを使用して、新しいパスキーを作成して登録します。

新しいパスキーを作成するには、次の重要なコンポーネントを指定する必要があります。

  • RP ID: リライング パーティの ID をウェブ ドメインの形式で指定します。
  • User information: ユーザーの ID、ユーザー名、表示名。
  • 除外する認証情報: 重複登録を防ぐために、以前に保存されたパスキーに関する情報。
  • パスキーの種類: 認証システムとしてデバイス自体（「プラットフォーム認証システム」）を使用するか、取り外し可能なセキュリティ キー（「クロスプラットフォーム / ローミング認証システム」）を使用するか。また、呼び出し元は、ユーザーがログインに使用するアカウントを選択できるように、認証情報を検出可能にするかどうかを指定できます。

RP がパスキーの作成をリクエストし、ユーザーが画面ロックで確認すると、新しいパスキーが作成され、公開鍵認証情報が返されます。これをサーバーに送信し、今後の認証のために認証情報 ID と公開鍵を保存します。

登録フロー

パスキーを作成して登録する方法について詳しくは、以下をご覧ください。

認証フロー

ウェブサイトで WebAuthn API を使用するか、Android アプリで Credential Manager ライブラリを使用して、登録済みのパスキーで認証します。

パスキーで認証するには、次の 2 つの重要なコンポーネントを指定する必要があります。

  • RP ID: リライング パーティの ID をウェブ ドメインの形式で指定します。
  • チャレンジ: リプレイ攻撃を防ぐためにサーバーで生成されるチャレンジ。

RP がパスキーによる認証をリクエストし、ユーザーが画面ロックで認証すると、公開鍵認証情報が返されます。これをサーバーに送信し、保存されている公開鍵で署名を検証します。

認証フロー

パスキーで認証する方法の詳細:

サーバーサイドの統合

パスキーを作成する際、サーバーはチャレンジ、ユーザー情報、除外する認証情報 ID などの重要なパラメータを提供する必要があります。次に、クライアントから送信された作成済みの公開鍵認証情報を検証し、公開鍵をデータベースに保存します。パスキーで認証するには、サーバーが認証情報を慎重に検証し、署名を確認して、ユーザーがログインできるようにする必要があります。

詳しくは、サーバーサイド ガイドをご覧ください。

既存の（従来の）認証メカニズム

既存のサービスでパスキーをサポートする場合、パスワードなどの古い認証メカニズムからパスキーへの移行は 1 日では完了しません。弱い認証方法をできるだけ早く排除したいとお考えでしょうが、ユーザーの混乱を招いたり、一部のユーザーが取り残されたりする可能性があります。当面は既存の認証方法を維持することをおすすめします。

これには次のような理由があります。

  • パスキーに対応していない環境のユーザーがいる: パスキーのサポートは複数のオペレーティング システムとブラウザに広く拡大していますが、古いバージョンを使用しているユーザーはまだパスキーを使用できません。
  • パスキー エコシステムはまだ成熟していない: パスキー エコシステムは進化しています。さまざまな環境間の UX の詳細と技術的な互換性を改善できます。
  • パスキーの利用にまだ抵抗があるユーザーがいる: 新しいものに飛びつくことに抵抗があるユーザーもいます。パスキー エコシステムが成熟するにつれて、パスキーの仕組みと、パスキーがユーザーにとって有用な理由を理解できるようになります。

既存の認証メカニズムを再検討する

パスキーによって認証がよりシンプルかつ安全になりますが、古いメカニズムを残しておくことは、穴を残しておくようなものです。既存の認証メカニズムを見直して改善することをおすすめします。

パスワード

ユーザーにとって、安全なパスワードを作成してウェブサイトごとに管理することは難しい作業です。システムに組み込まれているパスワード マネージャーまたはスタンドアロンのパスワード マネージャーを使用することを強くおすすめします。ログイン フォームに少し手を加えるだけで、ウェブサイトやアプリのセキュリティとログイン エクスペリエンスを大幅に改善できます。変更方法については、以下をご覧ください。

2 要素認証

パスワード マネージャーはパスワードの管理に役立ちますが、すべてのユーザーが使用しているわけではありません。このようなユーザーを保護するために、ワンタイム パスワード（OTP）と呼ばれる追加の認証情報を求めるのが一般的です。通常、OTP はメール、SMS メッセージ、または Google 認証システムなどの認証システム アプリを通じて提供されます。通常、OTP は限られた期間のみ有効な短いテキストが動的に生成されるため、アカウントの不正使用の可能性が低くなります。これらの方法はパスキーほど堅牢ではありませんが、ユーザーにパスワードだけを残すよりもはるかに優れています。

OTP の配信方法として SMS を選択する場合は、以下のベスト プラクティスを確認して、OTP の入力に関するユーザー エクスペリエンスを効率化してください。

ID 連携

ID 連携は、ユーザーが安全かつ簡単にログインできるようにするもう 1 つの方法です。ID 連携を使用すると、ウェブサイトやアプリで、サードパーティの ID プロバイダのユーザー ID を使用してユーザーがログインできるようになります。たとえば、Google でログインはデベロッパーにとってコンバージョン率が高く、ユーザーにとってはパスワード ベースの認証よりも簡単で好ましいものです。ID 連携はパスキーを補完するものです。ウェブサイトやアプリは 1 回の手続きでユーザーの基本的なプロフィール情報を取得できるため、登録に最適です。また、パスキーは再認証の効率化に最適です。

2024 年に Chrome でサードパーティ Cookie が段階的に廃止されると、ID 連携システムによっては、その構築方法に応じて影響を受ける可能性があります。この影響を軽減するため、Federated Credential Management API（FedCM）という新しいブラウザ API が開発されています。ID プロバイダを運営している場合は、詳細を確認して、FedCM の導入が必要かどうかをご確認ください。

マジック リンク ログインは、サービスがメールでログインリンクを送信し、ユーザーがそのリンクをクリックして認証を行う認証方法です。これにより、ユーザーはパスワードを覚えていなくてもログインできますが、ブラウザ/アプリとメール クライアントを切り替える際に手間がかかります。また、認証メカニズムはメールに依存しているため、メール プロバイダのセキュリティが弱いと、ユーザーのアカウントが危険にさらされる可能性があります。

学習用リソース

ウェブ

パスキーをウェブサイトに統合するには、Web Authentication API（WebAuthn）を使用します。詳細については、以下のリソースをご覧ください。

Android

パスキーを Android アプリに統合するには、認証情報マネージャー ライブラリを使用します。詳細については、次のリソースをご覧ください。

UX

パスキーのユーザー エクスペリエンスに関する推奨事項を確認します。