ヤフーのiOSアプリにおけるローカル認証を活用した独自のデバイス認証からパスキー認証への移行対応

こんにちは。Yahoo! ID連携のiOS SDKの開発・運用を担当している矢倉です。

現在、多くのヤフーのiOSアプリでは、ローカル認証を活用した独自のデバイス認証による再認証機能を搭載しています。この機能を提供しているのが、ヤフーのiOSアプリ向けのID連携 SDK です。**SDK では、利便性とセキュリティを両立させるさまざまなログイン機能を提供していますが、このたび新たに同期パスキー（以下、パスキー）に対応しました。

パスキーを利用したログインの仕組みについては以下の記事で紹介されていますので、詳細は「FIDO 認証＆パスキー総復習（認証の仕組みやパスキー登場までの経緯）」をご覧ください。

• FIDO 認証＆パスキー総復習（認証の仕組みやパスキー登場までの経緯）

以降、iOS アプリにおけるローカル認証を活用した独自のデバイス認証を標準規格であるパスキーへ移行した背景と、パスキー対応の内容を解説します。

移行した背景

ローカル認証を活用したデバイス認証

ヤフーの iOS アプリでは、2019年から Local Authentication framework（ローカル認証）を活用したログイン方法をサポートしてきました。

しかし、ヤフーの iOS アプリで扱うローカル認証によるログインは独自の仕様に基づいて実装されたものでした。

この記事では、ローカル認証だけでログインが完了する FIDO に近いデバイス認証方式のことを、「独自仕様FIDO」** と呼びます。

この独自仕様FIDO には以下のようなデメリットがありました。

• 鍵を登録した端末でしか使えず、機種変更時などに鍵の再登録が必要
• ログイン状態でないと鍵が使えず、再認証にしか利用できない
• ブラウザとアプリ間で鍵が共有されない

パスキー対応によるデメリット解消

独自仕様FIDO の課題を解決し、よりスムーズなユーザー体験を提供するためにパスキー対応を進めました。

パスキーを導入することで独自仕様FIDO のデメリットを解消できます。

• iCloud キーチェーンによるデバイス間同期

パスキーは Apple Account（旧Apple ID）にひも付くiCloud キーチェーンと連携します。これにより、作成したパスキーは同一 Apple Account（旧Apple ID）でサインインしている端末間で同期されます

• 端末を変更・紛失した場合でも、鍵の再登録なしでパスキーによるログインが可能になります

• Web との実装共通化

iOS 16.4以降、アプリの WebView 内でもWebAuthn API が拡張され、認証フローが扱えるようになりました

パスキー対応の内容

パスキー実装方式の検討

iOS アプリでパスキーを実装するにあたり、ユーザー体験と開発コストのバランスを考慮し、どの方式が適切か比較検討を行いました。

iOS における同期パスキーの正式サポートは iOS 16 から開始されていますが、アプリの WebView 内で利用できるのは iOS 16.4以降となります。

• Supporting passkeys

まず、以下の3つの方式を候補として整理しました。

ネイティブ API

ネイティブ API による Public-Private Key 認証 Public-Private Key Authentication

SFSafariViewController / ASWebAuthenticationSession

ブラウザ相当のコンテキストでの WebAuthn API（JavaScript）ASWebAuthenticationSession など

WebView（WKWebView）

アプリ内 WebView での WebAuthn API（JavaScript）。iOS 16.4 以降の WKWebView で WebAuthn によるパスキーが利用可能

ネイティブ API 案

「ネイティブ API」は OS 標準の UI を利用でき、iOS 15 以降で動作するというメリットがあります。一方で、ヤフーの iOS アプリでは既存のログイン画面がアプリ内 WebView 上にあり、Web ベースのフローを前提とした実装になっています。

新規ログイン（※1）も含めてネイティブ API に切り替える場合、以下のような課題がありました。

※1 アプリ内 WebView でログイン用の ID 入力画面が表示されるケース

