1 of 96

Chrome Tech Talk Night #16

パスキー

NRIセキュアテクノロジーズ古川英明

メルカリkokukuma, koi

1

2 of 96

スピーカーの紹介

2

3 of 96

セッションスピーカー

NRIセキュアテクノロジーズ �古川英明

メルカリ kokukuma

メルカリ�koi

3

4 of 96

Agenda

概要説明
パスキーの登録
パスキーの認証
Q&Aタイム

4

5 of 96

概要説明

メルカリ koi

5

6 of 96

メルカリの事例を紹介

6

7 of 96

メルカリのFIDO導入までの軌跡

2023/3�(App)

2023/4

(App)

2023/10 (Web)

2024/2�(App)

https://about.mercari.com/press/news/articles/20230414_passkeys/

https://about.mercari.com/press/news/articles/20240129_passkeys/

8 of 96

パスキーの登録

メルカリ登録メールアドレス

Googleアカウント

Step 1

登録ボタンを押下

Step 2

SMS認証

Step 3

パスキー作成

完了 👏

9 of 96

パスキーを使ったログイン

Step 1

ログイン画面を表示

Step 2

パスキーを選択

Step 3

顔や指紋、画面ロックで認証

完了 👏

10 of 96

クロスデバイス認証

Step 1

ログイン画面を表示

Step 2

QRコード表示

Step 3

カメラでQRコード読み取り

顔や指紋、画面ロックで認証

完了 👏

パスキー登録済みデバイス

11 of 96

FIDO認証における実績と効果

所要時間

認証成功率

400万

4.4秒

82.5%

登録者数

登録者数は2024/5の実績

その他数値は2023年のメルカリのデータから算出

12 of 96

認証の利用実態

SMS OTPとFIDOの認証実績比較

13 of 96

メルコインにおけるフィッシングによる被害

※ 2024/5時点で現時点でのメルコインサービスでの不正購入の入信、調査実績による

0件

14 of 96

どのような訴求をしているの？

ログイン後パスキー登録訴求

パスキー未登録のお客様へ、次回以降のログインがスムーズになることを伝え登録をお願いする画面を表示しています

15 of 96

課題

01

02

03

さらなるフィッシング対策強化

利用者数の拡大

サービス利用中の認証体験の最適化

16 of 96

Appendix

16

17 of 96

おまけ

error_codeが同じでも中身の性質が異なるものがあり、ユーザーへの説明がcodeから判定しにくいケースがある�

e.g., エラーコードのサンプル

error_code=35

Cannot find credential in local KeyStore or database
None of the allowed credentials can be authenticated
Failed to decrypt credential.
User canceled the request
Unable to get sync account.
Unable to create key during registration

error_code=1004

Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Stolen Device Protection is enabled and biometry is required." UserInfo={NSLocalizedFailureReason=Stolen Device Protection is enabled and biometry is required.}
Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier 2CCV6DZ29E.com.kouzoh.ios.mercari is not associated with domain jp.mercari.com" UserInfo={NSLocalizedFailureReason=Application with identifier 2CCV6DZ29E.com.kouzoh.ios.mercari is not associated with domain jp.mercari.com}
Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Request already in progress for specified application identifier." UserInfo={NSLocalizedFailureReason=Request already in progress for specified application identifier.}�

17

18 of 96

動かして学びたい人向け

Webauthn.io�パスキーの登録と認証を試せるデモサイト�
ウェブアプリでフォームの自動入力を使用してパスキーを実装する�とりあえずこれやれば、パスキーだいたいわかる�

18

19 of 96

読んで学びたい人向け

passkeys.dev�Device Supportの部分何度も見ちゃう。�実装もちょっと載ってる。�
Web+DB vol 136 実戦投入パスキーいまこそ実現，パスワードレス認証！�いいまとめ。�
パスキーによるパスワードなしのログイン�Googleさん公式のガイド。動画や図で分かりやすい�
Supporting passkeys�Appleさん公式のデベロッパー向けのAPI Document

19

20 of 96

じっくり読んで学びたい人向け

