「Chrome Tech Talk Night #16 〜 パスキー」まとめ

2024 年 6 月 14 日、Google 渋谷オフィスにて Chrome Tech Talk Night #16 〜 パスキー が開催されました。 CTTN #16 は、開発者のみなさんがパスキーの基本について学び、よくある疑問を解決できることを目指したイベントです。 FIDO Alliance メンバー企業でアクティブに仕様策定に参加しているエキスパートの皆様がご登壇されました。

資料はこちらに公開されています:Chrome Tech Talk Night #16 パスキー

以下はClaude Sonnet 3.5 によるまとめとNotta.ai によるまとめをもとに若干手を入れたものです。なお、私はこの分野は素人なので、間違いがあると思うので、その場合はご指摘いただければ幸いです。

目次

Chromeテックトーク16 – パスキーについて #passkeys_jp

1. イントロダクション

  • イベント名: Chromeテックトーク16
  • 主題: パスキー
  • 話者:
    • Google デベロッパーアドボケート: えーじ氏 (@agektmr)
    • NRIセキュアテクノロジーズ株式会社: 古川英明氏 (@hdfrk)
    • メルカリ: kokukuma氏 (@kokukuma)
    • メルカリ: 大井孝太郎氏(プロダクトマネージャー)(@koiPM4)

2. メルカリにおけるパスキー導入事例 (大井氏)

3. パスキーの登録について (kokukuma氏)

パスキー登録には、同じデバイス上で登録する方法と、別のデバイスで登録する方法の2つがあります。同じデバイスの場合は生体認証などを経てデバイス上でパスキーが作成されます。別のデバイスの場合は、QRコードを読み取ることで認証を行い、そのデバイス上でパスキーが作成されます。登録時に必要となるパラメータ(チャレンジ、RPIDなど)の役割や、APIコールの流れが説明されました。

ユーザー体験

  • ユーザー体験には同じデバイス上での登録と別のデバイス上での登録の2種類ある。
  • 同じデバイス上だと、登録しようとすると生体情報などが要求されて登録する形。
  • 別デバイス上だと、モバイルデバイスでQRコードを読んで生体認証をして登録を行う形になる。
  • Webauthn.io をみるとよくわかる。

登録プロセス

  1. サーバーがチャレンジを生成 (PublicKeyCredentialCreationOptions)
  2. ブラウザがオーセンティケーターにデータ(rp.Id,User info, RP info, clientDatahash)を渡す
  3. オーセンティケーターでユーザー検証、パスキー生成
  4. 生成されたデータをブラウザに送信
  5. ブラウザがそのデータをサーバーに返送
  6. サーバーで検証と保存

重要パラメーター

  1. AuthenticatorAttachmentとhint
    • 使える認証器の種類(例: platform, cross-platform)を指定する
    • 組み合わせで表示したくないもの(例:コンシューマコンテキストでのsecurity keyなど)を指定することもできる。
    • authenticatorSelection.AuthenticatorAttachment: RPは、navigator.credentials.create() を呼び出してパスキーを作成するときに、これを使用して、登録を許可する認証機のタイプを指定。
      • e.g., “platform”, “cross-platform”
    • Hints (near future): RPは、この列挙を使用して、リクエストを最も適切に完了する方法に関するヒントをユーザー エージェントに伝えることができます。
      • e.g., “security-key”, “client-device”, “hybrid”
    • どういう指定をするかは、RPのパスキー導入目的による
  2. challengeとrp.id
    • phishing耐性のある認証を成り立たせる為の必須パラメータ
    • rp.idとそのsubdomainの範囲が、同じパスキーを利用できる範囲になる
    • Safari ではWWDC2024で発表されたようにRelated Domains が使えるようになってこの制限が弱まっている。
    • challenge: パスキー登録をスタートさせたセッションと紐づく、サーバで作成されたランダムな値を指定。パスキー登録時に検証される。
    • rp.id: ユーザの登録や認証を行う有効なドメイン名を指定する。登録されたパスキーは、登録されたrp.idに紐づくRPでの認証でのみ利用できる。
  3. user.id と excludeCredentials
    • プロバイダーごとにパスキーを1つだけ作るために使用
    • user.id: RP内でユーザを一意に識別する値です。ユーザがログインに使う識別子とは異なり、ユーザの個人情報を含まないものにします。
    • excludeCredentials: 同じデバイスによる多重登録を防ぐために、登録済みのパスキーの識別子をすべて渡します。個々に指定されたパスキーが既に存在する場合、認証器はエラーを返します
  4. user.displayname と user.name
    • 認証時のアカウント選択時に表示したいものを指定
    • user.name: ユーザー アカウントのわかりやすい識別子です。表示のみを目的としています。
    • user.displayName: ユーザー アカウントのわかりやすい名前で、表示のみを目的としています。RPは、ユーザーがこの名前を選択できるようにする必要があります
    • Conditional UIとかで表示される値なので、ユーザが見て判別できる値を入れる。
    • 変更され得ない、アカウントに一意な情報がベスト。
    • displayName と nameはまぁ、同じ値でいいだろう…
  5. residentKey / userVerification / attestation