• WebView 上の ID 入力画面から、ネイティブの認証フローへ遷移させるための実装（ユニバーサルリンクなど）が必要
• Web 側で構築済みのログインフローと、ネイティブ側の認証フローを連携する実装が複雑になる
• SDK 利用アプリ側も、既存の WebView ベースのログイン連携からネイティブ API 連携へ切り替える必要があり、影響範囲が大きい

これらを踏まえると、既存の Web フローとネイティブ API を連携させるための実装コストが高く、「ネイティブ API」を採用するのは現実的ではないと判断しました。

SFSafariViewController / ASWebAuthenticationSession 案

「SFSafariViewController / ASWebAuthenticationSession」を用いる案のメリットは、ブラウザ相当のコンテキストで WebAuthn を利用でき、iOS 15 以降の幅広い OS バージョンで動作することです。

しかしこの案でも以下のようなデメリットが挙げられました。

• 既存のログイン画面がアプリ内 WebView 上にあるため、ログイン UX を「SFSafariViewController / ASWebAuthenticationSession」側に移す必要がある
• それに伴い、

既存の WebView ベースの UX を見直す必要がある

• SDK が提供している WebView 連携インターフェースの設計を変更する必要がある

• iOS 15 自体はサポートできるものの、iOS 15 では同期パスキーには対応しておらず、デバイス固定パスキー用の追加開発が必要となる

古い OS バージョンのシェアに対して追加の開発コストが見合わない

OS対応範囲の広さというメリットはあるものの、既存UXやSDK連携部分への影響が大きいこと、開発コストに見合ったリターンが得られないことから採用を見送りました。

WebView案を採用した理由

最終的に、本SDKではWebView（WKWebView）を使う方式を採用しました。判断の主な理由は次のとおりです。

• 既存ログイン画面がWebView上にあり、SDK既存のWebViewロジックをそのまま流用できる
• Web側の資産（画面UI・認証ロジック）を活用できるため、ブラウザ向け実装との共通化がしやすい
• SDK利用アプリ側は従来どおりWebViewベースの連携を維持でき、アプリ側の改修量を抑えられる
• iOS 16.4以上であればWKWebViewからWebAuthn APIを呼び出すことでパスキーに対応できる
• iOS 16.4未満の端末についてはこれまでどおり既存の独自仕様FIDOでフォールバックできるため、OSバージョン間でのUXの差分を最小限に抑えられる

総合して検討した結果、本SDKでは「iOS 16.4以上はWKWebViewでパスキーに対応し、iOS 16.4未満は独自仕様FIDOを利用する」というハイブリッドな構成を採用しました。

この構成については後述する「独自仕様FIDOとパスキーの共存」で詳しく説明します。

iOSにおけるパスキー対応の実装

サーバー側がWebAuthnに対応済みであれば、アプリ側の対応は比較的シンプルです。

Supporting passkeys #Use passkeys in a web view を参考に設定を行うだけで、基本的な対応は完了します。

ここでは、apple-app-site-association に関する Tips を紹介します。

apple-app-site-associationの反映タイミング

apple-app-site-association はAppleのCDNを経由して取得されます。

そのため、Supporting associated domains に記載のとおり、実際にアプリに設定が反映されるまでは最長1週間ほどかかります。全アプリに対して即時反映させる機能はないため注意が必要です。

なお、CDN の更新頻度やアプリ側への反映タイミングなどの挙動は将来的に変更される可能性があります。最新の仕様については必ず公式ドキュメントを確認してください。

• Apple CDN

24時間以内に1回更新

• アプリ（CDNから取得）

インストール・再インストール時に新規取得

• インストール後、約1週間に1回更新

開発時は mode=developer を付与することで、Apple CDNを経由せずに直接 apple-app-site-association を取得できます。反映の制限がなくなるため便利です。

• Associated Domains Entitlement

<string>webcredentials:*.yahoo.co.jp?mode=developer</string>

独自仕様FIDOとパスキーの共存

独自仕様FIDOを利用中のすべてのユーザーが即座にパスキーへ移行できるわけではありません。また、iOS 16.4未満の端末を利用しているユーザーも多数存在します。