Web Authentication: An API for accessing Public Key Credentials�WebAuthNの仕様�
FIDO Alliance Design Guidelines�パスキーのデザインガイドライン�
Synced Passkey Deployment: Emerging Practices for Consumer Use Cases�Consumer向けパスキーデプロイ時の考慮事項

20

21 of 96

パスキーの登録

メルカリ kokukuma

21

22 of 96

パスキーの登録 / よくある誤解�
パスキーの管理 (おまけ)�
パスキー登録への誘導 (おまけ)

22

23 of 96

パスキーの登録

23

24 of 96

ユーザ体験 - パスキーの登録

https://webauthn.io/

同じデバイス上に登録

別のデバイス上に登録

別のデバイスで、�QRコードを読んで登録

24

25 of 96

登録の流れ

https://w3c.github.io/webauthn/#sctn-api

25

26 of 96

登録の流れ - 前半

https://w3c.github.io/webauthn/#sctn-api

26

27 of 96

① ~ ② サーバで情報準備して認証器にリクエスト

① サーバから必要な情報を取得

challenge、excludeCredentials等
WebAuthn APIがArrayBufferで受け取る情報はBase64URL encodeして渡す�

② クライアントから、認証器にリクエスト

サーバから取得した情報を、navigator.credentials.createに渡す
ArrayBufferを要求してるのは、Base64URL decodeする。

27

28 of 96

Server側の実装雰囲気

https://glitch.com/edit/#!/passkeys-codelab?path=libs%2Fauth.mjs%3A2%3A0

28

29 of 96

Client側の実装雰囲気

https://glitch.com/edit/#!/passkeys-codelab?path=public%2Fclient.js%3A112%3A0

29

30 of 96

もっと細かいパラメータの解説

PublicKeyCredentialCreationOptions

https://w3c.github.io/webauthn/#sctn-api

30

31 of 96

AuthenticatorAttachment / Hints

使える認証器の種類を指定する�� authenticatorSelection.AuthenticatorAttachment

RPは、navigator.credentials.create() を呼び出してパスキーを作成するときに、�これを使用して、登録を許可する認証機のタイプを指定する事ができます。�e.g., “platform”, “cross-platform”�https://w3c.github.io/webauthn/#enum-attachment

�Hints (near future)

RPは、この列挙を使用して、リクエストを最も適切に完了する方法に関する�ヒントをユーザーエージェントに伝えることができます。�e.g., "security-key", "client-device", "hybrid",�https://w3c.github.io/webauthn/#enum-hints

31

32 of 96

AuthenticatorAttachment / Hints

どういう指定をするかは、RPのパスキー導入目的による

導入目的	スタンス	Authenticator Attachment	Hint
Enterprise	security keyのみ使わせたい	cross-platfrom	security key
Consumer UX改善 / SMS OTPコスト削減	OSのダイアログをシンプルにしたい。 security keyとか、hybridとかは使わせなくても良い。	platform	client-device
Consumer Phishing対策	security keyは持ってないので、ださないようにしたい。	方法なし	client-device, hybrid

32

33 of 96

challenge / rp.id

phishing耐性のある認証を成り立たせる為の必須パラメータ�rp.idとそのsubdomainの範囲が、同じパスキーを利用できる範囲になる�

challenge�パスキー登録をスタートさせたセッションと紐づく、サーバで作成された�ランダムな値を指定。パスキー登録時に検証される。�https://w3c.github.io/webauthn/#sctn-cryptographic-challenges��rp.id�ユーザの登録や認証を行う有効なドメイン名を指定する。�登録されたパスキーは、登録されたrp.idに紐づくRPでの認証でのみ利用できる。https://w3c.github.io/webauthn/#dictionary-rp-credential-params

33

34 of 96

rp.id / challenge

特にrp.id、せっかく登録したパスキーを、使えない状況に陥る可能性ある

rp.id : app1.example.com

パスキー利用可能

app1.example.com
sub2.app1.example.com

パスキー利用不可

example.com
app2.example.com�

rp.id : example.com

パスキー利用可能