Client側の実装雰囲気

credentials.createの結果がcredに入ってきて、それをBase64URLエンコードするなど色々して、credential.responseにセットする形。

Server側の実装雰囲気

SimpleWebAuthn を使った例。verifyRegistrationResponseの中身は長すぎるので、別途コードを参照のこと。

たくさん検証パラメータはあるが、中でも重要なのを2つ紹介

CollectedClientData
認証リクエストに関する情報

  • type: webauthn.create
  • challenge: 認証器に渡したチャレンジが返ってくる。
  • origin: ブラウザから認証器に渡されたオリジンの文字

検証

  • type が、 webauthn.create
  • challengeが、サーバ側に保存してある値と一致していること
  • originが、許可したいoriginであることを確認

この検証により、先ほどのrp.Idと組み合わせてフィッシング耐性を獲得している。

attestationObject

  • authenticator data: 利用された認証器に関する情報
  • Flags: 認証器の状態や認証の種類を示すフラグ。検証はUPが設定されていることを確認、RPの要求に応じてUVが設定されていることも確認。
  • attestation statement: 公開キー資格情報自体とそれを作成した認証者に関するステートメントを含む、特定の種類の署名済みデータ オブジェクト。証明機関のキーを使用して作成された証明署名が含まれる。検証にはattStmt, authenticatorData, clientDataHashを受け取り、attestation statementが有効かどうかを判定する。synced passkeyの場合、attestation statementはついてこない。

サーバ側に保存しておくもの

  • Attested Credential Data
    • Credential ID: excludeCredentialで指定したり色々。
    • Credential Public Key: 認証時assertionの検証に使うため
    • AAGUID: passkey providerを判別するため
  • Flags
    • BE: synced passkeyかどうかを判別するため
    • UP/UV: 登録時にローカル認証してるかどうか。

注意点

  • エクステンションの多くはブラウザやOSに完全に実装されているわけではない
  • コンディショナルクリエーション: ユーザーのインタラクションなしでパスキーを作成可能

4. パスキーの認証フロー超概観 (古川氏)

パスキー認証では、サーバーからチャレンジなどのパラメータを受け取り、デバイス上でパスキーを用いてそれらに署名を行います。その署名がサーバーに送られ、サーバー側で公開鍵を使って検証されます。この一連の流れが、ブラウザ、JavaScriptアプリ、認証デバイスを含む各コンポーネント間でどのようにデータが行き来するかが詳細に説明されました。また、パスキーの鍵自体はサーバーに送られないことや、生体情報もサーバーに共有されないことが強調されました。

主なパスキーの呼び出し方法

  1. コンディショナルUI
    • inputないしtextareaフォーム内での、autocompleteの属性としてwebauthnの値を設定する
    • ブラウザ側でConditional UIが利用可能かを判定
    • Conditional UIが利用可能な場合にConditional UIを発動
    • ユーザー操作中断時のエラー表示も準備
  2. パスキーでログインボタン
    • ボタンを押下することでパスキーのスクリプトが発動するようにする
    • allowCredentialsの中身は空
      • allowCredentials = [];
  3. ID入力からのパスキー要求
    • 入力されたIDから当該ユーザーのパスキーのcredential IDを絞り込む
    • 当該のcredential IDを、allowCredentialsの中に含める
      • allowCredentials = [credentialId, credentialId];

