LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

生体認証とパスキーの違い――ローカル認証とFIDO2パスワードレス認証

モバイルアプリにおけるパスワードレスログインとは、Face IDや指紋認証・パスキー（Passkey）など、パスワードを用いずにユーザーを認証する仕組みの総称です。ただし「生体認証」と「パスキー」は別の概念であり、混同したまま実装の外注を進めると設計ミスや手戻りを招きます。

ローカル生体認証とは何か――端末内で完結する認証

ローカル生体認証とは、Face IDや指紋センサーを使って端末内部でユーザーを確認する仕組みです。認証の結果は端末外へ出ることなく完結します。サーバーとの鍵交換は発生せず、アプリが「端末の持ち主本人か」を確認したいときに使います。

iOSではLocalAuthenticationフレームワークが担当します。AndroidではBiometricPrompt（androidx.biometric）が指紋・顔・虹彩などの生体認証UIを統合的に提供します。いずれもOSが生体情報の照合を行い、アプリはTrue/Falseに相当するコールバック（iOS: LAContext.evaluatePolicy、Android: onAuthenticationSucceeded等）だけを受け取ります。

パスキーとは何か――FIDO2規格に基づく公開鍵暗号認証

パスキーとは、FIDO2規格（WebAuthn＝Web Authentication APIとCTAPで構成）に基づくパスワードレス認証の仕組みです。端末で生成した公開鍵をサーバー（RP: Relying Party）に登録し、ログイン時はサーバーが発行したチャレンジを秘密鍵で署名して返すことで認証が成立します。

フィッシングサイトはRPのオリジンが一致しないため署名が無効になります。これがパスキーの大きな特徴であるフィッシング耐性の根拠です。iOSではApple DeveloperのAuthenticationServicesフレームワークがWebAuthn/パスキーの操作APIを提供します。AndroidではCredential Manager（Jetpackライブラリ）がパスキー・パスワード・フェデレーションサインインを統合して扱います。

なぜ今パスワードレスが求められるのか

FIDO Allianceは、パスキーがパスワードに比べてフィッシングや credential stuffing（流出パスワードの使い回し攻撃）への耐性を根拠に、パスワードレス認証への移行を推奨しています^*1。W3CのWebAuthn仕様（Level 2、2021年4月勧告）も同様の背景で策定されました。

国内では、総務省「国民のためのサイバーセキュリティサイト」がFIDO認証の利活用を紹介しており^*2、金融機関・医療・行政サービスを中心にパスキー対応の検討が進んでいます。

仕組みを理解する――WebAuthn/CTAPと公開鍵暗号・iOS/Androidのフレームワーク

パスキー実装を外注する場合でも、仕組みの概要を把握しておくと発注仕様書の作成や委託先との認識合わせがスムーズになります。ここではWebAuthnとCTAPの関係、および公開鍵暗号の流れを整理します。

WebAuthnとCTAPの役割分担

FIDO2は2つの仕様で構成されています。WebAuthn（Web Authentication API）はブラウザやアプリとRPサーバー間の通信プロトコルを定め、CTAP（Client to Authenticator Protocol）は端末とハードウェアキー（セキュリティキー）など外部認証器との通信を定めます。モバイルアプリのパスキー実装では、端末内のセキュア領域（Secure Enclave / StrongBox）が認証器として機能するため、CTAPの外部認証器は必須ではありません。

iOSのフレームワーク――AuthenticationServicesとLocalAuthentication

iOSでパスキーを実装する際の主要APIはApple Developerが提供するAuthenticationServicesフレームワーク（ASAuthorizationPlatformPublicKeyCredentialProvider等）です^*3。公開鍵の登録・ログイン時のアサーション取得をAPIで操作します。Secure Enclaveが秘密鍵を保管し、Face IDまたはTouch IDによる生体確認を経て署名が実行されます。

端末ロックのみに使うローカル認証（パスワードレスではないアプリ内ロック解除など）は、別途LocalAuthenticationフレームワーク（LAContext）を使います。パスキーと組み合わせる場合は、どちらのAPIを担当させるかを設計段階で明確に分離する必要があります。

AndroidのフレームワークーCredential ManagerとBiometricPrompt

Androidでパスキーを実装するためのAPIはCredential Manager（Jetpackライブラリ）です^*4。パスキー・パスワード・フェデレーションサインイン（Googleアカウント等）を統合して扱えます。登録時はCreatePublicKeyCredentialRequest、認証時はGetCredentialRequestを使います。生体確認のUIはBiometricPromptが担い、onAuthenticationSucceededコールバックで結果を受け取ります。