app1.example.com
app2.example.com

パスキー利用不可

example.org

WWDC 24: WebKit for Safari 18 beta adds support for using passkeys across related origins. This lets websites use the same passkey across a limited number of domains which share a credential backend.�

native appの場合も、RP IDと同じドメインで、`.well-known/apple-app-site-association` とか、�`.well-known/assetlinks.json` とか公開する必要ある。�https://developer.apple.com/documentation/xcode/supporting-associated-domains�https://developer.android.com/identity/sign-in/credential-manager#create-passkey

34

35 of 96

user.id / excludeCredentials

Provider毎にパスキーを一つだけ作るために使われる�

user.id�RP内でユーザを一意に識別する値です。ユーザがログインに使う識別子とは異なり、�ユーザの個人情報を含まないものにします。�https://w3c.github.io/webauthn/#dictionary-user-credential-params�

excludeCredentials�同じデバイスによる多重登録を防ぐために、登録済みのパスキーの識別子をすべて渡します。�個々に指定されたパスキーが既に存在する場合、認証器はエラーを返します�https://w3c.github.io/webauthn/#dictionary-makecredentialoptions�

35

36 of 96

user.id / excludeCredentials

指定しなきゃいけないものはシンプル。�

RPでユーザに対して一意のIDを、user.idに設定する�
登録されてるパスキーをexcludeCredentialsに設定する

36

37 of 96

user.displayname / user.name

認証時のアカウント選択時に表示したいものを指定する

�user.name�ユーザーアカウントのわかりやすい識別子です。表示のみを目的としています。つまり、�類似の表示名を持つユーザーアカウントの違いをユーザーが判断できるようにします。�たとえば、「alexm」、「alex.p.mueller@example.com」、または「+14255551234」などです。�https://w3c.github.io/webauthn/#dictionary-pkcredentialentity��user.displayName�ユーザーアカウントのわかりやすい名前で、表示のみを目的としています。�RPは、ユーザーがこの名前を選択できるようにする必要がありますが、�必要以上に選択を制限しないでください。�https://w3c.github.io/webauthn/#dictionary-user-credential-params�

37

38 of 96

user.displayname / user.name

指定しなきゃいけないものはシンプル。が...�

Conditional UIとかで表示される値なので、ユーザが見て判別できる値を入れる。�
変更され得ない、アカウントに一意な情報がベスト。�
displayName と nameはまぁ、同じ値でいいだろう...��

WWDC 24: Safari 18 beta adds support for using mediation=conditional for web authentication credential creation. This allows websites to automatically upgrade existing password-based accounts to use passkeys. Learn more by watching Streamline sign-in with passkey upgrades and credential managers at WWDC24�

38

39 of 96

residentKey / userVerification / attestation

その他、色々....��　　authenticatorSelection.residentKey�　　Discoverable Credentialsにするかどうかを指定します。�　　https://w3c.github.io/webauthn/#dictionary-authenticatorSelection�

authenticatorSelection.userVerification�ローカル認証(生体認証、PIN入力など)の必要性を指定します。�https://w3c.github.io/webauthn/#dictionary-authenticatorSelection�

attestation�パスキー生成時の証明伝達に関する設定を指定できます。�https://w3c.github.io/webauthn/#enum-attestation-convey�

39

40 of 96

residentKey / userVerification / attestation

passkey provider依存な部分が多い。

residentKey … Appleは、Discoverable credential / synced passkey しかない

userVerification … required or 気にしない

attestation … synced passkey にattestationないので指定しても無視される

40

41 of 96

登録の流れ - 後半

https://w3c.github.io/webauthn/#sctn-api

41

42 of 96

④ ~ ⑥ 認証器から得た情報をサーバで検証・登録

④・⑤ 認証器から得た情報をサーバに渡す

認証器から得た情報をサーバに渡せる形にする。

ArrayBufferで返ってくるのは、Base64URL encodeするとか。
transportsとかclientExtensionResultsを関数呼んで取得するとか。�

⑥ サーバで情報を検証してパスキー登録