認証フローの概要

  1. ユーザーがパスキーでログインを選択
  2. サーバーが認証開始要求を受信
  3. チャレンジなどのデータをブラウザに送信 (PublicKeyCredentialRequestOptions)
  4. ブラウザがオーセンティケーターにデータを渡す (authenticatorGetAssertion)
    • authenticatorGetAssertion の入力値にはrpId, hash などがあるが、このhashの中にシリアル化されたclientDataのハッシュが含まれる。この中に、先ほどサーバーで生成されたhashも含まれる。
  5. オーセンティケーターでユーザー検証
    • ユーザー検証「利用者を識別すること」 を目的とした「認証器がクレデンシャル生成ないしアサーションの取得のためのローカルでの許可」の確認(PINやパスワードの入力、生体情報での識別)
  6. パスキーによる署名
    • authenticatorDataとclientDataHashを結合してクレデンシャルのプライベート鍵を用いてassertion signatureを生成
  7. 署名されたデータをブラウザに返送
    • この時selectedCredential.userHandleにユーザー識別子がセットされて返るのでサーバはどのユーザかがわかるようになる。
  8. 署名されたデータをサーバーに返送(AuthenticatorAssertionResponse)
  9. サーバーで検証
    • 登録されている公開鍵で署名を検証

クロスデバイス認証

異なるデバイス間でパスキーを共有し、認証を行う方法としてクロスデバイス認証があります。この場合、ログインするデバイスでQRコードが表示され、パスキーを持つ別のデバイスでそのQRコードを読み取ることで認証が可能になります。Bluetooth接続が必須となり、一定の距離内でのみ認証できます。クロスデバイス認証の導線と、各デバイスでの操作手順が解説されました。

  • QRコードを使用して異なるデバイス間で認証可能
  • Bluetooth接続が必要

5. よくある誤解と質問への回答

  1. パスキーはサーバーに送られない
  2. フィッシング対策はRPIDとオリジンチェックによって実現
  3. 必ずしもユーザー検証が必要なわけではない。
    • “Relying Party”のJavaScriptアプリケーションが“Relying Party”のサーバーに返答するauthenticatorData内のフラグで、Bit 2がユーザー検証の有無を示す。
  4. 生体情報はサーバーに共有されない
  5. パスキープロバイダーは基本的に秘密鍵を見ることができない
  6. 1つのアカウントに対して複数のパスキーを作成可能
  7. シンクドパスキーとデバイスバウンドパスキーの違い
    • シンクロパスキー: デバイス間で同期可能
    • デバイスバウンドパスキー: 特定のデバイスにのみ紐づく

6. 今後の展望

  • レポートAPI: ユーザー情報の変更をオーセンティケーター側に伝える仕組み
  • アテステーションの活用: セキュリティレベルの確認や特定デバイスの制限など

この会議では、パスキーの基本概念から実装の詳細、実際の導入事例まで幅広くカバーされており、現在のパスキー技術の状況と今後の課題について深い洞察が得られました。

Q&A

なお、セッション中にいくつかQ&Aが行われていました。