なお、2025年時点でAndroid WebViewはパスキーのAutofillに未対応です^*4。WebView内でパスキーログインを提供する場合は、System WebViewの利用やAutofillに依存しないログインUXの設計が必要です。最新の対応状況は公式ドキュメントで確認してください。

外注で実装を進める5つの工程

生体認証・パスキー実装を外注で進めるにあたり、要件定義から検証まで5つの工程を順に押さえることが手戻りの少ない進め方につながります。特にサーバー（RP）対応はアプリ実装と並行して進む領域であり、バックエンド・フロントエンド・セキュリティの各専門領域が交差します。

工程1：要件定義――対象アプリ・認証方式・フォールバック設計の合意

まず対象アプリの認証要件を定義します。「ローカル生体認証のみ」か「パスキーによるパスワードレスログイン」かで開発工数と必要なバックエンド改修が大きく変わります。

合わせて、パスキー未対応機種（古いOSや特定メーカー端末）のフォールバック手段（PINコード・SMS OTPなど）を要件として明確にします。フォールバックを後から追加すると、UXフロー全体の再設計が必要になる場合があります。

工程2：認証方式設計――ローカル生体認証とパスキーの組み合わせ設計

要件が固まったら認証方式を設計します。「アプリ起動時のFace IDロック解除（ローカル認証）」と「ログインセッションのパスキー認証」を組み合わせる構成が多くのアプリで採用されています。どのタイミングにどちらの認証を挟むかを画面フロー図として整理します。

認証フローが複雑になると、委託先との仕様認識にズレが生じやすくなります。シーケンス図を要件定義書に含めることで、実装後の修正コストを抑えられます。

工程3：サーバー（RP）対応――WebAuthnサーバーライブラリの選定と実装

パスキーを採用する場合、サーバー側もWebAuthn仕様に対応したRP（Relying Party）サーバーとして実装する必要があります。具体的には、登録リクエスト時のチャレンジ生成・公開鍵の保存・ログイン時の署名検証のロジックを組み込みます。

主要言語向けにOSSのWebAuthnサーバーライブラリ（Node.js向けSimpleWebAuthn、Python向けpy_webauthn、Java向けjava-webauthnなど）が公開されています。既存の認証基盤（OAuth2/OIDC等）がある場合は、その拡張として実装するか新規スタックを採用するかの判断も必要です。

工程4：アプリ実装――iOS/AndroidのAPIコーディングとUI組込み

iOSはAuthenticationServicesのASAuthorizationController、AndroidはCredential ManagerのCredentialManagerClientを使い、登録・認証の各フローをコーディングします。生体認証UIはOS標準のダイアログを使用するため、独自デザインの作り込みは原則不要です。

一方、生体認証の利用可否確認（BiometricManager.canAuthenticate等）や、ユーザーが初回に設定を求められるオンボーディングUXの実装は、外注先との仕様合意が必要な部分です。

工程5：検証――実機テスト・セキュリティ確認・機種差異の洗い出し

パスキー・生体認証は実機でしか確認できない挙動が多くあります。機種・OSバージョン・セキュリティパッチレベルによってBiometricManager.canAuthenticateの返答や、Secure Enclave/StrongBoxの動作が異なる場合があります。

テスト計画には「生体認証が無効の端末」「OS最小サポートバージョン」「機内モード時のパスキー動作」など、想定外の環境を含めることが品質確保につながります。

見落としやすい実装の注意点――フォールバック・WebView・機種差異・アカウントリカバリ

生体認証・パスキーの実装で特に見落とされやすいのが、エッジケースへの対処です。設計段階でこれらを把握しておかないと、リリース後に大規模な修正対応を余儀なくされます。

フォールバック設計――生体認証を使えない状況への対処

Face IDや指紋認証は、手袋着用・濡れた指・マスク着用時など、生体情報の読み取りに失敗する場面があります。パスキーも端末紛失・機種変更時は引き継ぎが必要です。これらの状況に対してPINコード・メールOTP・バックアップコードなどの代替手段を用意しないと、ユーザーがアカウントにアクセスできなくなります。

フォールバックの設計を後付けすると、認証フロー全体のステート管理を見直す必要が生じます。最初から「生体認証が使えない状態」を前提に設計することが、後工程の手戻りを防ぐ重要なポイントです。

Android WebViewの制約――Autofill非対応への対策

Androidの公式ドキュメントでは、2025年時点でWebViewはパスキーのAutofillに未対応であることが示されています^*4。WebView内でログインフォームを扱うアプリ（ハイブリッドアプリ等）では、ネイティブのCredential Managerを直接呼び出せないため、JavaScript BridgeやCustom Tabsへの切り替えなどの代替設計を検討する必要があります。

