パスキーの導入と実装の手順｜事業者が決めること・既存会員への展開・注意点

パスワードは残したまま、パスキーを追加するところから始める

パスキーは、端末の生体認証やPINでログインできる認証方式です。フィッシングに強く、パスワードの再設定も要らなくなります。仕組みはパスキーとはで解説しています。

ただ、利用者全員が一度に切り替えるわけではありません。導入は次の順序で進めるとよいでしょう。

1. 既存のログイン方法はそのままにして、パスキーも選べるようにする
2. ログインの直後などに、パスキーの登録を案内する
3. 利用率を見ながら、パスキーを主なログイン方法にしていく

パスワードをなくすかどうかは、端末をなくした利用者の復旧手段を用意してから判断してください。

パスキーで解決すること、残る課題

見落とされやすいのは復旧手段です。パスキーを導入しても、メールだけで簡単にログイン方法を変えられるなら、攻撃者はそちらを狙います。

導入前に決める5つのこと

1. 新規会員だけに使ってもらうか、既存会員にも広げるか

新規登録でパスキーを作ってもらうだけなら、登録画面の変更で始められます。既存会員にも使ってもらうなら、ログイン中にパスキーを登録できる画面（マイページなど）が必要です。

2. 登録を案内するタイミング

案内に向いているのは、ログインに成功した直後や、購入・応募が完了した直後など、利用者が目的を果たした場面です。会員登録フォームの途中で求めると、離脱の原因になります。

3. ログイン画面での見せ方

ログイン画面には、ボタンを置く方法と、入力欄の候補に出す方法があります。

• 「パスキーでログイン」のボタンを置く
• IDの入力欄で、ブラウザにパスキーを候補として表示させる（自動入力）

自動入力なら、利用者はパスキーを意識せずに使えます。ボタンと併用することもできます。

4. 端末を変えた・なくした場合の復旧

AppleのiCloudキーチェーンやGoogleパスワードマネージャーに保存されたパスキーは、同じアカウントでログインした端末どうしで同期されます。手元にない端末のパスキーを、QRコードを読み取って使う方法もあります。

それでも、パスキーを使えなくなる利用者は必ず出てきます。本人確認をしたうえでパスキーを登録し直せる手順を、あらかじめ用意しておきましょう。

5. パスワードを残す期間

パスワードをいつまで残すかは、パスキーの登録率と、ログインに占めるパスキーの割合を見て決めるとよいでしょう。最初から期限を切っておく必要はありません。

既存会員に広げる順序

自社で実装するか、サービスを使うか

パスキーは、WebAuthnというブラウザの標準の仕組みで実装します。自社で実装する場合は、おおよそ次の作業が発生します。

• 登録では、サーバーでチャレンジ（使い捨ての値）を発行し、端末で作られた公開鍵を検証して保存する
• 認証では、端末から送られた署名を、保存した公開鍵で検証する
• 1人の会員に端末ごとの複数のパスキーを紐づけ、利用者が自分で削除できるようにする
• パスキーを使えない環境を判定し、別のログイン方法へ案内する

検証の処理を規格どおりに一から書くのは難しいため、自社で実装する場合も実績のあるライブラリを使うのが一般的です。

サービスを使う場合は、登録・認証の画面と検証をサービス側に任せられるので、自社で実装するのはパスキーと自社の会員IDの紐づけが中心になります。

パスキーを実装する手順

ここでは、実装の中身を登録とログインに分けて見ていきます。自社で実装する場合と Login Plus を使う場合とでは、サイト側で作る範囲が変わります。

自社で実装する場合の登録の流れ

1. ログイン中の利用者が登録を始めると、サーバーはチャレンジを発行し、サイトのドメインにあたるRP IDや会員を識別する値と一緒にブラウザへ返します。
2. ブラウザは navigator.credentials.create() を呼び出します。端末は生体認証やPINで本人を確かめてから鍵のペアを作り、秘密鍵は端末（またはパスキーを同期するサービス）に残したまま、公開鍵をサーバーへ送ります。
3. サーバーは、チャレンジやオリジンが発行したものと一致するかを検証したうえで、公開鍵とクレデンシャルIDを会員に紐づけて保存します。

自社で実装する場合のログインの流れ