クライアントから渡された情報を検証する。

client data, authenticator data, attestation statement等

必要な情報を保存する

Credential ID,Credential Public Key,AAGUID, Flags等

42

43 of 96

Client側の実装雰囲気

https://glitch.com/edit/#!/passkeys-codelab?path=public%2Fclient.js%3A112%3A0

43

44 of 96

Server側の実装雰囲気

https://glitch.com/edit/#!/passkeys-codelab?path=libs%2Fauth.mjs%3A2%3A0

https://github.com/MasterKale/SimpleWebAuthn/blob/a169def3c663cb671cdc6bc6e00a4993944a61ae/packages/server/src/registration/verifyRegistrationResponse.ts#L55

44

45 of 96

WebAuthnAPI

AuthenticatorAttestationResponseJSON

https://w3c.github.io/webauthn/#sctn-api

45

46 of 96

CollectedClientData

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

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

https://w3c.github.io/webauthn/#dictdef-collectedclientdata�

検証

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

https://w3c.github.io/webauthn/#sctn-registering-a-new-credential

46

47 of 96

attestationObject

authenticator data

�利用された認証器に関する情報

Attested Credential Data.Credential ID：鍵ペアに関連付けられた識別子。
Attested Credential Data.Credential Public Key：公開鍵。
Attested Credential Data.AAGUID：認証器の固有ID。
Flags：認証器の状態や認証の種類を示すフラグ。
rpIdHash：サービスプロバイダのIDのハッシュ値。
Sign Count：認証器内部のカウンター値。
Extensions（オプション）：追加情報。

https://w3c.github.io/webauthn/#sctn-authenticator-data

47

48 of 96

attestationObject

Flags

�認証器の状態や認証の種類を示すフラグ。

UP: User Present … ユーザ存在確認
UV: User Verified … ユーザ検証
BE: Backup Eligibility … パスキーがsyncされる機能を有してるかどうか。
BS: Backup State … パスキーがsyncされたかどうか。

https://w3c.github.io/webauthn/#sctn-authenticator-data

検証

UPが設定されていることを確認する。（options.mediationがconditionalじゃない限り）
RPがユーザー検証を要求する場合、UVが設定されて要ることを確認する。

https://w3c.github.io/webauthn/#sctn-registering-a-new-credential

48

49 of 96

attestationObject

attestation statement

�公開キー資格情報自体とそれを作成した認証者に関するステートメントを含む、�特定の種類の署名済みデータオブジェクトです。�証明機関のキーを使用して作成された証明署名が含まれます。��https://w3c.github.io/webauthn/#sctn-authenticator-data��検証

attStmt, authenticatorData, clientDataHashを受け取り、attestation statementが有効かどうかを判定する。
synced passkeyの場合、attestation statementはついてこない。

https://w3c.github.io/webauthn/#sctn-registering-a-new-credential

49

50 of 96

attestationObject

https://w3c.github.io/webauthn/#sctn-attestation

50

51 of 96

AttestationResponseの検証方法まとめ

CollectedClientDataの検証

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

authenticator dataの検証

rpIdHashが、指定したrp.idのsha256と一致すること
UP/UVが、想定通りの状態になっているか？
BE/BSが、想定通りの状態になっているか？�

attestation statementの検証

attStmt, authenticatorData, clientDataHashを受け取り、attestation statementが有効かどうかを判定する。
細かいところはAttestation Typesによって変わるtypeがnoneの場合、attestation statementはついてこない。�

https://w3c.github.io/webauthn/#sctn-registering-a-new-credential�https://w3c.github.io/webauthn/#sctn-attestation-formats

51

52 of 96

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

Attested Credential Data

Credential ID: excludeCredentialで指定したり色々。
Credential Public Key: 認証時assertionの検証に使うため
AAGUID: passkey providerを判別するため�

Flags

BE: synced passkeyかどうかを判別するため
UP/UV: 登録時にローカル認証してるかどうか。��

他のもまぁ必要があると思えば...

52

53 of 96

よくある誤解

53

54 of 96

初級編

