用通行密鑰（Passkey）設計無密碼登入體驗：使用流程、UI/UX設計個案研究、設計資源

無論是登入網站、服務，都需要建立一組帳號密碼。然而，隨著使用的服務越來越多，要記住的帳密也跟著越來越多。為了解決帳號容易被盜用、但現代人又懶得管理密碼的困擾，由Apple、Google、Microsoft等大企業所共同推動的FIDO聯盟推出了一種更新、更方便、更安全的驗證方式——通行密鑰（Passkey）。只需解鎖手機/電腦，就可神奇地登入網站或服務，完全不需要輸入密碼。

通行密鑰的原理

既然用通行密鑰登入不需要輸入密碼，那麼，網站或服務是怎麼識別不同使用者的呢？簡單來說就是：

1. 當你註冊時，你的裝置（例如手機/平板）會為這個網站/服務產生一組「准考證」與對應的「答案」並儲存起來。另外，這張「准考證」也會留一份在網站/服務那裡。
2. 當你下次登入時，網站/服務會詢問你的裝置有沒有「准考證」。如果雙方都有且一致，就證明了你曾經註冊過。
3. 接下來，網站/服務會送一張神奇考卷給你的裝置，這份考卷只有使用在第1步建立的「答案」才能解開，且作答完成以後，分數會自動出現。但是，要讓裝置填寫「答案」，你需要再解鎖裝置一次。
4. 你的裝置只會把考試分數傳回網站/服務。對方看到成績如果全對，就會知道你手中有正確的「答案」，可以讓你登入；反之則不行。

採用通行密鑰的好處

對於使用者而言

1. 無需再記憶密碼，同時卻擁有更加安全的登入方式

對於網站/服務而言

1. 確保資料外洩時，不會令使用者的帳號安全受到影響
2. 避開使用兩步驟驗證所產生的額外成本
3. 由於通行密鑰更加簡單，因此可預期使用者登入成功的比率提升

UX設計建議

將「通行密鑰設定」設計於帳戶安全操作相關的流程中

通行密鑰屬於和帳戶安全性相關的功能，使用者預期該功能會在與帳戶相關的流程中出現（例如：註冊帳戶、管理帳戶、恢復帳戶）。不要將其放置於其他核心任務的流程中。

用已知的熟悉概念向使用者介紹通行密鑰

通行密鑰是相對新興的科技。盡可能地利用使用者已熟悉的概念來介紹通行密鑰的概念、用途、益處。

在系統對話框觸發前/後，設計清楚的訊息指示

在系統對話框觸發通行密鑰前，使用相關的Icon、文字訊息來告訴使用者即將開始通行密鑰驗證；完成驗證後，使用清楚的訊息告知使用者登入為成功或失敗。

讓使用者自行決定是否建立通行密鑰

讓使用者自行決定是否要建立通行密鑰。在忘記密碼流程中，讓使用者選擇是要建立一組新密碼，還是要建立通行密鑰。而在管理通行密鑰方面，提供清晰的選項讓使用者建立/管理它們。

考慮網頁可及性

在設計通行密鑰體驗時，確保所有用到的元素、底層技術皆考慮了各種使用者的需求。具體可參考WCAG或由Passkey Central提供的額外規範白皮書、專屬頁面。

在產品中使用統一的視覺區塊

為通行密鑰功能設計視覺區塊（包含Icon、標題、文字、CTA），並確保整個使用流程中保持一致。

讓通行密鑰相關概念說明持續保持可見

無論使用者是否建立了通行密鑰，相關說明訊息應持續在介面中清楚可見。這是因為使用者需要知道通行密鑰是什麼、建立後會發生什麼、刪除後會發生什麼等種種疑問。

讓通行密鑰作為主要登入選項

「使用通行密鑰」選項的外觀應和使用密碼、兩步驟驗證等選項的外觀相同、不被弱化。

以UI卡片呈現每把通行密鑰

由於通行密鑰不像密碼，使用者可清楚看見裡頭的內容物是什麼，因此建議以「卡片」形式呈現每把通行密鑰，並在其中顯示與之相關的重要訊息，例如：名稱、建立日期、最後使用的日期。

設計資源