Q. メルカリでパスキーの登録時にSMS OTPを要求するのはなぜですか?

  1. フィッシング対策の強化:
    • メルカリの大井氏によると、これはフィッシングリスクをさらに軽減するための措置です。
  2. 既存の強力な認証方法の活用:
    • パスキー登録前の段階では、IDパスワードとSMS OTPの組み合わせが最も強力な認証方法となっています。
  3. 多層防御:
    • 仮にIDとパスワードがフィッシング攻撃で漏洩したとしても、SMS OTPという追加の障壁があることで、不正なパスキー登録のリスクを減らすことができます。
  4. 2段階の検証:
    • ログイン時にIDパスワードとSMS OTPを使用し、その後パスキー登録時にも再度SMS OTPを要求することで、2回のSMS OTP検証を行うことができます。
  5. リスク軽減:
    • この方法により、フィッシングされた情報を使って攻撃者が不正にパスキーを登録するリスクを軽減できます。
  6. ユーザー体験とセキュリティのバランス:
    • 大井氏は、これがUXとセキュリティのバランスを取る上で一定の妥協点であると述べています。
  7. サービスによる判断:
    • ただし、全てのサービスがこの方法を採用しているわけではありません。各サービスのリスク評価や、ユーザーがパスキー登録に至るまでの経路によって、追加認証の要否を判断する必要があります。
  8. 既存アカウントの保護:
    • 特に既存のユーザーベースを持つサービスでは、アカウント乗っ取りのリスクを軽減するために、パスキー登録前の認証を強化する必要があります。

このアプローチは、パスキーという強力な認証方法を導入する際に、その登録プロセス自体もセキュアに保つための戦略の一つとして位置付けられています。

Q: パスキー実装のアンチパターンとしてこういうことをやってしまうと脆弱性を作ってしまうというものがありますか。

A: パスキーのライブラリを使わずに全部自分で実装して、オリジンを検証しないと脆弱性を生む可能性があります。また、パブリックキーの検証をしないと脆弱性になります。さらに、ユーザーベリフィケーションのフラグ(UV)を適切に検証しないと、セキュリティリスクが高まります。

Q: ユーザーネームにメールアドレスを入れた場合、ユーザーがログインに用いるメールアドレスを変更した際、認証機側のユーザーネームを更新することはできますか。

A: 現状ではユーザーネームを更新することはできません。ただし、今後レポートAPIが実装されれば、RPからユーザー情報の変更を認証機に通知し、ユーザーネームを更新できるようになる予定です。

Q: FIDOクレデンシャルとパスキーって何が違うんですか。

A: FIDOアライアンスの定義では、あらゆるパスワードレス認証のクレデンシャルをパスキーと呼んでいます。セキュリティキーやUAFなども、ファイルクレデンシャルの一種であり、パスキーに含まれます。

Q: フィッシング耐性の観点でChromeのパスワードマネージャーとパスキーの差が知りたいです。

A: パスワードマネージャーは文字列を保存しているため、ユーザーがコピー&ペーストしてしまえばフィッシングサイトで使用できてしまいます。一方パスキーはコピー&ペーストができないため、フィッシング耐性があります。パスキーならコピペできないので、サジェストされないサイトではログインできません。

Q: extensionsについてどれくらい自由に指定できるものなのでしょうか?

A: エクステンションは、ブラウザやOSに実装されている機能次第で、自由に指定できるわけではありません。ドキュメントに記載されているエクステンションのみ使用可能です。

Q: メルカリでは当初デバイスバウンドだけだったのがシンクドも利用可能にしたとのことでしたが、シンクド共有をしたことによる新たな普段や特有のトラブルはありましたでしょうか?

A: シンクドパスキーを導入したことで、iCloudの設定が適切でないユーザーからの問い合わせが増えるなどの新たな課題が発生しました。また、デバイスを紛失した場合の対応も必要になりました。一方で、デバイスバンドパスキーに比べて問い合わせ数は減少しました。

Q. クロスデバイス認証は背後からQRコードを読み取られるリスクがあると思うのですが、これを禁止することはCredentialCreationOptionsなどの指定で可能ですか?

A. 現在はできません。

Q: caBLE, ハイブリッドでのパスキーの利用ですが、操作端末とパスキーを持つ端末をそれぞれ別で操作することはできないんでしょうか?Bluetoothでの接続が必須となるのでしょうか?

A: はい、Bluetooth接続が必須となります。離れた場所にある端末ではパスキー認証ができず、Bluetooth通信が可能な一定距離内でのみ認証が行えます。

Q: パスキーの仕様書として、WebAuthnのレベル3はまだドラフトという認識ですがレベル2とレベル3の現在の立ち位置の違いを伺いたいです。またレベル3にも、w3.org とW3C.GitHubIOの仕様書の2種類が存在していますが今回のハッカソンの実装上はどれを参照するのが良いのでしょうか?