生体認証がサーバに保存されちゃう？

�

Passkey providerは、自由にパスキーにアクセスできちゃう？

54

55 of 96

中級編

パスキーはひとつしか作れない？

�

トラッキングに利用できる？

55

56 of 96

上級編

synced passkeyは、共有されるから安全ではない？

synced passkeyは、atteStmtないから安全ではない？

56

57 of 96

パスキーの管理

57

58 of 96

登録されてるパスキーをどう見せるか？ (UX Guidelines)

https://fidoalliance.org/design-guidelines/patterns/passkey-management-ui-best-practices-for-combining-all-passkey-types/

58

59 of 96

登録されてるパスキーをどう見せるか？ (UX Guidelines)

https://fidoalliance.org/design-guidelines/patterns/passkey-management-ui-best-practices-for-combining-all-passkey-types/

登録・削除

パスキーの名前・icon

登録時の情報

利用情報

59

60 of 96

登録されてるパスキーをどう見せるか？ (Google)

https://www.google.com/intl/ja/account/about/passkeys/

60

61 of 96

登録されてるパスキーをどう見せるか？ (Google)

登録・削除

パスキーの名前・icon

登録時の情報

利用情報

https://www.google.com/intl/ja/account/about/passkeys/

61

62 of 96

それぞれの情報をどうやって取得するか？

パスキーの名前 / アイコン

synced passkeyの場合、passkey providerの名前いれるのがわかりやすい。
AAGUIDからこの辺引いて取れる。アイコンも一緒に取れる。
https://github.com/passkeydeveloper/passkey-authenticator-aaguids
supportされてたらauthenticatorDisplayNameつかえるかもね。�

登録・削除・名前変更

device-bound passkeyの場合、全部同じ名前だと辛い場合も。
そんなときに名前変更があると便利かもしれない。�

登録時の情報・利用時の情報

登録時・認証時に取得しておいて出すのみ

62

63 of 96

パスキー登録への誘導 (おまけ)

63

64 of 96

どのように登録に誘導するか？

UX Guidelines

64

65 of 96

どのように登録に誘導するか？

実際のRPの例

ログイン直後に、パスキー登録訴求
My pageアクセス時に、パスキー登録訴求
特定の機能利用直前に、パスキー登録訴求
パスキーを特定機能利用の必須条件とする
Conditional Creation <- new!

WWDC 24: Safari 18 beta adds support for using mediation=conditional for web authentication credential creation. This allows websites to automatically upgrade existing password-based accounts to use passkeys. Learn more by watching Streamline sign-in with passkey upgrades and credential managers at WWDC24�

65

66 of 96

どのように登録に誘導するか？

色々あるけど結局どれをやれば？

RPのパスキー導入する目的次第。

導入目的	スタンス	使う対策 (例)
UX改善	登録させたい	・アカウント設定画面・パスワードリカバリ時訴求・My pageアクセス時訴求
SMS OTPコスト削減	積極的に登録させたい	・アカウント設定画面・パスワードリカバリ時訴求・My pageアクセス時訴求・アカウント作成時・ログイン直後の訴求
Phishing対策	ガチ積極的に登録させたい	・アカウント設定画面・パスワードリカバリ時訴求・My pageアクセス時訴求・アカウント作成時・ログイン直後の訴求・特定の機能利用直前 / 必須条件

66

67 of 96

パスキーの認証フロー�超概観

NRIセキュアテクノロジーズ株式会社　古川英明

67

68 of 96

パスキーでの認証におけるユーザー体験

主なパスキー呼び出し方法とそれぞれの導線概観
認証時のデータの流れの概観

クロスデバイスでの認証
パスキーでの認証にまつわるよくある誤解を解く

鍵（パスキー）自体が送られる訳では無い
鍵自体が送られないからフィッシング耐性があるわけではない
利用者が必ずしも全く何も覚えなくて良いというわけではない

ユーザー検証についての解説

68

69 of 96

ユーザー体験　主なパスキー呼び出し方法とそれぞれの導線概観

ID入力欄

Conditional UI

