Passkeys + Magic Links：DHH 心中「正確形狀」的認證組合
DHH 對 passkeys 的看法大轉彎：從「問題比密碼還多、整套拆掉」到「passkeys 配 magic links 才是大多數應用的正確形狀」。本文整理他在 On Rails podcast 的論點、passkeys 與 magic links 的分工、以及 Rails 端到端原生支援的規劃。
Passkeys + Magic Links：DHH 心中「正確形狀」的認證組合
摘要
在 On Rails podcast 上，DHH 談到他對 passkeys（通行金鑰） 的看法做了一次大轉彎。
他早先在 HEY 部落格發過一篇〈Passwords have problems, but passkeys have more〉，
直言 passkeys 問題比密碼還多，37signals 甚至把原本「純 passkeys」的登入機制整套拆掉。
但後來他找到一個關鍵突破：不要用 passkeys 取代密碼，而是把 passkeys 和 magic links 配成一對。
他現在認為，對絕大多數應用來說，認證的「正確形狀（right shape）」就是這麼簡單一句話：
「他們只要有 Magic Links 和 Passkeys 就好。就這樣。」（"They should simply just have Magic Links and Passkeys. That's it."）
而且這兩者都會被做進 Rails 的端到端原生支援裡——passkey 的 PR 已經開出來了，目標是 2026 年 9 月的 Rails World。
背景：DHH 為什麼一度否定 passkeys
DHH 在 HEY 的文章裡列出 passkeys 的幾個現實痛點：
- 平台綁定（platform lock-in）：passkey 會以使用者不易察覺的方式綁在特定裝置上。 例如用 Windows 上的 Chrome 註冊，金鑰存進 Windows Hello；換到 iPhone 就登不進去， 除非事先在 iPhone 上也建一把——但大多數人不會這麼做。
- 跨裝置失敗：就算在同生態系（iPhone + Mac 透過 iCloud Keychain）內順暢， 一旦要在「朋友的電腦」上登入就卡關，帳號被鎖在外的風險很高。
- 變通方案笨重：用 QR code 掃描跨裝置登入，對多數人來說「笨重又陌生」。 他講了個反諷：如果你要教使用者搞懂這一整套，那「幾乎不如直接教他用一個跨平台的密碼管理器」。
- 後端實作成本高：除了使用者卡關，後端處理 passkeys「複雜到出乎意料」， 代價高卻看不到明確好處。
結論是：37signals 一開始做了「純 passkeys」的認證，最後拆掉，因為「使用者體驗就是有點爛」。
轉折：把 passkeys 和 magic links 配成一對
DHH 在 podcast 上說明他改變看法的關鍵：
「我對 passkeys 的第一個看法是，它們會整個取代密碼。我看到很多可用性問題……
但讓我真正接受 passkeys 的突破是——獨立來看不行，就把它和 Magic Links 配對，
你永遠可以透過 email 登入。」
重點不在 passkeys 本身，而在搭配方式：
- Passkey 負責「在已啟用的裝置上快速、無摩擦地登入」。
- Magic Link 是永遠存在的後備路徑——只要能收 email，在任何裝置、任何瀏覽器都能登入。
這樣一來，passkeys 原本最致命的「換裝置就被鎖在外」問題就被 magic link 接住了。
DHH 認為這個組合「對大多數應用來說就是認證的正確形狀」，
甚至連社群登入（social login）都可以不要：「如果能擺脫 social logins，那更好。」
Passkeys vs Magic Links：兩種無密碼方式的分工
| 面向 | Passkeys（WebAuthn / FIDO2） | Magic Links（email 連結） |
|---|---|---|
| 原理 | 裝置上的私鑰對伺服器的 challenge 做密碼學簽章 | 寄一條一次性登入連結到信箱 |
| 防釣魚 | 強：金鑰綁定網域，天生抗釣魚 | 弱：安全性等同於該 email 帳號本身的安全 |
| 使用體驗 | 不用開信箱，本機生物辨識即可，最快 | 要切換到信箱 App / 分頁，多一步 |
| 跨裝置 | 痛點所在（綁裝置） | 強項：能收信就能登入 |
| 適合情境 | 高頻、高安全、已啟用裝置的回訪使用者 | 新使用者、未啟用裝置、低頻登入 |
2026 年業界的主流做法，正好呼應 DHH 的判斷：
passkeys 當回訪老使用者在已啟用裝置上的主路徑，magic links 當新使用者與未啟用裝置的主路徑，
social login 則作為可選的加速捷徑。
flowchart TD
A["使用者要登入"] --> B{"這台裝置<br/>有 passkey 嗎？"}
B -- "有" --> C["WebAuthn 挑戰-簽章<br/>生物辨識，秒登入"]
B -- "沒有 / 換新裝置" --> D["寄出 Magic Link<br/>到 email"]
D --> E["點信中連結<br/>完成登入"]
E --> F["可順手在這台裝置<br/>建立新的 passkey"]
F --> C
C --> G["登入成功"]
E --> G
為什麼這對 Rails 生態很重要
DHH 觀察到一個他覺得「很瘋狂」的現象：很多開發者寧可把整個登入外包給認證 SaaS，
不是因為功能不夠，而是純粹對「自己實作認證」感到不安、被嚇到。
他想用 Rails 解決這個心理門檻：
- 已經有一個 open PR 要把 passkey 支援端到端做進 Rails。
- passkeys 的點子其實很簡單，但那段「JavaScript 之舞（the JavaScript dance）」很微妙、有點 tricky—— 要把 WebAuthn 的 ceremony 做對並不容易。
- 由框架來扛起這段細緻的儀式，包裝成「任何人都能在登入頁直接插上」的乾淨 API， 就能把門檻「降到低得人人都能玩」。
這延續了 Rails 既有的方向：Rails 8 已內建基本的 authentication generator（產生 session/密碼骨架），
而 passkeys + magic links 會是下一批要「打磨好、包裝成禮物」端上 2026 年 9 月 Rails World 的功能。
一個延伸問題：agents 怎麼登入？
訪談中也被問到：如果應用裡要讓 AI agents 擁有自己的帳號，
passkeys 這種綁實體裝置 / 生物辨識的機制要怎麼套用到沒有「人」與「裝置」的 agent 上？
DHH 坦言「這個還完全沒有定論」，並提醒在 agent 領域變動極快的此刻，
不該太早把框架的「地基混凝土」灌死。這是一個開放、尚待解決的架構問題。
小結
- DHH 的立場演變：從「passkeys 問題比密碼多、整套拆掉」→「passkeys 配 magic links 才是正解」。
- 關鍵不是技術選型，而是搭配：passkey 給速度，magic link 給永遠可用的後備。
- 兩者都會成為 Rails 的原生、端到端能力，目標是讓開發者不必再把認證外包出去。
- 對 AI agent 的認證，目前仍是未解的開放題。