RPがFirefox Androidのパスキーをサポートするときの覚え書き
この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2024 12日目の記事です。
こんにちは。毎度パスキーの話ばかりですみません。そして今回もパスキーのお話です。
今年夏頃に以下の記事を拝読し、興味深いFirefox Androidの仕様について知ることができたのでRPとしてサポートする場合に考慮した方がよさそうなことを書きます。
Android Firefoxの仕様
冒頭紹介したブログによると、Firefox Androidはパスキー登録時にauthenticatorSelection.residentKeyの値によってパスキーを生成する方法が異なるようです。まとめると以下のようになります。
residentKey | 挙動 |
---|---|
required | Credential Managerによる同期パスキー作成 |
discouraged | FIDO APIによるデバイス固定パスキー作成 |
preferred | FIDO APIによる同期パスキー作成※ |
なお、パスキーでの認証時はCredentials Managerを利用しているような挙動となっていました。※
※Android 15, Firefox 133.0.2で確認
(ブログ内では明記されておらず、手元の検証端末で表示されたUIで判断しています。間違っていたら教えてください。)
FIDO APIで作成されるパスキーの注意点
サードパーティパスワードマネージャーでパスキーが作れない
Android 14以降ではCredential Managerを通じてサードパーティパスワードマネージャーでパスキーを作成管理できるようになりました。一方、FIDO APIの方ではこの機能を利用できません。
FIDO API | Credential Manager |
---|---|
GPMでしかパスキー作れない |
その他のオプションから サードパーティパスワードマネージャーを選択可能 |
["internal","cable"]
になる
transportの値がtransportとは、AttestationResponse内に含まれる「そのクレデンシャルを作成した認証器がクライアントデバイスとの接続可能な方法」です。例えば、クライアントデバイスとUSBやNFCで接続可能なセキュリティキーの場合はtransport=["usb","nfc"]
だったり、iOS(Safari)やAndroid(Chrome)などのスマートフォンであれば認証器がデバイス内にあり、かつQRコード読み取りで開始するhybridフローによる接続をサポートしているのでtransport=["hybrid","internal"]
だったりします。"cable"(caBLE)というのはこの"hybrid"の以前の名称です。
ここで登録されたパスキーは、同期パスキーはGPMで管理、デバイス固定パスキーの場合はデバイス内で管理され、従来通りそのデバイスでのパスキーの認証に利用できますし、hybridフローでも問題なく動きます。しかし問題になるのはこのtransportをサーバから受け取ったPCなどのブラウザ側です。具体的にSafari※において、transport=["hybrid"]の場合はhybridフローのみが発動しますが、transport=["cable"]の場合は認証器の候補にセキュリティキーが含まれます。 このような挙動を回避するためにauthenticatorAttachment="platform"を指定しているようなRPでは、この挙動は把握しておくと良いと思います。対策としてはRPが配信するallowCredentialsのtransportsのcableをhybridに上書きする黒魔術しかおもいつきません。
transport=["hybrid"] | transport=["cable"] |
---|---|
hybridフローのみ発動 |
hybridフローとセキュリティキーが発動候補 |
※ Safari 18.2で確認
ThrowされるDOMException
普段WebAuthn APIで開発するときによく見かける例外は、主にユーザキャンセルや認証に利用できるパスキーのないNotAllowedError
や、excludeCredentialsで指定されたパスキーが存在したときのInvalidStateError
です。あとは、限定的ですがAndroid Chromeでデバイス固定パスキーの画面ロック解除時にタイムアウトになった際のNotReadableError
とか。一方Firefox Androidでは一般のユーザ操作によってそれ以外のDOMExceptionが発生するケースがあります。
登録時の挙動
- 登録時
residentKey=required
のケース(Credential Manager)- platform認証器の登録画面で登録キャンセル ->
AbortError
- cross-platform認証器の選択画面/登録画面で登録キャンセル ->
UnknownError
- platform認証器の登録画面で登録キャンセル ->
- 登録時
residentKey=prefferd
(FIDO API)- (platform/cross-platform問わず)登録キャンセル ->
NotAllowedError
- (platform/cross-platform問わず)登録キャンセル ->
- 登録時
residentKey=discouraged
(FIDO API)- platform認証器の登録画面で登録キャンセル ->
UnknownError
- cross-platform認証器の選択画面/登録画面で登録キャンセル ->
NotAllowedError
- platform認証器の登録画面で登録キャンセル ->
認証時の挙動
- 認証時のケース(デバイス固定パスキーがallowCredentialsに含まれていたケース)
- platform認証器の認証画面で認証キャンセル ->
NotAllowedError
- platform認証器の認証画面で認証キャンセル ->
- 認証時のケース(Credential Manager)
- アカウント選択画面での認証キャンセル ->
AbortError
- platform認証器での認証キャンセル ->
UnknownError
- cross-platform認証器の選択画面/認証画面での認証キャンセル ->
UnknownError
- アカウント選択画面での認証キャンセル ->
タイムアウトの挙動
WebAuthn APIの挙動として、RPの指定するtimeoutの値が適切な範囲でない場合は、クライアント内で自動的に「適切な値」に書き換えられます。(参考: WebAuthn L3 5.1.3. Create a New Credential)そして、Android Firefoxではこのtimeoutの値を超過するとTimeoutError
がthrowされます。Chrome(Credentials Manager)やSafariではこの「適切な値」がかなり長いようで基本的にタイムアウトエラーは起こりません。一方でAndroid FirefoxにおいてはFIDO APIを利用する登録ケースではRPが指定した値をほぼ解釈してくれるようでした。また、認証時においてもデバイス固定パスキーを利用するケースでも同様な挙動が見られました。
よってAndroid Firefoxでrpの指定したtimeoutでTimeoutError
がthrowされうるケースは以下です。
-
residentKey=prefferd/discouraged
でパスキー登録を行うケース - 認証時のallowCredentialsにデバイス固定パスキーのkeyIdが含まれているケース
まとめ
Android Firefoxの仕様的にRPが注意すべき点は以下です。
-
residentKey=prefferd/discouraged
を指定しているRPではAndroid Chromeと異なる挙動になる -
AbortError
,UnknownError
,TimeoutError
の例外ハンドリングに注意
サービス内でサポート環境として明記しないとしても、これらの仕様でもUXが破綻しないようなサービス設計にしていきたいですね。
年末年始はパスキー周りの書籍とか特集などの予定がありメジャーな知識はそこで扱うだろうと思い、マイナーな部分を攻めようとしたら仕事の調査報告書みたいになっちゃいました。
以上、Digital Identity技術勉強会 #iddance Advent Calendar 2024、12日目の記事でした。
Discussion