パスキーで�ログインボタン

ID入力からの�パスキー要求

FIDOアライアンスの�UXガイドライン^[1]でも推奨

※ただしWindows 10などの

一部環境では利用不可能

IDを基にし、サーバー側が、

利用者に要求するパスキーを絞り込む

パスキーでログイン

ID入力欄

ログイン

※UIはOSやブラウザ、および�バージョンによっても異なります

パスキーを使用しますか？

　　ユーザーID A

　　ユーザーID B

ユーザー検証^[2]

パスキーを使用しますか？

　　ユーザーID A

　　ユーザーID B

ユーザー検証^[2]

[1] https://fidoalliance.org/design-guidelines/patterns/sign-in-with-a-passkey/

[2] ユーザー検証については実施有無も含めて後述

69

70 of 96

Conditional UI

Conditional UIを発動させる準備をする

ID入力欄でConditional UIを発動させるようにする

inputないしtextareaフォーム内での、autocompleteの属性としてwebauthnの値を設定する

ブラウザ側でConditional UIが利用可能かを判定
Conditional UIが利用可能な場合にConditional UIを発動
ユーザー操作中断時のエラー表示も準備

ID入力欄

出所） https://developers.google.com/codelabs/passkey-form-autofill?hl=ja#5

70

71 of 96

パスキーでログインボタン

ボタンを押下することでパスキーのスクリプトが発動するようにする
allowCredentialsの中身は空

allowCredentials = [];

ログイン

71

72 of 96

ID入力からのパスキー要求

入力されたIDから当該ユーザーのパスキーのcredential IDを絞り込む
当該のcredential IDを、allowCredentialsの中に含める

allowCredentials = [credentialId, credentialId];

ID入力欄

72

73 of 96

ID入力からのパスキー要求サーバー側の実装コード例（一部）

出所） https://glitch.com/edit/#!/passkeys-codelab?path=libs%2Fauth.mjs%3A2%3A0

73

74 of 96

ID入力からのパスキー要求クライアント側の実装コード例

出所） https://glitch.com/edit/#!/passkeys-codelab?path=public%2Fclient.js

74

75 of 96

認証時のデータの流れの概観（原図）

出所） https://www.w3.org/TR/webauthn-3

75

76 of 96

認証時のデータの流れの概観⓪

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

認証開始

出所） https://www.w3.org/TR/webauthn-3 を基に作成

0

76

77 of 96

認証時のデータの流れの概観①

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

�challenge

timeout

rpId

allowCredentials

userVerification

hints

attestation

attestationFormats

extensions

� 認証器が他のデータとともに署名するチャレンジ

（任意）完了を待つミリ秒での時間

（任意） “Relying Party”側が主張するRP ID

　　　　クライアントと認証器側で要検証

（任意）クライアントが認証に用いる認証器を�　　　　探索するための値

（任意）ユーザー検証を行うか

（任意）ユーザーエージェントをガイドする�　　　　ための要素（PublicKeyCredentialHints）

（任意）attestation搬送の指定

（任意）attestationステートメント形式の指定

（任意）クライアントと認証器への追加の処理要求

PublicKeyCredentialRequestOptions

サーバー側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

1

77

78 of 96

PublicKeyCredentialRequestOptionsの例

出所） https://www.w3.org/TR/webauthn-3

78

79 of 96

認証時のデータの流れの概観②

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

rpId

clientDataHash

ほか

WebAuthnのRelying Partyを�識別するドメインの文字列

シリアル化されたclientDataのハッシュ

authenticatorGetAssertionオペレーション

clientData：type（処理の種類）、challenge （Base64エンコードされた①のchallenge）、origin、top origin（要求元のトップレベルorigin）、crossOrigin（同一オリジンかのブール値）

クライアント側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

2

79

80 of 96

authenticatorGetAssertionの入力値

出所） https://www.w3.org/TR/webauthn-3 一部加工

シリアル化されたclientDataのハッシュが含まれる

80

81 of 96

clientData内にサーバーからのチャレンジなどがある。