機種・OSバージョンの差異――サポート範囲の明示

iOS向けパスキーはiOS 16以降、Android向けパスキーはAndroid 9（API Level 28）以降がサポートの目安です。ただし、端末メーカーのカスタマイズやセキュリティパッチの適用状況によって動作が変わる場合があります。外注の要件定義では、サポートするOSバージョンの下限を明示しておくことが、後工程でのデバイステスト範囲の確定に直結します。

アカウントリカバリ――機種変更・端末初期化後の対応

パスキーの秘密鍵は端末のSecure Enclave/StrongBoxに保存されます。AppleはiCloud Keychain経由のパスキー同期をサポートしており、機種変更後も同じApple IDでパスキーを引き継げます^*3。Androidも Google Password Manager を経由したパスキーの同期・バックアップに対応しています^*4。

しかし端末初期化やキーチェーンのリセットが発生した場合は、パスキーが利用できなくなります。このような状況のリカバリフロー（再登録の誘導・本人確認手段）を実装しておかないと、サポート問い合わせの急増につながります。

外注の使いどころ――設計・実装・検証の委託判断軸

生体認証・パスキーの実装は、セキュリティ設計・iOS/Androidの各OS固有API・サーバーサイドのWebAuthn対応という複数の専門領域が重なります。内製エンジニアが全領域をカバーするためには、認証セキュリティ・モバイルOS・バックエンドの知識が必要です。

内製が難しい領域――必要スキルと工数の実態

パスキー実装を内製で完結させる場合、最低でもiOSエンジニア1名・Androidエンジニア1名・バックエンドエンジニア1名（WebAuthn対応）、さらにセキュリティレビューができる人材が必要です。加えて、実機検証のためのデバイス環境の整備も必要になります。

実装工数の目安は仕様の複雑さによって変わりますが、設計・実装・検証を合わせると複数ヶ月規模になることが多いです。社内に認証セキュリティの知見がない場合、設計ミスが後でセキュリティ上の問題として発覚するリスクも考慮する必要があります。

外注が効果的な3つの場面

外注が特に有効なのは以下の3つの場面です。

• 設計フェーズ：認証方式選定・フォールバック設計・RP仕様策定など、セキュリティの専門知識が必要な意思決定を外部専門家に委ねる。
• 実装フェーズ：iOS/AndroidのAPIコーディングとWebAuthnサーバー実装を、OS固有の知見を持つエンジニアチームに委託する。
• 検証フェーズ：多機種・多OSバージョンでの動作確認とセキュリティテスト（ペネトレーションテスト等）を専門チームに依頼する。

委託先を選ぶ際の確認ポイント

委託先の選定では、以下の点を確認することが有益です。

LASSICへの依頼で期待できること

LASSICは元請（プライムベンダー）としてモバイルアプリ開発・システム開発を受託しており、iOS/Android両対応の開発体制を持っています。認証基盤の受託開発・実装支援の知見。認証フローの設計相談からサーバーサイドのWebAuthn対応・検証まで一気通貫での対応が可能です。

まとめ――外注で生体認証・パスキー実装を進める3つのポイント

本稿では、モバイルアプリへの生体認証・パスキー実装を外注で進めるにあたって押さえるべき概念・仕組み・進め方・注意点を整理しました。要点を3つに集約すると次の通りです。

第一に、ローカル生体認証（Face ID/指紋）とパスキー（FIDO2/WebAuthn）は別の仕組みであり、それぞれiOS・Androidで専用のフレームワークが用意されています。両者を混同した要件定義では設計ミスが起こりやすく、外注前に概念を整理しておくことが有益です。

第二に、パスキーの実装はアプリだけでなくサーバー（RP）側の対応も必要であり、設計・フォールバック・アカウントリカバリを含めて一体で設計する必要があります。Android WebViewのAutofill非対応など、OS固有の制約も把握したうえで委託先と仕様を合意することが大切です。

第三に、内製で全領域をカバーするためにはiOS・Android・バックエンド・セキュリティの知見が必要であり、リリーススケジュールや品質要件によっては外注が有効な選択肢になります。委託先の選定では、両プラットフォームの実装経験・WebAuthnサーバー対応・多機種テスト環境を確認することが選定精度を高めます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：FIDO Alliance「Passkeys」（2024年）
2. *2　出典：総務省「国民のためのサイバーセキュリティサイト」（2024年）
3. *3　出典：Apple Developer Documentation「Supporting Passkeys」（2024年）
4. *4　出典：Android Developers「Sign in users with Credential Manager」（2024年）

Tweet