A: レベル3はまだドラフトの段階で、ブラウザに実装されていない機能が多数含まれています。一方でレベル2はブラウザにおおむね実装されているため、ハッカソンではレベル2の仕様を参照するのが適切です。レベル3の仕様書は最新のドラフトですが、まだ実装されていない部分が多いでしょう。

Q: IDパスワードはパスワード間違いが多いと思いますがパスキーでの認証成功率は何に依存するのでしょうか?

A: パスキーでの認証成功率は、生体認証の失敗、デバイスの状態(パスキーが同期されていないなど)、ユーザーの操作ミスなどに依存します。パスワードに比べて成功率は高いものの、完全ではありません。

Q: 「Passkeys」という言葉の正確な定義は何でしょうか?

A: 仕様書の中で「パスキー」という言葉の明確な定義はありません。ただし一般的には、パスキーとは認証に使う秘密鍵のことを指します。厳密な定義はないため、ワードとしての「パスキー」の捉え方で問題ありません。

Q: Synced passkeys と Device-bound Passkeys などそれぞれの言葉はどの仕様で定義されていますか。

A: これらの言葉の定義は、仕様書ではなくFIDOアライアンスのFAQなどで記載されています。正式な仕様での定義ではありません。

Q: シンクド(同期)パスキーとそうでないパスキーの違いが知りたいです。

A: 同期パスキーは、クラウドなどを介して複数のデバイス間で共有できるパスキーです。デバイス固定パスキーは、特定のデバイスにのみ存在し、他のデバイスで利用できません。Appleデバイスでは全てのパスキーが同期パスキーとなり、Androidデバイスではオプションで同期/デバイス固定を選択できます。

Q: アテステーションはどういったユースケースが想定されているものなのでしょうか?

A: アテステーションは、デバイスが信頼できるものかどうかを検証するために使われます。デバイスメーカーによって異なる署名が入っているため、エンタープライズ向けのサービスでは利用が難しい場合があります。一般的なコンシューマー向けサービスでは、アテステーションの有無に関わらずパスキーを提供するのが適切とされています。

4:57 メルカリにおけるパスキーの導入事例
24:23 パスキーの登録
50:28 パスキーによる認証フロー概観
1:12:40 休憩
1:25:22 Q&Aタイム

より詳細な情報

上記のまとめだとあまりにも簡潔にすぎるので、Claudeに追加でいくつか質問しました。なお、音声のトランスクリプトしか入れていないのにコードサンプルが出てくるのは、Claudeが持っている知識を使っていると思われます。(なので、正しいかどうかは謎)

Q. パスキーの登録における、Server側の実装について説明してください。

パスキーの登録における、サーバー側の実装について、会議での説明を基に詳細にまとめます:

  1. チャレンジの生成:
    • サーバーは、認証のためのランダムな値(チャレンジ)を生成します。
    • このチャレンジは後でチャレンジレスポンス認証に使用されます。
  2. 登録オプションの準備:
    • サーバーは以下の情報を含む登録オプションを準備します:
      • チャレンジ
      • ユーザー情報(ユーザー名、ユーザーID等)
      • 既存のクレデンシャルID(既に登録されている場合)
      • リライングパーティ(RP)の情報(名前、RPID等)
  3. データのエンコード:
    • 準備した情報は通常、Base64でURLエンコードされてクライアントに送信されます。
  4. クライアントへの送信:
    • エンコードされたデータをJSONフォーマットでクライアントに送信します。
  5. レスポンスの受信:
    • クライアントから送り返されたアテステーションレスポンスを受信します。
    • このレスポンスには、クライアントデータJSON、アテステーションオブジェクト等が含まれています。
  6. デコードと検証:
    • 受信したデータをBase64デコードします。
    • デコードしたデータを検証します。
  7. 検証プロセス:
    • チャレンジの一致確認: 保存していたチャレンジと一致するか確認
    • オリジンの確認: RPが許可したオリジンかどうか確認
    • 公開鍵の抽出: アテステーションオブジェクトから公開鍵を抽出
    • フラグの確認: UV(User Verification)、UP(User Presence)等のフラグを確認
  8. パスキーの保存:
    • 検証が成功した場合、以下の情報を保存します:
      • 公開鍵(必須)
      • クレデンシャルID(エクスクルードクレデンシャルに使用)
      • アルゴリズム(認証に使用される暗号アルゴリズム)
      • 登録要求時の追加情報(任意)
  9. エラーハンドリング:
    • 検証プロセスで問題が発生した場合、適切なエラーメッセージを生成し、クライアントに返します。
  10. セキュリティ考慮事項:
    • アテステーション検証: デバイスや認証器の信頼性を確認する場合に実施
    • ユーザー検証(UV)フラグの扱い: サービスのポリシーに応じて、UVフラグの有無による処理を決定
  11. レスポンス:
    • 登録成功または失敗のレスポンスをクライアントに返します。