1. サーバーがチャレンジを発行して、ブラウザへ返します。
2. ブラウザが navigator.credentials.get() を呼び出し、利用者が生体認証やPINで端末のロックを解除すると、端末が秘密鍵でチャレンジに署名します。
3. サーバーは、クレデンシャルIDから保存済みの公開鍵を探して署名を検証し、問題がなければログイン状態にします。

前の節で触れた自動入力を使う場合は、IDの入力欄に autocomplete="username webauthn" を指定し、ログイン画面を開いた時点で mediation: "conditional" を付けて navigator.credentials.get() を呼び出しておきます。こうすると、入力欄の候補にパスキーが表示されます。

Login Plus を使う場合の流れ

Login Plus を使う場合、パスキーの登録画面とログイン画面は Login Plus が用意します。サイト側で作るのは、利用者を Login Plus の画面へ送る処理と、戻ってきた利用者を自社の会員と照らし合わせる処理です。

1. サイトのログイン画面やマイページから、戻り先のURL（redirect_uri）を付けて、Login Plus の登録画面またはログイン画面へ利用者を送ります。
2. 利用者は Login Plus の画面で、パスキーを登録するか、パスキーでログインします。
3. 終わると redirect_uri に指定したサイトのURLへ戻り、認可コードが渡されます。サイトのサーバーは、この認可コードを使って利用者の情報を受け取ります。
4. 受け取った情報を自社の会員IDと照らし合わせ、ログイン状態にします。

ソーシャルログインで作った会員に、後からパスキーを結びつけることもできます。サイト側の会員を site_user_id で指定するので、たとえばソーシャルログインで登録した会員がマイページからパスキーを追加する、といった使い方ができます。

つまずきやすい点

ソーシャルログインとの併用

パスキーとソーシャルログインは、解決する問題が違います。ソーシャルログインはアカウントを作る手間を省き、パスキーはパスワードを置き換えます。

新規登録ではソーシャルログインで入力を省き、自社のアカウントを持つ会員にはパスキーを案内する、という組み合わせにすると、取りこぼしが少なくなります。ログイン画面に両方を並べる場合は、前回使ったログイン方法を表示しておくと、利用者が迷わずに済みます。

ソーシャルログインの導入手順はソーシャルログインの導入手順と期間で解説しています。

よくある質問

パスキーを導入すると、パスワードは不要になりますか？

パスキーを登録した利用者は、ログインにパスワードを使わなくなります。ただ、全員がすぐに登録するわけではないため、当面はパスワードとの併用が現実的です。

パスキーに対応していない端末の利用者はどうなりますか？

主要なOSとブラウザはパスキーに対応していますが、古い端末では使えない場合があります。既存のログイン方法は残し、使える利用者から順に切り替えていくのが一般的です。

パスキーとソーシャルログインは、どちらから導入すべきですか？

新規登録の離脱を減らしたいならソーシャルログイン、既存会員のパスワード管理や不正ログインが課題ならパスキーが先です。判断の考え方はパスキーとソーシャルログインの違いの記事にまとめています。

パスキーの実装では、サーバー側で何を作る必要がありますか？

自社で実装する場合は、チャレンジの発行、登録時の公開鍵の検証と保存、ログイン時の署名の検証が必要です。Login Plus を使う場合は、画面と検証を Login Plus に任せ、認可コードで受け取った利用者の情報を自社の会員IDと照らし合わせる処理を作ります。

ソーシャルログインで登録した会員にも、パスキーを追加できますか？

Login Plus では、ソーシャルログインで作った会員に、後からパスキーを結びつけられます。会員は site_user_id で指定します。

Login Plus について

Login Plusは、パスキーと6つのソーシャルログインに1つの実装で対応できるサービスです。

• FIDO2 / WebAuthn に準拠したパスキー認証
• パスキーの登録画面とログイン画面をLogin Plusが提供
• 登録されたパスキーを、自社の会員IDに紐づけるAPIを用意
• Apple・Facebook・Google・X（旧Twitter）・Yahoo! JAPAN・LINEのソーシャルログインと併用できる

既存の会員サイトにパスキーを追加できるかのご相談は、資料請求またはお問い合わせからどうぞ。