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

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

パスキー システムの構造

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

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

登録フロー

ウェブサイトで WebAuthn API を使用するか、Android アプリの認証情報マネージャー ライブラリを使用して、新しいパスキーを作成して登録します。

新しいパスキーを作成するには、次の重要な要素があります。

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

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

登録フロー

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

認証フロー

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

パスキーによる認証を行うには、次の 2 つの主要コンポーネントが必要です。

  • RP ID: 証明書利用者の ID をウェブドメインの形式で指定します。
  • チャレンジ: リプレイ攻撃を防ぐ、サーバーで生成されたチャレンジ。

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

認証フロー

パスキーによる認証の方法について詳しくは、以下をご覧ください。

サーバーサイドの統合

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

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

既存（レガシー）の認証メカニズム

既存のサービスでパスキーをサポートしている場合、パスワードなどの古い認証メカニズムからパスキーへの移行は 1 日では行われません。脆弱な認証方法をできる限り早く廃止することを希望されるかもしれませんが、それによってユーザーが混乱したり、一部のユーザーが残されたりする可能性があります。当面は既存の認証方法をそのまま使用することをおすすめします。

いくつかの理由があります。

  • パスキーに互換性のない環境にユーザーがいる場合: パスキーのサポートは、複数のオペレーティング システムとブラウザに幅広く拡張されていますが、古いバージョンを使用しているユーザーは、まだパスキーを使用できません。
  • パスキーのエコシステムはまだ成熟していない: パスキーのエコシステムは進化しています。異なる環境間での UX の詳細と技術的な互換性が向上します。
  • ユーザーはまだパスキーを使用する準備ができていない可能性があります: 新しいことに飛びつきにくいと感じるユーザーがいます。パスキーのエコシステムが成熟するにつれて、パスキーの仕組みと、パスキーが役立つ理由を理解できるようになります。

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

パスキーは認証を簡単かつ安全にしますが、以前のメカニズムを維持することは穴をあけるようなものです。既存の認証メカニズムを見直して改善することをおすすめします。

パスワード

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

2 要素認証

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

OTP の配信方法として SMS を選択する場合は、次のベスト プラクティスを確認して、OTP を入力する際のユーザー エクスペリエンスを効率化します。

ID 連携

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

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

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

学習用リソース

ウェブ

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

Android

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

UX

パスキーのユーザー エクスペリエンスに関する推奨事項をご確認ください。