出所） https://www.w3.org/TR/webauthn-3

81

82 of 96

認証時のデータの流れの概観③

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

ユーザー検証「利用者を識別すること」を目的とした「認証器がクレデンシャル生成ないしアサーションの取得のためのローカルでの許可」の確認（PINやパスワードの入力、生体情報での識別）と、authenticatorDataとclientDataHashを結合してクレデンシャルのプライベート鍵を用いてassertion signatureを生成

クライアント側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

3

82

83 of 96

認証時のデータの流れの概観④

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

authenticatorData�

signature

attestationオブジェクトselectedCredential.userHandle

rpIdのハッシュ、フラグ、署名回数、attestedCredentialData、extensions �assertion/attestationの署名

attestation

ユーザーアカウントの識別子�allowCredentialsが空の場合は必須

クライアント側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

4

83

84 of 96

認証時のデータの流れの概観⑤

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

AuthenticatorAssertionResponse

clientDataJSON

�authenticatorData

signature

type（処理の種類）、challenge （Base64エンコードされた①のchallenge）、origin、top origin（要求元のトップレベルorigin）、crossOrigin（同一オリジンかのブール値）

rpIdのハッシュ、フラグ、署名回数、�attestedCredentialData、extensions�assertion/attestationの署名

クライアント側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

5

84

85 of 96

認証時のデータの流れの概観⑥

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

“Relying Party”のサーバー

サーバー側で検証

clientDataJSON

�authenticatorData

signature

type（処理の種類）、challenge （Base64エンコードされた①のchallenge）、origin、top origin（要求元のトップレベルorigin）、crossOrigin（同一オリジンかのブール値）

rpIdのハッシュ、フラグ、署名回数、�attestedCredentialData、extensions�assertion/attestationの署名

サーバー側処理

出所） https://www.w3.org/TR/webauthn-3 を基に作成

6

85

86 of 96

認証時のデータの流れの概観全体像

“authenticator”（認証器）

ブラウザ�（クライアント）

“Relying Party”の�JavaScriptアプリケーション

WebAuthnAPI

“Relying Party”のサーバー

認証開始

�challenge

timeout

rpId

allowCredentials

userVerification

hints

attestation

attestationFormats

extensions

1

0

AuthenticatorAssertionResponse

5

2

4

authenticatorData�

signature

attestationオブジェクトselectedCredential.userHandle

3

ユーザー検証「利用者を識別すること」を目的とした「認証器がクレデンシャル生成ないし�アサーションの取得のためのローカルでの許可」の確認（PINやパスワードの入力、生体情報での識別）、�authenticatorDataとclientDataHashを結合してクレデンシャルのプライベート鍵を用いて�assertion signatureを生成

rpId

clientDataHash

ほか

6

サーバー側で検証

� 認証器が他のデータとともに署名するチャレンジ

（任意）完了を待つミリ秒での時間

（任意） “Relying Party”側が主張するRP ID

　　　　クライアントと認証器側で要検証

（任意）クライアントが認証に用いる認証器を�　　　　探索するための値

（任意）ユーザー検証を行うか

（任意）ユーザーエージェントをガイドするための�　　　　要素（PublicKeyCredentialHints）

（任意）attestation搬送の指定

（任意）attestationステートメント形式の指定

（任意）クライアントと認証器への追加の処理要求

PublicKeyCredentialRequestOptions

clientDataJSON�authenticatorData

signature

（②の下を参照）

（④を参照）

WebAuthnのRelying Party（「WebAuthn APIで�ユーザーを登録と認証するWebアプリケーションのエンティティ」）を識別するドメインの文字列

シリアル化されたclientDataのハッシュ

authenticatorGetAssertionオペレーション

rpIdのハッシュ、フラグ、署名回数、�attestedCredentialData、extensions�assertion/attestationの署名

attestation

ユーザーアカウントの識別子�allowCredentialsが空だった場合は必須

clientData：type（処理の種類）、challenge （Base64エンコードされた①のchallenge）、origin、top origin（要求元のトップレベルorigin）、crossOrigin（同一オリジンかのブール値）

出所） https://www.w3.org/TR/webauthn-3 を基に作成

86

87 of 96

クロスデバイス認証（2024年6月現在）概要

異なるOS提供元の端末などに同期パスキーを同期できない場合など、�“caBLE”や “Hybrid”などと呼ばれた方法で、異なる端末のパスキーを使える。

Android端末

パスキー

iOS/iPadOS端末

パスキー

Android端末

iOS/iPadOS端末

macOS端末

Windows端末

87

88 of 96

クロスデバイスでの認証導線概観

一般的にはパスキーでの認証を行う先の端末でQRコードを表示させ、�Bluetoothも用いパスキーを持つ端末との接続を確立後に行われる。

パスキーを選択する

他の端末のパスキーを使用する

セキュリティキーを使用する

パスキーを持つ端末で�QRコードをスキャン

パスキー

ユーザー検証

※Android端末の場合は�Googleレンズアプリで�QRコードをスキャン

※UIはOSやブラウザ、および�バージョンによっても異なります

88

89 of 96

パスキーにまつわるよくある誤解を解く

鍵（パスキー）自体が送られる訳では無い
鍵自体が送られないからフィッシング耐性があるわけではない
利用者が全く何も覚えなくて良いというわけではない

89

90 of 96

鍵（パスキー）自体が送られる訳では無い

「認証時のデータの流れの概観」の中でも示したように、�鍵（パスキー）自体は認証器からサーバー側に対して送られていない。

90

91 of 96

鍵自体が送られないからフィッシング耐性があるわけではない

以下、WebAuthn Level 3仕様より�
“RP ID”として、WebAuthnのRelying Party（「Web Authentication APIで�ユーザーを登録と認証するWebアプリケーションのエンティティ」）を登録や�認証の実施の際に識別するドメインの文字列がある。�公開鍵のクレデンシャルは登録で用いられた同じエンティティ（“RP ID”により�識別）でしか用いられない。
クレデンシャルを持ち管理する認証器（“authenticator”）は、すべての�オペレーションが特定の“origin”に“scope”（公開鍵が利用されてよい“origin”のセットを設定）されていて、レスポンスの中に“origin”を含めることで異なる “origin”に再送されないようにする。

出所） https://www.w3.org/TR/webauthn-3/

91

92 of 96

利用者が必ずしも何も覚えなくて良いというわけではない

端末（認証器）でパスキー利用時に、「ユーザー検証」（user verification）と�して、「利用者を識別すること」を目的とした「認証器がクレデンシャル生成かアサーションの取得のためのローカルでの許可」の確認が行われうる。
ローカルでの許可確認の手段（許可ジェスチャー: authorization gesture）に、�PINやパスワードの入力、ないし生体情報での識別がある。

生体情報

画面ロック解除�PIN/パスワード

出所） https://www.w3.org/TR/webauthn-3/#user-verification

92

93 of 96

認証時はユーザー検証（“user verification”)について指定が可能

userVerificationとしては“required”、“preferred”、“discouraged”の3択。

required：「サーバー側がユーザー検証を要求し、レスポンス内に “UV”� （“User Verified”）フラグがセットされていなければ一連の流れを失敗させる。� クライアント側はユーザー検証を実施できない場合にはエラーを返す。」
preferred：「サーバー側はユーザー検証が行われることを望むが、� レスポンス内に“UV”フラグがセットされていなくても流れを失敗させない。」
discouraged：「サーバー側はユーザー検証が行われることを望まない。」

出所） https://www.w3.org/TR/webauthn-3/#enum-userVerificationRequirement

93

94 of 96

認証器でのユーザー検証の結果はauthenticatorData内のフラグに包含

“Relying Party”のJavaScriptアプリケーションが“Relying Party”のサーバーに�返答するauthenticatorData内のフラグで、Bit 2がユーザー検証の有無を示す。

1であればユーザー検証が行われた
0であればユーザー検証が行われていない

出所） https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data

94

95 of 96

Q&Aタイム

95

96 of 96

Thank you

96