ユーザー体験を損なわないよう、再認証時には独自仕様FIDOとパスキーを共存させ、パスワードレスログインがこれまでどおりできる仕組みが必要でした。

今回はサーバー側とWeb側がWebAuthnに対応済みだったため、以下の機能が主な実装対象になります。

• 利用可能な認証方式に合わせ、独自仕様FIDOとパスキーのどちらかを発動させる
• パスキーが利用できない端末の場合は独自仕様FIDOを発動させる
• 独自仕様FIDOを利用しているユーザーに対してパスキーの登録を促す

SDKでは表のようにOSや登録状況に応じて認証方式を出し分けています。

OSバージョン鍵登録再認証

iOS 16.4未満独自仕様FIDO独自仕様FIDO

iOS 16.4以上同期パスキー独自仕様FIDO または 同期パスキー

従来のデバイス認証からパスキーへの移行を促す機能

独自仕様FIDOを利用中のユーザーのうち、パスキーに対応している端末の場合は、独自仕様FIDOによる再認証が成功したタイミングで専用の案内画面をWebViewで表示します。

パスキーの登録に成功すると、成功レスポンスをSDKがフックし、Keychainに「次回以降はパスキーを優先利用する」フラグが書き込まれ、以降は独自仕様FIDOではなくパスキーが優先されて発動するようになります。

これによりユーザーは特別な操作をする必要なく、より安全で便利なパスキーへシームレスに移行することができます。

SDKを介さずにパスキーを登録していた場合

上記の案内画面を介さず、ブラウザやアプリ内WebView上でパスキーを登録した場合、SDK側でパスキーの登録状況を検知することができません。

そのため、すでにパスキーを登録済みの状態でも、再認証時には引き続き独自仕様FIDOが優先して発動してしまいます。

この課題を解決するため、認証時にパスキーの利用を検知した際、SDK内の「次回以降はパスキーを優先利用する」フラグを最新の状態に更新することで、次回以降は自動的にパスキーが優先されるよう最適化を行っています。

フラグが更新されるタイミング画面説明

初回ログイン時image

• パスキーによる認証を行ったタイミングで更新
• ブラウザやアプリ内 WebView 上ですでにパスキーを登録済みの場合、ユーザーは意識することなくアプリもパスキー利用へ移行できます

独自仕様 FIDO による再認証時image

• 案内画面が必ず表示される
• 画面内でパスキーを登録したタイミングで「パスキーの認証を優先発動するフラグ」を更新
• すでにパスキーを登録済みのユーザーが登録を試みた場合は、登録済みであることを示すダイアログを表示する

パスキーへの移行実績

2025 年 7 月末頃から順次ヤフーの iOS アプリでパスキーが導入されています。

7 月末から 9 月にかけて「Yahoo!ショッピング」、「Yahoo!フリマ」、「Yahoo!オークション」といったアプリがパスキーに対応し始め、以降、対応アプリが増えるとともに独自仕様 FIDO による認証数が減少しています。

グラフのとおり、順調にパスキーへの移行が行われていることがわかりました。

以下の表は特定期間において 1 日あたりの独自仕様 FIDO とパスキーによる認証割合を示したものです。

パスキー対応前である 1 年前と比べ、1 年後にはヤフーの iOS アプリにおけるデバイス認証の全体の約 69％をパスキーが占める結果となりました。

認証方式2025 年 4 月末〜5 月2026 年 4 月

独自仕様 FIDO による認証数（1 日あたり）100％約31％

パスキーによる認証数（1 日あたり）0％約69％

2026 年 4 月には利用者数が特に多い「Yahoo! JAPAN アプリ」もパスキーに対応しました。今後さらにパスキーへの移行が進んでいく見込みです。

おわりに

本稿では、独自仕様の FIDO 認証から標準的なパスキーへと、ユーザー体験を損なわずに移行するための取り組みを紹介しました。

現在、パスキーに対応していないヤフーの iOS アプリも、アップデートを通じて順次パスキーが利用可能になる予定です。

今後も最新の技術動向をいち早く取り入れ、ユーザーの皆さまへより安全で便利な認証体験を提供できるよう努めていきます。