告別密碼煩惱：深入解析 WWDC25 Passkey 五大技術更新與實作指南

身份認證的「通行密鑰之旅 Passkey Journey」

身為開發者，我們長期在「使用者註冊摩擦力」與「帳戶安全性」之間尋求平衡。傳統的密碼與簡訊驗證碼（SMS）不僅是使用者體驗的絆腳石，更是網路釣魚（Phishing）攻擊的溫床。

Apple 在 WWDC25 明確提出了通行密鑰之旅（Passkey Journey）的概念：這是一個產業轉型過程，目標是將所有帳戶從依賴「可被釣魚的因素」（如密碼）遷移至完全由「不可被釣魚的因素」保護的狀態。根據 FIDO 聯盟 2025 年的調查，已有 69% 的使用者擁有至少一個 Passkey；Google 的數據顯示 Passkey 登入成功率比密碼高出 4 倍，而 TikTok 更觀察到高達 97% 的驚人成功率。Passkey 已不再是選配，而是現代 App 的標配。

全新 Account Creation API：實現「一鍵註冊」的極致體驗

在 iOS 26 與 macOS 26 中，Apple 推出了 Account Creation API，旨在消除註冊時的傳統表單障礙。

UX 對比：從手動表單到系統導引介面

• 傳統流程：使用者需手動輸入 Email、姓名，並面對「最強密碼」的聯想與確認，步驟繁瑣
• 全新流程：當使用者點擊「使用 Email 註冊」時，系統會彈出一個預填好的 Sheet。系統會自動從裝置資訊中帶入姓名與 Email
• 關鍵細節：這些預填資訊對使用者而言是可編輯的。使用者可以點擊欄位開啟選擇器（Picker）更換 Email 或手動修改姓名，這在提升效率的同時也保留了使用者的自主權

技術實作要點：

開發者應僅在確實需要帳戶姓名時才將 shouldRequestName 設為 true，以極小化資料蒐集的摩擦力。

import AuthenticationServices

// 初始化帳戶建立提供者
let provider = ASAuthorizationAccountCreationProvider()

// 建立 Passkey 註冊請求
let request = provider.createPlatformPublicKeyCredentialRegistrationRequest(
    acceptedContactIdentifiers: [.email], // 告知系統支援的識別碼類型
    shouldRequestName: true,              // 僅在必要時請求姓名
    relyingPartyIdentifier: "xcodeproj.blogspot.com",
    challenge: challengeFromServer,       // 來自伺服器的單次挑戰碼
    userID: internalUserID                // 伺服器端的穩定唯一識別碼
)

Signal API：確保憑證管理器的資料一致性

帳戶資訊並非靜態。當使用者在 App 內更改了 Email 或使用者名稱，若「密碼」App 內的標籤未同步更新，將導致下次登入時的混淆。

核心架構觀念：

我們必須理解，Passkey 的使用者名稱（Username）在本質上是一個本地端標籤（Local-only label）。在身份驗證過程中，這個標籤不會被回傳給伺服器。因此，透過 Signal API 更新標籤，純粹是為了優化使用者在憑證管理器中的視覺體驗。

全端實作支援：

• App 端：使用 ASCredentialUpdater 類別
• 網頁端：透過 WebAuthn 標準中的 signalCurrentUserDetails（Safari 19＋ 支援）

import AuthenticationServices

// 1. 更新使用者名稱標籤
ASCredentialUpdater.reportPublicKeyCredentialUpdate(
    for: credentialID,
    newUserName: "XcodeProject@xcodeproj.com"
)

// 2. 撤銷憑證：當使用者在後台刪除某個 Passkey 時，告知系統僅保留有效的 ID
// 這能防止無效的憑證出現在登入選項中
ASCredentialUpdater.reportAllAcceptedPublicKeyCredentials(validCredentialIDs)

自動化 Passkey 升級（Automatic Passkey Upgrades）

對於現有的密碼使用者，我們該如何引導他們轉向 Passkey？Apple 提供了「零摩擦」的自動升級路徑。

技術分析：

當使用者完成一次成功的密碼登入後，App 可以發起一個樣式設定為 conditional 的註冊請求。系統會在背景執行一系列靜默檢查（包括裝置是否支援 Passkey、是否剛使用過密碼等）。若條件滿足，系統會靜默建立 Passkey 並彈出通知告知使用者，全程不中斷使用者的操作流。

Passkey 管理端點（Management Endpoints）與導流

為了增加功能的「可發現性 Discoverability」，開發者可以在伺服器部署標準化的 .well-known/passkey-endpoints。

嚴格的實作規範：

這是許多開發者容易失敗的地方，請務必遵循以下 HTTP 要求：

1. 直接回應：必須直接從該路徑回傳，不可經過任何重新導向（No Redirects）
2. 狀態碼：必須回傳 200 OK
3. Content-Type：必須是 application/json

JSON 格式範例：

{
  "enroll": "https://xcodeproj.com/settings/passkeys/create",
  "manage": "https://xcodeproj.com/settings/passkeys"
}

當「密碼」App 偵測到此端點時，會在該帳戶旁顯示「提供 Passkey 升級」按鈕，直接將使用者導流至你的設定頁面。

憑證的自由遷移：導入與導出功能

使用者擁有自己的憑證，並有權選擇在哪裡管理它們。Apple 在新版 OS 中支持了與 FIDO 聯盟合作開發的新標準，允許 Passkey 在不同的憑證管理器之間進行安全遷移。

安全性躍進：

與過去匯出「未加密 CSV」這種極其危險的做法不同，新的遷移機制採用端到端加密，並需透過 Face ID 或 Touch ID 進行本地驗證。這是一個現代且安全的機制，確保憑證在傳輸過程中絕不落地。

實作細節：錯誤處理與最佳實踐

在實作 Account Creation API 時，妥善處理錯誤是確保 UX 連貫性的關鍵：

進階 tip：組合式登入請求（Combined Sign-in Request）

為了達到像 Shiny App 在 iPad 上「一啟動就提示登入」的流暢感，建議在 App 啟動時發起一個包含 prefer immediately available credentials 選項的組合式請求。這會同時檢查 Passkey、密碼與 Sign in with Apple，若有可用憑證則立即提示，若無則靜默不干擾介面。

邁向無密碼的未來

2025 年的技術更新標誌著我們進入了「從首日開始即無密碼」的新階段。透過 Account Creation API 降低進入門檻、Signal API 維持一致性，以及自動化升級機制，我們正攜手終結易受攻擊的密碼時代。

身為技術實踐者，我建議各位立即審視 App 的身分驗證架構。當註冊不再需要填寫繁瑣表單、登入不再需要記憶密碼時，你的產品將獲得無可比擬的競爭優勢。你的 App 準備好加入這場無密碼革命了嗎？