いろんなウェブサービスにパスキーでログインしてみる
2023/12/12 記事公開
2023/12/14 調査サービスの差し替え & コメント返信
はじめまして。kinmemodokiです。
この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2023の12日目の記事です。
2023年では様々なウェブサービスがパスキーに対応し様々なログインUXが生まれました。
本記事はそのさまざまなウェブサービスのパスキーによるログインUXの挙動をまとめ、挙動の考察を行いました。
本記事で扱うのは「ウェブサービスのパスキーでのログインUX」についてであり、「パスキー周りの実装や技術」については基本的に扱いません。
なお、本記事では「WEB+DB PRESS Vol.136「特集2 実戦投入パスキー ─いまこそ実現、パスワードレス認証！」」の「第２章 パスキー時代の認証UX」を参考にしており、最低限の部分は引用しておりますが、こちらも併せて読んでいただくとさらに理解が深まると思います。
この書籍ではパスキーのUXに関して包括的にとても良くまとまっているだけでなく、パスキーの登場経緯や実装知識も含まれています。パスキーに興味がある方にはぜひ読んでいただきたいです。（ちなみに自分は著者ではないです）
3つの認証方法
実際のウェブサービスの調査の前におおまかな認証UXについて紹介する必要があるので軽く触れます。「WEB+DB PRESS Vol.136「特集2 実戦投入パスキー」」ではパスキーの認証のUXは以下の３つに分類して紹介しています。
- ワンボタンログイン
- フォームオートフィルログイン
- ユーザ名指定ログイン
ワンボタンログイン
ログイン画面に「パスキーでログイン」のようなボタンを設置されてあり、それを押下するとパスキーでの認証が開始する方式。例えば ニンテンドーアカウント のログイン画面など。
フォームオートフィルログイン
入力フォームにフォーカスをした際にパスワードオートフィルと同じように利用可能なパスキー一覧が表示され、それを押下するとパスキーでの認証が開始する方式。このパスキー一覧はConditional UIと呼ばれたりします。例えば マネーフォワード ID のログイン画面など。
ユーザ名指定ログイン
入力フォームにIDを入力後、次の画面でパスキーでの認証が開始する方式。例えば Google アカウント のログイン画面など。
ウェブサービスのパスキーでのログインを触る
ここから実際のウェブサービスのパスキーでの認証UXについて調査した内容を紹介していきます。
今回調査したのは以下です。
- ニンテンドーアカウント
- マネーフォワード ID
- GitHub アカウント
- Yahoo! JAPAN ID
ニンテンドーアカウント
前章で例に出した通りニンテンドーアカウントのログインは「ワンボタンログイン」でした。
また、メールアドレス + パスワードでのログインを行い、そのアカウントで二段階認証が有効になっていた場合、二段階認証としてパスキーでのログインが可能でした。
二段階認証としてパスキーでのログイン
フローチャートにすると以下の感じです。
二段階認証としてパスキーを利用する場合、ログインするアカウントは決まっているため「ユーザ名指定ログイン」のUXにあてはまります。（厳密にはIDとパスワードでログイン済みのため、「ユーザ名指定ログイン」のUXかと言われるとすこし微妙ですが）
まとめ
- 「ワンボタンログイン」でログインができる
- 二段階認証としてパスキーを利用することも可能
マネーフォワード ID
こちらも前章で例として出しましたが、マネーフォワード IDは「フォームオートフィルログイン」に対応しています。
ログイン画面は「メールアドレス入力画面」、「パスワード入力画面」に分かれており、このどちらのフォームでもパスキーのオートフィルログインが発動します。
マネーフォワード IDのパスキーでのログイン
なお、アカウントの二段階認証が有効の場合、メールアドレス + パスワードで認証を行ったあとはSMSによる確認コードが要求されますが、こちらのフォームではフォームオートフィルログインは発動しませんでした。
フローチャートに表すと以下の感じです。
パスワードを入力画面ではすでに入力されたIDが利用できるパスキーのみが表示されるため「ユーザ名指定ログイン」のUXと言えるでしょうか。
マネーフォワード IDのフォームオートフィルログインについては中の人から開発の試行錯誤や実装内容について紹介されています。参考になるのでオススメです。
まとめ
- 「フォームオートフィルログイン」でログインできる
- 「パスワード入力画面」では入力済みのIDで利用できるパスキーのみが選択肢として表示される
GitHub アカウント
GitHubには「ワンボタンログイン」に対応しています。このパスキーでログインを行うボタンのUIは目立つボタンと目立たないボタンの2種類ありました。（自分が把握している限り）
この出し分けはおそらく 「パスキー登録済みのアカウントにログインしたことがあるブラウザかどうか」 で判定されていそうです。パスキー登録済みアカウントにログインしたことがあるブラウザであれば目立つボタンが表示されるのだと思います。
目立たないパスキーでのログインボタン（左）と目立つパスキーログインボタン（右）
また、「フォームオートフィルログイン」にも対応をしています。こちらも 「パスキー登録済みのアカウントにログインしたことがあるブラウザ」でのみConditional UIが表示されているように思われました。
Condtional UI未発動（左）とCondtional UI発動（右）
さらにパスキーでログインをせずにID+パスワードを入力後に発動する二段階認証ではパスキーを利用することが可能でした。 こちらはブラウザの状態に関わらずパスキーを登録しているアカウントであれば利用できそうです。
フローチャートに起こすと以下のような感じです。
特徴的なのはパスキー登録済みのアカウントでログインしたことのあるブラウザで挙動が変わる点ですね。これに関しては次章の考察で触れます。
まとめ
- 「ワンボタンログイン」でログインができる
- 「パスキー登録済みのアカウントでログインしたことのあるブラウザ」では「フォームオートフィルログイン」が利用できたり「ワンボタンログイン」のUIが目立つような出し分けが行われていそう（推測）
- 二段階認証としてパスキーを利用することも可能
Google アカウント
（追記）別サービスの紹介からこのGoogle アカウントの紹介に差し替えました。理由については最後の追記を参照してください。
Google アカウントは「ユーザ名指定ログイン」に対応しています。
こちらもGitHub アカウントと似ていて「過去にパスキーでそのアカウントにログインしたブラウザでは即パスキーでの認証が発動する」という挙動になっていそうです。
なお、「過去にそのアカウントにパスキーを登録したブラウザ」でもパスキーでログインしたことのあるブラウザと同じ挙動となっていました。
この出し分けの仕様上、パスキーを登録したブラウザでの再認証は即パスキーでの認証が発動します。なんらかの理由（例えば指が乾燥していて即座に指紋認証ができないとか）でパスキー認証を好まないユーザに対してはパスワードでの認証を優先、つまりパスキーでの認証をオプトアウトできる機能が提供されています。
フローチャートは以下のような感じです。
以前はパスキーでの認証が発動する前に「パスキーでログインする」みたいなボタンがあるページが挟まれていたりしたのですが、2023/10頃から見なくなりましたね。
まとめ
- 「ユーザ名指定ログイン」でログインができる
- 「指定したユーザ名に対してパスキーでログイン or パスキーを登録したことのあるブラウザ」ではユーザ名入力後にパスキーでの認証が即発動する
- それ以外では「別の方法を試す」から選択することでパスキーでの認証を発動できる
考察
なぜ複雑な発動フローが存在するのか
前半のニンテンドーアカウントやマネーフォワード IDに比べ後半のGitHub アカウントやGoogle アカウントでは複雑な判定ロジックが含まれているように感じます。（前半のサービスでも自分が見えていないだけで複雑な判定をしている可能性はありますが）
discoverable credentialではないFIDOクレデンシャルの存在
この理由の1つとして「サービス側でdiscoverable credentialではないFIDOクレデンシャルの存在」が考えられます。
discoverable credentialとは認証のための公開鍵ペアの他ユーザ識別子を含んでいるパスキーを指します。ユーザ識別子が含まれているとどうなるかというと「ワンボタンログイン」や「フォームオートフィルログイン」のようにIDを入力せずにパスキーでログインするような機能が利用できます。
2023年12月現在GitHub アカウントではdiscoverable credentialの登録が可能ですが、以前は対応していませんでした。そのためdiscoverable credentialではないnon-discoverable credentialを登録しているユーザは「ワンボタンログイン」や「フォームオートフィルログイン」を試みようとすると認証が失敗してしまいます。
このことから、確実にdiscoverable credentialを登録しているであろうユーザ（=ブラウザ）にのみ「ワンボタンログイン」の機能が目立つようにしていたり「フォームオートフィルログイン」を発動させる制御をしているのかなと思いました。
サービスとしてパスキーでのログインを強く勧めたい背景
もう１つ考えられる理由として、「サービスとしてパスキーでのログインを強く勧めたい背景」もあるかなと思います。
これはGoogle アカウントやYahoo! JAPAN IDなどの「ユーザ名指定ログイン」が当てはまると考えています。「ユーザ名指定ログイン」のUXは悪く言ってしまうと「半ば強制的にパスキーでログインさせる」挙動です。そのため多くのユーザにパスキーで認証をしてもらうことが可能です。パスキーでの認証は認証時間や認証成功率的に優秀ということがいろいろなサービスで報告されており、「ユーザ名指定ログイン」はサービスとしてユーザのドロップリスクを抑えるための手段の１つなのかなと思います。他にも多くのユーザにパスキーを利用させることでパスキーの認知向上に繋がったり、コストのかかる他の認証手段（SMSとか）の抑制も考えられます。
このように「ユーザ名指定ログイン」は強制的にパスキーの認証を発動させるため、Googleのようにパスキーの認証の発動をユーザ側で抑制できる機能が必要になったのかなと思いました。
また、Yahoo! JAPAN IDでは「過去にパスキーを登録した端末UA」と「現在ログインしようとしている端末UA」から「ログインしようとしている端末に利用できるパスキーが存在するかどうか」を判定してパスキーでの認証を発動する/しないのロジックがあります。(idcon vol.29の資料)
こちらも強制的にパスキーの認証を発動させることによって必要になった機能と言えそうです。
感想
本記事ではいろいろなウェブサービス（4つ）のパスキーによる認証ロジックを調査し、その背景などを考察したりしました。複雑な仕様には過去の経緯や様々なビジネス要件などがありそうですが、運用していくのであればなるべくシンプルな仕様なのほうが個人的には好ましいですね。シンプルな仕様はヘルプページでも簡潔にユーザに案内することができますし。
今回の調査や考察の結果、「最初からdiscoverable credentialのみ対応」かつ「「ワンボタンログイン」や「フォームオートフィルログイン」を採用する」のがシンプルな構成を維持していきやすいんじゃないかと思いました。対応できない環境など、例えば記憶容量の少ないセキュリティキーでは容量を使うdiscoverable credentialの作成があまり好まれなかったり(今は解消されている問題かもしれないです)、Conditional UIに対応していないOSやブラウザなど制限事項がありますが、そこはビジネス要件と相談な感じがあります。さらにアプリを持っているサービス（特にWebAuthnの機能が制限されているWebViewを利用しているとか）になってくるとまたいろいろ考えることはありそうです。
また、今回GitHub アカウントの「パスキーでログインしたことのあるブラウザでのみ挙動を変える」というのは初めて知ったのですが、この手法はなにか複雑なビジネス要件が生まれた際は裏技としてもってもよさそうです。（なるべく複雑なことはしたくないですが...）
最後に、今回はログインUXのみに焦点をあてて各サービスの工夫を見ましたが結果的に4サービスしかまとめられませんでした。他にも様々な工夫をこらしたサービスもたくさんあるため、今後ももっと調査をして複雑な要件に対応するための技やそれを回避するような思想は持っておきたいなーと思いました。
注意事項
- 本記事では2023/12/11に各サービスを操作した際の挙動をまとめたものです。今後もアップデートされることが考えられるので異なる挙動になることがあります。
- 本記事では各サービスの操作して確認できた挙動から発想した事項をまとめています。そのため、実際のロジックとは異なることがあります。
追記 & コメントをみる
- 一部サービスの紹介が「景品表示法違反」になるかもと思ったので差し替えをしました。広告ではなく感想的なコンテンツなのでたぶん問題はないはずなんですが。
=====
コメントありがとうございます！
たしかに、ユーザ知っている/しらないというメトリクスはよさそうです。
個人的にはUX観点では「いつ発動させるか」という点で以下のようなメトリクスを想像しました。
（ritouさんのおっしゃる「ユーザー識別子だけでユーザーの登録有無すら知られたくない=allowCredentialsをサーバ側から送信したくない」には対応できていないのでまだ改善余地はありそう）
この場合①と④は自動発動するのでパスキーを持たない端末では認証失敗時のBadUXが発生しがちなので複雑な判定ロジックが必要そうです。一方で認証時間は短くできそうです。
②と⑤に関しても同様ですが一応ユーザ操作が必要でユーザ意思が介入できる余地があるためBadUX感はやや薄く、複雑なロジックはなくても許容できるかなと思いました。
③と⑥はそもそもパスキーが存在しない端末では選択肢がでないので判定ロジックはなくてもよく、シンプルな実装ができそう。ただしOSによってはhybridの選択肢が表示されることがあり、ユーザが理解できずに選択してしまう可能性があります。
他にはこういうのもよく使いますね笑
allowCredentialsのtransportで何を出しているかも見たかったりするときなど
navigator.credentuals.get = function(arg) { console.log(args) }
Discussion