実装上の注意点:

  • ライブラリの使用: 多くの場合、WebAuthn/FIDO2ライブラリを使用して実装を簡略化します。
  • セキュアな乱数生成: チャレンジ生成には暗号学的に安全な乱数生成器を使用します。
  • RPID設定: フィッシング対策として重要なRPIDを適切に設定します。
  • データの永続化: 公開鍵などの重要データを安全に保存するための仕組みを整えます。

この実装フローは基本的なものであり、具体的なサービスの要件や使用するライブラリによって詳細が異なる可能性があります。セキュリティを重視しつつ、各サービスの特性に合わせた実装を行うことが重要です。

Q. パスキーの登録における、Client側の実装について説明してください。

パスキーの登録における、クライアント側の実装について、会議での説明を基に詳細にまとめます:

  1. サーバーからの情報取得:
    • サーバーのURLにアクセスし、登録に必要な情報(オプション)を取得します。
    • 取得したデータは通常Base64でURLエンコードされているため、デコードする必要があります。
  2. データの準備:
    • デコードしたデータを適切な形式に変換します。
    • 主な項目には以下が含まれます:
      • チャレンジ
      • RPID(Relying Party ID)
      • ユーザー情報(name, displayName等)
      • 公開鍵の生成に関するパラメータ
  3. navigator.credentials.create() APIの呼び出し:
    • Web Authentication APIを使用して、パスキーの作成を開始します。
    • 準備したデータを引数として渡します。
const publicKeyCredential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});
  1. ユーザーインタラクション:
    • ブラウザはユーザーに対して認証器(オーセンティケーター)の選択を促します。
    • ユーザーは生体認証やPIN入力などで本人確認を行います。
  2. パスキーの生成:
    • 選択された認証器がパスキー(公開鍵と秘密鍵のペア)を生成します。
    • 秘密鍵は認証器内に安全に保存されます。
  3. アテステーションレスポンスの取得:
    • 認証器は生成したパスキーに関する情報を含むアテステーションレスポンスを返します。
  4. レスポンスの処理:
    • 返されたアテステーションレスポンスを適切な形式に変換します。
    • 主な項目には以下が含まれます:
      • クライアントデータJSON
      • アテステーションオブジェクト
      • 公開鍵
  5. サーバーへのデータ送信:
    • 処理したデータをサーバーに送信します。
    • データは通常、Base64エンコードされてJSONフォーマットで送信されます。
const response = await fetch('/register', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    id: base64url.encode(publicKeyCredential.rawId),
    rawId: base64url.encode(publicKeyCredential.rawId),
    type: publicKeyCredential.type,
    response: {
      clientDataJSON: base64url.encode(publicKeyCredential.response.clientDataJSON),
      attestationObject: base64url.encode(publicKeyCredential.response.attestationObject),
    },
  }),
});
  1. エラーハンドリング:
    • プロセス中に発生する可能性のあるエラーを適切に処理します。
    • 主なエラーには以下があります:
      • ユーザーによるキャンセル
      • 非対応デバイス
      • タイムアウト
  2. UI更新:
    • 登録プロセスの状態をユーザーに適切にフィードバックします。

実装上の注意点:

  • ブラウザ互換性: 全てのブラウザがWeb Authentication APIをサポートしているわけではないため、フォールバックオプションを用意することが重要です。
  • セキュリティ考慮事項: クライアント側でのデータ処理は最小限に抑え、重要な検証はサーバー側で行うようにします。
  • ユーザー体験: スムーズな登録プロセスのために、適切なガイダンスとエラーメッセージを提供します。
  • プラットフォーム固有の実装: モバイルアプリケーションの場合、プラットフォーム固有のAPIを使用する必要がある場合があります。

この実装フローは基本的なものであり、具体的なアプリケーションの要件や使用するライブラリによって詳細が異なる可能性があります。セキュリティと使いやすさのバランスを取りながら、各アプリケーションの特性に合わせた実装を行うことが重要です。

Q. クロスデバイスのパスキーを利用した認証のステップについて解説してください。

クロスデバイスのパスキーを利用した認証のステップについて、会議での説明を基に詳細に解説します:

  1. 認証開始:
    • ユーザーが、パスキーを持っていないデバイス(例:PC)でログインを試みます。
  2. 認証オプションの表示:
    • ブラウザは、ユーザーに認証オプションを提示します。
    • 通常、以下の選択肢が表示されます:
      • 他の端末のパスキーを使用
      • セキュリティキーを使用
  3. クロスデバイス認証の選択:
    • ユーザーが「他の端末のパスキーを使用」を選択します。
  4. QRコードの表示:
    • ログインしようとしている端末(PC)にQRコードが表示されます。
    • このQRコードには、認証に必要な情報が含まれています。
  5. モバイルデバイスでのQRコード読み取り:
    • ユーザーは、パスキーを持つモバイルデバイス(スマートフォンなど)でQRコードをスキャンします。
    • iOSの場合: 標準のカメラアプリでスキャン可能
    • Androidの場合: Google Lensアプリを使用してスキャン
  6. Bluetooth接続の確立:
    • QRコードスキャン後、ログイン端末とモバイルデバイス間でBluetooth接続が確立されます。
    • この接続は、デバイス間の近接性を確認し、セキュリティを強化するために使用されます。
  7. パスキーの選択:
    • モバイルデバイス上で、該当するアカウントのパスキーが表示されます。
    • 複数のパスキーがある場合、ユーザーは適切なものを選択します。
  8. ユーザー認証:
    • モバイルデバイス上で、ユーザー認証(生体認証やPIN入力など)が行われます。
  9. 署名の生成:
    • 認証が成功すると、モバイルデバイス上でパスキーを使用して署名が生成されます。
  10. データの送信:
    • 生成された署名とその他の必要なデータが、Bluetooth接続を通じてログイン端末(PC)に送信されます。
  11. サーバーへの送信:
    • ログイン端末は受け取ったデータをサーバーに送信します。
  12. サーバーでの検証:
    • サーバーは受信したデータを検証し、認証の成否を判断します。
  13. 認証完了:
    • 検証が成功すると、ログイン端末(PC)上で認証が完了し、ユーザーはログインした状態になります。

注意点と補足情報:

  • セキュリティ: QRコードとBluetooth接続の組み合わせにより、物理的な近接性が要求され、リモートからの不正アクセスリスクが軽減されます。
  • ユーザー体験: この方法により、パスキーを持っていない端末でも安全にログインできますが、QRコードのスキャンなど追加のステップが必要になります。
  • デバイスの制限: 現状、クロスデバイス認証に使用できるのは主にスマートフォン(AndroidまたはiOS)です。
  • プラットフォーム依存: 具体的な実装方法は、使用するプラットフォームやブラウザによって若干異なる可能性があります。
  • Bluetooth要件: クロスデバイス認証にはBluetoothの接続が必須であり、これにより遠隔地からのQRコード読み取りによる不正アクセスを防いでいます。

このクロスデバイス認証の仕組みは、パスキーの利便性を大きく向上させる一方で、セキュリティも維持する重要な機能です。ただし、ユーザーへの適切な説明と導入が必要となります。

脚注

  1. 15:05にグラフあり

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください