前言

昨天介紹了 ROPC，說明為什麼 Client 不應直接取得使用者密碼。今天要看的 Passkey，則讓使用者不必輸入密碼，也能完成登入。

Day02 曾提過，Passkey 比密碼與 OTP 更安全。很多人以為這是因為 Passkey 會使用指紋或臉部辨識，但生物辨識只是用來解鎖裝置內的 Passkey，真正的核心是一組公開金鑰與私密金鑰。

登入時，服務端會送出每次都不同的 Challenge，裝置使用私密金鑰完成簽章，服務端再用公開金鑰檢查結果。由於私密金鑰不會被傳出去，之前的簽章也不能拿來重複登入，因此比密碼與 OTP 更能抵抗釣魚和重放攻擊。

本文會先介紹 Passkey 的註冊與登入流程，再比較它與密碼、靜態條碼及 TOTP 的差異，最後說明 Passkey 與 OpenID Connect、Device Authorization Grant 的關係。

今天內容涵蓋：

1. Passkey 跟密碼、OTP 最大的差別
2. Passkey 的註冊與登入流程
3. Passkey 與 FIDO2、WebAuthn、CTAP 的關係
4. Passkey 與密碼、靜態條碼、TOTP 的差異
5. Passkey 與 OpenID Connect、Device Authorization Grant 的分工

一、Passkey 跟密碼、OTP 最大的差別

登入的目的，是向服務端證明「目前操作的人有權使用這個帳號」。不同登入方式，最大的差別在於這份證明如何送到服務端。

• 密碼或靜態條碼： 使用者送出一個固定值。攻擊者只要取得這個值，通常就能直接冒用。
• TOTP 動態驗證碼： 驗證碼會定期更換，但使用者仍要把當下有效的數字輸入網站。攻擊者若透過釣魚網站取得驗證碼，仍可能在過期前立即使用。

因此，真正的問題不只是內容會不會改變，而是登入時送出的資料能不能被複製後拿去冒用。

Passkey 改用一組公開金鑰與私密金鑰完成驗證：

• 公開金鑰： 註冊時交給服務端保存，只能用來檢查簽章，不能拿來登入。
• 私密金鑰： 保存在使用者的裝置或受保護的 Passkey 環境中，不會傳送給服務端。

登入時，服務端先送出一個每次都不同的 Challenge，裝置使用私密金鑰對它簽章，再把簽章結果送回去。服務端用公開金鑰驗證成功後，就能確認使用者持有正確的私密金鑰。

由於每次登入使用的 Challenge 都不同，這次產生的簽章無法拿到下一次登入重複使用。簡單來說，密碼登入像是把鑰匙交出去檢查；Passkey 則像是用鑰匙完成一次簽名，鑰匙本身不必交出去。

二、Passkey 的註冊與登入流程

Passkey 必須先完成一次註冊，之後才能用來登入。這兩個流程可以簡單理解成：

• 註冊＝先把 Passkey 設定好： 裝置建立一組公開金鑰與私密金鑰。公開金鑰交給服務端記錄，私密金鑰則由裝置保管。
• 登入＝使用已設定好的 Passkey 驗證身分： 服務端送出一個每次都不同的 Challenge，裝置使用私密金鑰簽名，再由服務端使用公開金鑰檢查簽名是否正確。

圖中的 Relying Party 是提供登入功能的網站或服務；Authenticator 則是保存並使用 Passkey 的手機、電腦或安全金鑰。

流程中會反覆出現 Challenge。它是服務端在每次註冊或登入時臨時產生的一組隨機資料，裝置必須使用私密金鑰簽署這次的 Challenge，服務端才能確認裝置持有正確的私密金鑰。

Passkey 註冊流程

對照上圖，流程如下：

1. 開始註冊： 使用者在網站或 App 選擇建立 Passkey。
2. 建立註冊請求： 服務端產生一次性的 challenge，並回傳使用者資料與其他必要設定。
3. 建立金鑰： Authenticator 產生一組公開金鑰與私密金鑰。
4. 保存私密金鑰： 私密金鑰保存在受保護的 Passkey 環境中，不會交給服務端。
5. 回傳註冊資料： 裝置將公開金鑰與 credential ID 回傳給服務端。
6. 綁定帳號： 服務端將公開金鑰及 credential ID 記錄在使用者帳號下。
7. 完成註冊： 服務端確認資料保存成功，Passkey 即可用於後續登入。

圖中省略了瀏覽器或 App 的傳遞過程，實際上會透過 WebAuthn API 與 Authenticator 溝通。

Passkey 登入流程

對照上圖，流程如下：

1. 開始登入： 使用者選擇使用 Passkey。
2. 建立登入請求： 服務端產生一次性的 challenge，並回傳可使用的憑證資訊。
3. 本機確認： 裝置要求使用者透過生物辨識或 PIN 解鎖 Passkey。
4. 完成簽章： Authenticator 使用私密金鑰簽署 challenge。
5. 回傳驗證資料： 裝置將簽章結果（signed assertion）與 credential ID送回服務端。
6. 驗證簽章： 服務端依照 credential ID 找到公開金鑰，再驗證簽章及其他必要資訊。
7. 完成登入： 驗證成功後，服務端建立登入 Session 或回傳登入成功。

使用另一台手機上的 Passkey 登入

藍牙不是所有 Passkey 登入都必須使用。若 Passkey 已同步到目前的電腦，或電腦本身保存該 Passkey，使用者可以直接在本機完成驗證，不需要手機或藍牙。

只有在 Passkey 儲存在手機，並透過電腦顯示的 QR Code 進行標準跨裝置登入時，才會使用 FIDO Hybrid Transport。QR Code 用來建立加密通道，藍牙低功耗（BLE）則用來確認手機與電腦確實位於附近；手機完成本機驗證及簽章後，再將結果傳回電腦。

🧪 可以用 Google 帳號實際測試： 在電腦的 Google 登入頁面選擇使用 Passkey，再選擇使用其他手機或平板，電腦便會顯示 QR Code。掃描前可以先故意關閉手機的藍牙；掃描後，系統會提示開啟藍牙服務。開啟藍牙並完成手機上的指紋、臉部辨識或 PIN 驗證後，電腦才會繼續登入。這個測試可以直接看出，BLE 在跨裝置 Passkey 登入中負責確認手機與電腦位於附近。

從流程可以看出的安全重點

1. 私密金鑰不會交給服務端： 網路上傳送的是簽章結果，而不是可以直接拿來登入的私密金鑰。
2. 每次登入都使用新的 Challenge： 先前的簽章只對當次 Challenge 有效，無法拿到下一次登入重複使用。
3. 生物辨識只在本機使用： 指紋、臉部辨識與 PIN 的作用是解鎖 Passkey；生物特徵資料不會傳到服務端。
4. Passkey 會綁定服務網域： 瀏覽器與 Authenticator 會檢查網站身分，釣魚網站無法要求裝置使用其他網域的 Passkey。

此外，每個服務網域與帳號使用的 Passkey 憑證彼此獨立，因此不同服務無法直接用公開金鑰辨認同一位使用者。

三、Passkey 與 FIDO2、WebAuthn、CTAP 的關係

前面的流程說明了 Passkey「做了什麼」。實際運作時，網站、瀏覽器與 Authenticator 還需要依照共同標準交換資料，這套技術架構稱為 FIDO2，主要包含 WebAuthn 與 CTAP：

💡有些 Passkey 可以在使用者自己的多台裝置上使用。例如，假設你在 iPhone 上為某個網站建立 Passkey，並將它儲存在 iCloud Keychain。之後，只要你的 Mac 登入相同的 Apple 帳號並啟用 iCloud Keychain，這組 Passkey 就能同步到 Mac，讓你直接使用 Mac 的 Touch ID 登入同一個網站，不必重新建立 Passkey。同步過程會受到加密保護，網站仍然拿不到私密金鑰；登入時，網站收到的只有裝置產生的簽章結果。

四、Passkey 與密碼、靜態條碼、TOTP 的差異

密碼、靜態條碼、TOTP 與 Passkey 都可以用來確認登入者的身分，但它們交給服務端的資料不同，遭到竊取後的風險也不同。

比較這些方式時，重點不是資料屬於「靜態」還是「動態」，而是攻擊者取得登入資料後，能不能直接拿去完成登入。

💡Passkey 跨裝置登入時顯示的 QR Code 並不是登入憑證，而是讓正在登入網站的電腦，與保存 Passkey 的手機建立一次性的加密連線。真正用來證明身分的，仍然是裝置使用私密金鑰產生的簽章；後面再說明它與 Device Authorization Grant 的差異。

五、Passkey 與 OpenID Connect、Device Authorization Grant 的分工

Passkey、OpenID Connect（OIDC）與 Device Authorization Grant 分別解決不同問題，不是互相取代的登入方式。Passkey 負責讓使用者證明身分；OIDC 負責將登入結果交給應用系統；Device Authorization Grant 則讓輸入能力受限的裝置取得 Access Token。

與 OpenID Connect 的分工

當應用系統透過 OIDC 將使用者導向 IdP 登入時，IdP 可以要求使用者使用 Passkey 完成認證，再由 OIDC 把登入結果交回應用系統。

假設一個應用系統使用 OIDC 串接公司 IdP，並讓使用者用 Passkey 登入，流程如下：

1. 使用者在應用系統選擇登入，應用系統透過 OIDC 將使用者導向 IdP。
2. IdP 顯示登入畫面，要求使用者使用 Passkey 證明身分。
3. Passkey 驗證成功後，IdP 確認使用者是誰。
4. IdP 繼續執行 OIDC 流程，將 Authorization Code 交回應用系統。
5. 應用系統交換取得 ID Token，從中得知使用者的身分。

與 Device Authorization Grant 的分工

Device Authorization Grant 常用於 Smart TV 等輸入能力受限的裝置，讓使用者改在手機或電腦上完成登入與授權。它和 Passkey 跨裝置登入都可能顯示 QR Code，但兩者位於不同的協定層，QR Code 的用途也不同：

例如 Smart TV 可以透過 Device Flow，讓使用者改在手機瀏覽器完成登入；如果使用者在手機上選擇 Passkey，Passkey 負責證明使用者身分，Device Flow 則負責讓電視取得 Access Token。

小結

Passkey 的安全性核心是公開金鑰密碼學與 Challenge－簽章機制：

• 私密金鑰由裝置保護，服務端只保存公開金鑰與 credential ID。
• 每次登入使用新的 Challenge，舊簽章無法重複使用；網域綁定也能降低釣魚風險。
• 指紋、臉部辨識與 PIN 僅用於本機解鎖 Passkey。
• Passkey 負責使用者認證；OIDC 與 Device Authorization Grant 則處理身分結果傳遞或 Token 取得。

下一篇將進一步拆解 Passkey 背後的技術架構，說明 FIDO2、WebAuthn 與 CTAP 分別負責什麼，以及網站、瀏覽器／作業系統與 Authenticator 如何共同完成註冊與登入。

參考資源

• 為什麼 Passkey 安全：圖解「不傳送秘密的驗證」機制 - Comcomponent
• CodeLove｜Passkey 相關文章
• Passkeys: the promise of a simpler and safer alternative to passwords（PDF）- NCSC
• How Phishing-Resistant Authentication Works - LoginRadius
• Phishing-Resistant Authenticator Playbook - idmanagement.gov
• QR codes within enterprise security - Yubico
• WebAuthn Passkey QR Codes & Bluetooth: Hybrid Transport - Corbado
• Passkey vs 密碼 - Proton
• Common Developer Misconceptions About Passkeys - Auth0
• 通行密鑰（Passkey）是什麼？ - Auth Wiki
• TOTP 是什麼？ - Auth Wiki
• How Passkeys Work - Passkey Central