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

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

パスキー システムの構造

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

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

登録フロー

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

新しいパスキーの作成に必要な主なコンポーネントは次のとおりです。

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

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

登録フロー

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

認証フロー

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

パスキーによる認証を行うには、次の重要な要素があります。

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

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

認証フロー

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

サーバーサイドの統合

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

ただし、自分でパスキー サーバーを構築すると、時間効率が悪く、重大なセキュリティ インシデントにつながる可能性があるバグが発生する可能性があります。利用可能なオープンソース ライブラリのいずれか、またはパスキーの統合の高速化に役立つソリューションを使用することをおすすめします。

オープンソース ライブラリの一覧については、passkeys.dev のライブラリ セクションまたは WebAuthn ライブラリのクラウドソース リストをご覧ください。解決策を見つけるために、FIDO Alliance は認定 FIDO2 サーバーの名簿を用意しています。

既存(レガシー)の認証メカニズム

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

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

  • パスキーに互換性のないユーザーがいる場合: パスキーのサポートは、複数のオペレーティング システムとブラウザに幅広く拡大されていますが、古いバージョンを使用しているユーザーは、まだパスキーを使用できません。
  • パスキーのエコシステムがまだ成熟していない: パスキーのエコシステムは進化しています。異なる環境間での UX の詳細や技術的な互換性が向上します。
  • まだパスキーを使用できないユーザー: 新しいことに挑戦することをためらっているユーザーも存在します。パスキーのエコシステムが成熟するにつれ、ユーザーはパスキーの仕組みとそれが自分にとって有用である理由を理解できるようになります。

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

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

パスワード

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

2 要素認証

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

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

ID 連携

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

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

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

学習用リソース

ウェブ

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

Android

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

UX

パスキーのユーザー エクスペリエンスに関する推奨事項: