β公開された1Passwordのパスキー対応について調べてみた

Passkey 1Password Security Authentication WebAuthn FIDO

こんにちは、ritouです。

β公開から少し時間が経ってしまいましたが、1Passwordのパスキー対応について確認して整理しました。

www.publickey1.jp

これまでAppleのiCloud KeychainやAndroidのGoogleパスワードマネージャーなどが プロバイダとしてのパスキーのサポートをしてきた中で、1Passwordが同様の対応をすることでクロスプラットフォームなパスキー利用環境が整うのか？と注目が集まっています。

個人的に1Passwordを活用しているので、使い勝手を見てみました。

環境は Chrome バージョン: 114.0.5735.133 @ macOS です。 1Passwordのβ版の拡張機能を有効にすることで動作確認ができます。 Relying Partyにはwebauthn.ioを利用します。

webauthn.io

パスキーの生成/登録

Webサービスでは、アカウントの新規作成の際や設定変更などでパスキーの生成、登録を行います。特に新規作成時はなるべくシームレスに完了できることが重要な処理ですね。

何も考えずに生成/登録を行おうとすると、このようなプロンプトが表示されます。

1Passwordのアンロックを忘れていたので生成ができませんでした。アンロックして1Passwordが利用可能な状態にして再度試してみます。

こんな感じでパスキーを生成して保存しますよとなります。

これで、1Passwordにwebauthn.ioで利用するパスキーを生成できました。生成したパスキーはパスワードと同様に確認できます。

実にスムーズにパスキーの生成/登録ができました。むしろ、スムーズすぎる気がします。

これまで1Password以外のパスキー生成のフローにあったTouchIDやFaceIDとか指紋認証、PINなどのローカル認証が求められませんでした。技術的には、UserVerificationを要求しているのにすっと生成できてしまったんだが？ というところです。

後から直接1PasswordのTwitterアカウントに聞いてみたら教えてくれたんですが、1Passwordが利用可能な状態=1Password自体がパスワードなどでアンロックされた状態であるので、UserVerificationが済んでいる扱いなのだ ということらしいです。 その観点で言えば、なるほど...となりますが、これまでのFIDO仕草をこれだけあっさり変えてもいいものなのか...と思ってしまいます。

もう一つ、これは仕様かバグか表現に迷う部分ですが、ある1Passwordアカウントに対して保存できるパスキーは1つだけとなっている気がします。別にそれ困らないのでは？という感じですが、例えばサービス側のuser1, user2に対してそれぞれパスキーを生成/登録しようと思っても1Password上では単一のパスキー管理が上書きされるような挙動になっていました。 その結果、user_1に対して後から生成/登録されたuser_2のためのパスキーが保存されたりします。 これはさすがによろしくない挙動だと思うのでサービス側から受け取った識別子に紐づけられた複数のパスキーを登録できるとか(追記:もしくはVaultを分けるように促せ)とった改善をしてもらいたいところです。

パスキーを用いた認証

それではさっきのパスキーを用いてログインするところを確認しましょう。

今度はこんな感じのプロンプトが出てきて、ログインできます。 生成のところと同様に、ローカル認証は求められません。理由も一緒です。

Autofill

マネーフォワード IDが本格的に導入してパスキーのログインUXのキモだとも思っているAutofillの動作も確認してみます。

生成の部分は上記と同様にできました。 さて、Autofillを用いたログインはどうでしょうか。

1PasswordのプロンプトとChromeのプロンプトで渋滞です。 ここで1Passwordのプロンプトを選んでも識別子が入力されるだけでした。Chromeのプロンプトからは1Passwordのプロンプトが立ち上がりません。よって、少なくともこの環境ではAutofill対応ができていないということでしょう。 この辺り興味がある方がいたら他の環境でも試していただければと思います。

他のパスキープロバイダとの併用

パスワードの時点でもうだいぶカオスになってる部分ですが、Chrome管理のパスキーと1Password管理のパスキー両方がある場合に、いい具合に使えるのか？というのも気になります。

生成のところでは、キャンセルするとChromeのプロンプトが出て来るので、手元の端末やhybrid transportと呼ばれる仕組みで繋いだモバイル端末にパスキーを生成できます。これはまぁまぁ良さそう。

ログインに関しては、識別子を先に入れたり入れなかったりと色々なパターンがあるのですが、

  • サービス側から1Password以外に管理されているパスキーが指定された場合 : 1Passwordは何も干渉してこないので使える
  • サービス側から1Passwordとそれ以外に管理されているパスキー両方が指定された場合 : 1Passwordのプロンプトが出てきて、しかも❌ボタンのキャンセルが効かないので実質1Passwordのパスキーしか使えない
  • サービス側からパスキーが指定されない状況において、1Password以外に管理されているパスキーしかない場合 : 1Passwordは何も干渉してこないので使える
  • サービス側からパスキーが指定されない状況において、1Passwordとそれ以外に管理されているパスキーが存在する場合、 : 先に1Passwordのプロンプトが出てきて、しかも❌ボタンのキャンセルが効かないので実質1Passwordのパスキーしか使えない

という状況でした。生成/登録だけではなく認証の部分もChromeにフォールバックさせて欲しいところです。

まとめ

1Passwordのパスキー対応について調べました。

  • パスキー生成/登録、ログインをするためには1Passwordのアンロックが必要で、それがされている=UserVerificationが行われた状態なのでローカル認証は呼ばれない
  • パスキー生成はスムーズに完了できるが、サービス側の複数ユーザーの時に1Passwordでは最初のユーザーに対する鍵情報の更新になりそう
  • ログインについて、こちらもローカル認証が呼ばれないので単一ユーザーのログインについてはスムーズにできるが、キャンセルできないのはおかしい
  • Autofillには非対応の模様
  • 既に別の仕組みでパスキーを管理していて1Passwordでもパスキーを管理する場合、その後は1Passwordのプロンプトが先に出てくるので注意が必要。いちいち拡張無効化めんどい。

キャンセルできないとかAutofillに対応していないとかは今後も機能改善などが行われるかと思いますが、ローカル認証が都度呼ばれない点については、利用するサービス側が「必ず毎回ローカル認証呼ばれる前提」で作られていた場合に想定と違う挙動になり得るので気になっています。

モバイルアプリでの対応含め、この辺りは今後も追っていく予定です。

そういえばBitwardenも同様の対応、さらにBitwarden自体へのログインでもPasskeyが利用できるようになったそうじゃないですか。 クロスプラットフォームが実現できるのか、様子を見ていきましょう。

ではまた。

おまけ：UserVerificationについて聞いてみたメモ