--- title: パスキー導入で下した判断と、その後の運用 tags: #wealthnavi #パスキー #android author: [ウェルスナビ株式会社 技術広報チーム](https://www.docswell.com/user/WN_Tech-PR) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/4JMYD1V9JW.jpg?width=480 description: 2026/10/1開催 パスキー導入、何を基準に決める？〜他社の判断に学び、自分たちの答えを探す〜 https://findy.connpass.com/event/406171/ の登壇資料です。 --- ウェルスナビ Engineering Blog https://zenn.dev/p/wn_engineering ウェルスナビ技術広報Xアカウント https://x.com/WealthNavi_Tech ウェルスナビ採用情報 https://recruit.wealthnavi.com/ published: October 01, 26 canonical: https://www.docswell.com/s/WN_Tech-PR/Z3JDEL-2026-10-01 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/4JMYD1V9JW.jpg) パスキー導入で下した判断と、 その後の運用 2026.10.01 パスキー導⼊、何を基準に決める？ 〜他社の判断に学び、⾃分たちの答えを探す〜 佐藤健作 / ウェルスナビ株式会社 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/PJR94L2979.jpg) ⾃⼰紹介 佐藤 健作 ウェルスナビ株式会社 モバイルアプリ開発 / Androidエンジニア ウェルスナビでは • Androidアプリの設計と実装を担当 ひとこと • 個⼈の検証⽤リポジトリで認証を触っています。 今⽇の発表の⽐較と実測部分は、2026年に確かめ直した結果です。 © WealthNavi Inc. All Rights Reserved. 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/PEXQ2WD3JX.jpg) プロダクト紹介 全自動の資産運用サービス 手間を省き、感情に左右されず、 最適なアルゴリズム・自動リバランス・ 自動税金最適化を何十年間も 規律正しくやり続けられる環境を実現する ※1 © WealthNavi Inc. All Rights Reserved. ⼀般社団法⼈資産運⽤業協会「契約資産状況（最新版）(2026年3⽉末現在） 『ラップ業務』『投資⼀任業』」を基にネット専業業者を⽐較 ウエルスアドバイザー社調べ（2026年6⽉時点） ※2 2026年7⽉7⽇時点 ※3 2026年3⽉31⽇時点 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/3EK9MVXNED.jpg) 1 前提とパスキー必須化 2 WebViewを選べなかった 3 判断を2つに分解する 4 導⼊後に起きたこと 5 前提は動く ― 2026年の実測 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/L73WYM5Z75.jpg) 1 前提とパスキー必須化 © WealthNavi Inc. All Rights Reserved. 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/87DK56D4JG.jpg) 前提 認証基盤と共通ID Universal Login ‧Auth0 × ウェルスナビID ‧Web‧iOS‧Androidで同⼀のIDを共有している ‧ログインはUniversal Login⽅式 アプリ Auth0 アプリ ログイン画⾯を ホストされた リダイレクトで 持たない 画⾯で認証 戻る※ ‧Auth0がホストするログイン画⾯へ遷移して認証する パスキーを導⼊した背景 「ログイン画⾯がアプリの外にある」 Web‧iOS‧Androidが同じ画⾯を通る ‧セキュリティ強化の必要性 ‧証券⼝座の不正アクセス‧乗っ取りへの対策 ※ 戻るときに受け取った認可コードを トークンに交換してログインが成立する ‧フィッシング耐性のある認証⽅式 © WealthNavi Inc. All Rights Reserved. 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/VJPKGYXVE8.jpg) パスキー必須化と、例外の設計 原則 • パスキーでのログインを必須化 例外 • 申請することで従来ログインを維持 ◦ フィッシング耐性を全ユーザーに ◦ ID∕パスワード → 認証コード ◦ 対象を段階的に拡⼤ ◦ 利⽤できない⽅向け ◦ 2026年9⽉に全ユーザー展開完了 ◦ パスキー導⼊前からのユーザーが対象 パスキーも認証コードも、通るログイン画⾯は同じ ― では、パスキー認証はどこから呼び出すのか 必須化は⾦融庁‧⽇証協のガイドライン（2025年10⽉改正）に基づく。申請ベースの例外運⽤は当社の設計 © WealthNavi Inc. All Rights Reserved. 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/2EVV6GLREQ.jpg) パスキー認証をどこから呼び出すか 選択肢は3つ アプリ内WebView Custom Tabs Auth0ネイティブAPI WebViewの中から呼ぶ アプリに重ねた ブラウザを介さず、 外部ブラウザから呼ぶ アプリから呼ぶ 移⾏先 EarlyAccessで⾒送った 最初に選んだ この選択が、導⼊前と導⼊後に1つずつ、技術的な課題を⽣みます © WealthNavi Inc. All Rights Reserved. 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/57GLN8X6EL.jpg) 2 1 WebViewを選べなかった © WealthNavi Inc. All Rights Reserved. 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/4EQYQ982JP.jpg) 現象 ブラウザでは成功する。 WebViewでは失敗する。 ○ Chrome：登録もログインも成⽴ × アプリ内WebView：同じページで失敗 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/KJ4WNX2P71.jpg) 切り分けの地図 WebAuthnは2段階で検証される 1 アプリ クライアント検証 2 サーバ検証 検証するのはOS∕Credential 検証するのはRP（Relying Party）＝Auth0 Manager。アプリとドメインが紐 origin が許可リストにあるか、challengeと づいているかを assetlinks.json 署名の正当性 で検証する 失敗すると鍵が作られない 失敗しても端末には鍵が残る どちらで弾かれているかを最初に切り分けないと、総当たりになる © WealthNavi Inc. All Rights Reserved. 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LE1Y5NMX7G.jpg) 第1の壁：クライアント側 RP IDの検証に失敗 ― アプリとドメインの紐付けが検証できなかった assetlinks.json が通る条件 Error creating credential: RP ID cannot be validated. ErrType: androidx.credentials .TYPE_CREATE_PUBLIC_KEY_CREDENTIAL _DOM_EXCEPTION 配信を直しても 304 Not Modified でキャッ シュが返り続けた。 「直したのに直らない」に数⽇を溶かした ✓ インターネットから取得できる（/.well-known/ を公開） ✓ 常に 200 OK で返す ✓ Content-Type: application/json ✓ 署名フィンガープリントとパッケージ名が⼀致 ✓ relation は2種類： 304 は NG 別物 ‧handle_all_urls（App Links） ‧get_login_creds（パスキー） ここは突破できた。問題は次だった © WealthNavi Inc. All Rights Reserved. 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/GEWG543KJ2.jpg) 第2の壁：サーバ側 ― これが根本原因だった Credential Managerが返すclientDataJSONのorigin { "type": "webauthn.create", "challenge": "…", "origin": "android:apk-key-hash:AbCd…", "androidPackageName": "com.example.app" 期待 https://xx.yyy.zzzz.com 実際 android:apk-key-hash:… • Auth0はWeb originしか許可しない。つまり サーバ側で不⼀致になる } • ブリッジ実装のバグではない。アプリが Credential Managerを呼ぶ限り、こうなる • 当時は、WebViewでもアプリからでも同じ値に なった つまり成否を決めるのは、RPがこのoriginを許すかどうか © WealthNavi Inc. All Rights Reserved. 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/47ZLN2VNJ3.jpg) 回避策を2つ試した 1 clientDataJSONを書き換えてみる 2 • デコードしてoriginをWeb originに書き換 originを指定する公式APIを使う • CREDENTIAL_MANAGER_SET_ORIGIN を えた Manifest に追加 • Auth0への登録は成功した • 結果は TYPE_NO_CREATE_OPTIONS • しかしアプリからは使えない • 特権アプリ限定。Googleの承認が必要、 API 34以降のみ ◦ 鍵はWebドメインに紐づき、アプリのorigin と⼀致しない × 署名対象の改変では整合が保てない © WealthNavi Inc. All Rights Reserved. × ⼀般アプリでは使えず、撤退を決めた 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/YJ6W8V59JV.jpg) 撤退の判断 撤退ラインは、着⼿前に引いていた 「いつまでに解決できなければ別⽅針に切り替えるか」を先に決めておく。延⻑戦をやらないための保険 仕様の制約か、実装の問題か 動くとしても運⽤に耐えるのか セキュリティを削るか originの形はAndroidと ⼀時的に動いても、登録とログ お客様の資産を預かる以上、難 WebAuthn仕様が決める。実装の インの整合が取れなくなる 易度が⾼くてもセキュリティは削 ⼯夫では変わらない らない 「なぜできないか」を技術的に明確にすることも、エンジニアリングの成果。 どこまで動いて、どこで詰まるかが分かった。では、代替案はどう選んだのか © WealthNavi Inc. All Rights Reserved. 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/GJ5M9DYDJ4.jpg) 3 1 判断を2つに分解する © WealthNavi Inc. All Rights Reserved. 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/9E2928YM7R.jpg) 判断A｜⽐較①（2025年時点）：ここは仕様で決まってしまう 観点 Custom Tabs（SDK / 自前） WebView RFC 8252 準拠 ○ ×（非推奨方式） パスキー（WebAuthn） ○ ×（originがRP次第） ブラウザとのセッション共有 ○ × SDKでも⾃前でも、この3項⽬はまったく同じ パスキーが使えるかを決めていたのは、WebViewから呼ぶか、本物のブラウザから呼ぶかだった © WealthNavi Inc. All Rights Reserved. 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/D7Y4Y6GPEM.jpg) 判断B｜⽐較②：ここは選べる 観点 Auth0 SDK 自前 Custom Tabs 実装コスト 低 中 追加依存 あり なし 保守性 ◎（SDK更新に追従） △ 分かれるのはここだけ 実装コストと保守性を取って、Auth0 SDKを選んだ © WealthNavi Inc. All Rights Reserved. 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/VENYPZGMJ8.jpg) 判断は2つに分かれていた 判断A：選べない • 外部ブラウザか、WebViewか 判断B：選べる • SDKか、⾃前実装か ◦ パスキーを使うなら前者⼀択 ◦ コストと依存のトレードオフ ◦ 技術的に決まってしまう ◦ ここは⾃分たちで選んだ 認証基盤が違っても、「選べない部分」と「選べる部分」に分けて考えることはできる © WealthNavi Inc. All Rights Reserved. 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/Y79P3ZWWE3.jpg) 当時の結論 originが解けていたとしても、 WebViewは選ばなかった ブラウザとセッションを共有できない RFC 8252で⾮推奨 アプリ側が⼊⼒内容を⾒られてしまう 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/G78DM1NR7D.jpg) 4 1 導⼊後に起きたこと © WealthNavi Inc. All Rights Reserved. 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/L7LM3QP2JR.jpg) 本番 認証は成功している。 でもアプリはログイン画⾯のまま。 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/4EMYD149EW.jpg) 原因 認証中、アプリはバックグラウンドにいる 1 2 3 4 アプリから外部ブラウザへ バックグラウンドで OSがメモリ回収で 復帰したとき 認証完了を待つ プロセスを終了 受け取り⼝が消えている ログインページ読込と認証 その間ずっと 認証結果を受け取る バックグラウンドにいる Activityがない Custom Tabs で認証を開始 繰り返し 発⽣ SDK対応済み 方式由来 メモリが逼迫した状況では、連続し Auth0.Android v3.4.0 で対応済み。 外部ブラウザ⽅式に元からある性 て発⽣することがあった 当社も対応済みバージョン 質。パスキー起因の不具合ではない © WealthNavi Inc. All Rights Reserved. 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/PER94LW9J9.jpg) 対応 受け取り⼝をActivityからApplicationスコープへ BEFORE AFTER 受け取り⼝ = Activity 受け取り⼝ = Application スコープ 画⾯が作り直されると、結果を受け取る相⼿ プロセス再⽣成をまたいで購読し、画⾯が作 がいない り直されても結果を取りに⾏ける © WealthNavi Inc. All Rights Reserved. 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/P7XQ2WP3EX.jpg) この不具合の性質 「パスキーのバグ」ではなく「ブラウザに出る⽅式のバグ」だった 1 クラッシュしない。エラーも出ない 2 起きるかどうかは端末のメモリ状況次第 アプリ側のログにも監視にも痕跡が残らない 3 パスキー固有ではない ― 外部ブラウザ に出る経路すべて 認証⽅式ではなく、外部ブラウザに出る構造に 由来する 狙って再現できない 4 症状だけでは操作ミスと区別できない ユーザーからもサポートからも「ログインでき ない」としか⾒えない 認証⾃体は成功しており、なりすましや情報漏えいは無い。 ただしログインできない状態が確率的に起きるのは、サービスとして許容できない © WealthNavi Inc. All Rights Reserved. 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/37K9MVDN7D.jpg) 運⽤でいちばん⼤きな学び アプリ側には痕跡が残らない 認証基盤側には⽭盾が残っていた • アプリ側には何も記録されない • Auth0のログに⽭盾が残っていた ◦ クラッシュログに出ない ◦ ログインは毎回「成功」 ◦ エラーレートにも出ない ◦ なのにトークン交換がない • アプリ側の監視では検知できない • この差分が原因特定の決め⼿ ⽚側だけ⾒ていると気づけない。アプリ側にも復帰を検知できる計測を⼊れた。 © WealthNavi Inc. All Rights Reserved. 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/LJ3WYMRZJ5.jpg) 5 1 前提は動く © WealthNavi Inc. All Rights Reserved. 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/8JDK56Y4EG.jpg) 当時の制約が変わっていた Android側 • 公式ドキュメントが2026/2に更新 ◦ ブリッジ実装は不要になった ◦ 設定を1⾏呼ぶだけになった • ただしoriginがどうなるかは書かれて いない ◦ では実際はどうなるのか ― ⼿元で確か Auth0側 • ネイティブパスキーAPIが正式版に ◦ Auth0コミュニティでスタッフが明⾔ （2026/6） ◦ apk-key-hash originを検証できる ◦ ブラウザに出ずアプリ内で完結する⽅式 • OTP検証付きサインアップは⾮対応 めた 当社のサインアップは認証コードを挟むので制約は残る。ログイン側での利⽤が選択肢に⼊る。 © WealthNavi Inc. All Rights Reserved. 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/VEPKGY6V78.jpg) 実測：originはWeb originになっていた WebViewのネイティブWebAuthnで返ってきたclientDataJSON 2025年 ⾃前ブリッジ経由（当時の検証） { 2026年9⽉ 実機計測（Android 15 / WebView 151） { "type": "webauthn.create", "challenge": "…", "origin": "android:apk-key-hash:…", "androidPackageName": "com.example.app" } "type": "webauthn.create", "challenge": "…", "origin": "https://passkeytest.github.io/", "androidPackageName": "com.ts.app.easypasskey" } • apk-key-hashではなくhttpsのoriginが返る。第2の壁はこの経路では消えた • 第1の壁は残る。assetlinks.json に get_login_creds が無いと、クライアント側の検証で⽌まる • Chromeが返す値との差分は2つ。末尾スラッシュ付きoriginと、androidPackageName の追加 • サーバ側（Auth0）がこの origin を受け付けるかは未検証。今回はAuth0を経由せず、⼿元のRPで計測した ※ 1機種1回の計測（Android 15 / WebView 151 / androidx.webkit 1.17.0）。WebViewのバージョンで結果は変わりうる。 個⼈環境での検証で、当社のシステム‧コードは含まない © WealthNavi Inc. All Rights Reserved. 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/27VV6G3R7Q.jpg) 2026年の選択肢 判断の軸は変わらない。答えは変わりうる 「origin」「アプリの外に出るか」「セッション共有」で、いま3つの経路を並べるとこうなる アプリ内WebView Custom Tabs + SDK Auth0 ネイティブAPI ネイティブWebAuthn（2026年） 現⾏（Auth0 SDK） 正式版（2025年は早期アクセス） origin（2025年はapk-key-hash） origin origin Web origin Web origin apk-key-hash を検証 assetlinks / get_login_creds assetlinks / get_login_creds assetlinks / get_login_creds 必要 必要 必要 RPが受理するか RPが受理するか RPが受理するか 未検証 ○ ○（署名指紋を登録） アプリの外に出るか アプリの外に出るか アプリの外に出るか 出ない 出る（バックグラウンドで待つ） 出ない ブラウザとのセッション共有 ブラウザとのセッション共有 ブラウザとのセッション共有 × ○ ×（ブラウザに出ないため） ⻘：問題なし 橙：制約‧未確認 © WealthNavi Inc. All Rights Reserved. 黒：3経路とも同じ条件 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/5JGLN8367L.jpg) 持ち帰っていただきたいこと 1 まず「クライアントで弾かれたか、サーバで弾かれたか」を切り分ける 2 パスキーは「認証がアプリの外に出る」⽅式。その帰結を先に設計へ⼊れる 3 アプリ側に痕跡が残らない失敗は、認証基盤側と突き合わせないと⾒えない 4 撤退ラインは引く。ただし撤退した道は定期的に⾒直す 地図がないと総当たりになる プロセス終了で受け取り⼝が消えるリスクは、⽅式を選んだ時点で決まる ログイン成功とトークン交換の差分は、有効な⼿がかりになる 認証基盤の制約は動く。実際、今回確かめたら当時の壁の⽚⽅は消えていた パスキーそのものより「パスキー認証をどこから呼び出すか」の問題として整理すると、⾒通しが良くなります © WealthNavi Inc. All Rights Reserved. 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/47QYQ952EP.jpg) We are hiring 採⽤強化中 安⼼して使える⾦融インフラを共につくる仲間募集 https://recruit.wealthnavi.com/ © WealthNavi Inc. All Rights Reserved. 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/KE4WNX9PJ1.jpg) ご清聴ありがとうございました © WealthNavi Inc. All Rights Reserved. 33 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/L71Y5NKXJG.jpg) 重要な注意事項 • 本資料は、断定的判断を提供するものではなく、情報を提供することのみを⽬的としており、いかなる種類の商 品も勧誘するものではありません。最終的な決定は、お客様⾃⾝で判断するものとし、当社はこれに⼀切関与せ ず、また、⼀切の責任を負いません。 • 本資料には将来の出来事に関する予想が含まれている場合がありますが、それらは予想であり、また、本資料の 内容の正確性、信頼性、完全性、適時性等を⼀切保証するものではありません。本資料に基づいて被ったいかな る損害についても、当社は⼀切の責任を負いません。また、当社は、新しい情報や将来の出来事その他の情報に ついて、更新⼜は訂正する義務を負いません。 • 本資料を利⽤することによりお客様に⽣じた直接的損害、間接的損害、派⽣的損害その他いかなる損害について も、当社は⼀切の責任を負いません。 商号等：ウェルスナビ株式会社 ⾦融商品取引業者 関東財務局⻑（⾦商）第2884号 加⼊協会：⽇本証券業協会、⼀般社団法⼈ 資産運⽤業協会 © WealthNavi Inc. All Rights Reserved.