1. FIDO聯盟提供了Passkey Figma UI範本，裡頭包含在iOS、Android、macOS、Windows、瀏覽器等觸發通行密鑰時，會出現的系統對話框。前往範本
2. FIDO聯盟提供了通行密鑰體驗Prototype。前往範本
3. FIDO聯盟提供了通行密鑰Icon可供下載用於相關用途，前往頁面。儘管如此，Apple和Google也各自設計了自家版本的Icon用於系統中。
4. Android開發者說明文件中，提供了一些視覺化的頁面設計範例可供參考。前往頁面

Case Study

X（Twitter）

「建立通行密鑰」選項通常位於設定中的「帳戶」或「安全性與隱私權」等類似名稱的頁面中。以X為例，該選項位於設定→安全性內。

由於此類操作涉及帳戶安全，因此系統會再度要求使用者輸入密碼以確認身份。在建立通行密鑰前，系統通常會有一個頁面告訴使用者通行密鑰是什麼，以及啟用它可以帶來什麼益處。點擊頁面下方按鈕，會觸發系統級對話框，詢問用戶要將通行密鑰儲存在哪裡。因為通行密鑰是系統級別的功能，因此App端不需要設計此畫面（除非你設計的是密碼管理App）。

通行密鑰儲存完成後，此時流程回到App中，因此App具有責任需明確告訴使用者通行密鑰已製作完成。

Notion

Notion的整體通行金鑰製作流程與前面舉例的X大同小異。不過，Notion支援建立多把通行金鑰，因此多了管理畫面。在管理畫面中，應該要顯示每把金鑰的名稱（由用戶定義）、建立日期以協助用戶區別不同的金鑰。

Google

在電腦上使用通行密鑰登入時，輸入帳戶後系統級對話框會自動彈出，詢問使用者是否要以通行密鑰登入。（在Google服務中，所有設定了通行密鑰的帳戶預設會改以通行密鑰而非密碼登入。因此輸入帳號後，Google才會直接觸發系統對話框而非詢問輸入密碼）

iCloud

在電腦端登入網頁版iCloud時，可選擇以密碼或是通行密鑰登入。選擇以通行密鑰登入，網頁會觸發瀏覽器的對話框，提示使用者以支援的裝置掃描QR code並登入。

其他細節

在成功以密碼金鑰登入、成功建立密碼金鑰等帳戶安全性出現變更的時機，寄送Email以提示使用者（前述的X/Notion/iCloud皆有寄送Email）

重要概念

1. 通行密鑰不是Apple/Google或任何一家公司專有的技術

儘管通行密鑰這項技術因深度整合於iOS/Android系統內而時常被使用者誤會，但這項技術並不專屬於Apple、Google或任何一家公司。它是由FIDO（Fast IDentity Online）聯盟所推動的開放標準，而Apple、Google等大公司只是這個聯盟的成員而已。

2. 通行密鑰可同步於使用者的所有裝置中

舉例來說，在iPhone上建立的通行密鑰可透過iCloud同步至該使用者的所有Apple裝置中；而Android方面則可透過Chrome中的Google Password Manager，在登入同一Google帳戶的裝置中同步。

3. 使用者可選擇通行密鑰的儲存位置

現在有許多系統、App皆支援儲存通行密鑰，常見舉例如下。注意，通行金鑰的跨裝置同步功能是由儲存的位置決定。例如若你選擇將通行金鑰儲存於iCloud，那麼這把金鑰就無法直接在Android裝置上使用，因為Android裝置沒有整合iCloud。不過，通行密鑰同時提供了跨裝置解鎖功能，具體請看第5點。

• iOS/macOS（透過iCloud）
• Android（透過Google Password Manager）
• Windows
• Chrome、Edge、Firefox（透過各自帳戶同步）
• 1Password、Bitwarden等密碼管理工具
• Samsung Pass等手機廠商內建專屬工具

4. 在iOS/Android裝置上使用通行密鑰的最低技術環境要求

• iOS：iOS 16 及後續版本
• Android：Android 9 及後續版本

5. 使用者可用存有通行密鑰的裝置A，解鎖裝置B上的登入請求

當使用者在沒有儲存通行密鑰的裝置上嘗試登入時，系統會顯示一個QR code，使用有儲存通行密鑰的裝置掃描該QR code並解鎖手機，一樣可完成登入。然而要使用此功能，兩裝置都必須支援藍牙且物理距離接近。

延伸閱讀

• Passkey Centeral: UX Principles and content principles for passkey
• Android Developers: Auth with passkeys
• Chrome for Developers: Understand passkeys in 4 minutes
• Google Identity: Passwordless login with passkeys
• Google Identity: Passkeys user journeys