先從門口驗身分開始
這篇先不要急著背 Credential、Authentication、Authorization 這些名詞。你先想像自己站在安全實驗室門口，跟守衛說：我是 MY，我可以進去。守衛真正要問的是：你有什麼證明？
Credential 就是你拿出的證明。Authentication 是系統檢查這份證明是真的。Authorization 是通過檢查之後，系統決定你可以進哪裡、能做什麼。三件事分開看，後面的密碼、Passkey、Token、Certificate 就會清楚很多。
左側目錄是閱讀地圖。先用前幾張圖把門口驗證的故事看懂，再往下看私鑰、公鑰、憑證、裝置身分與 Attestation。每張圖下面的文字會把比喻接回真正的工程設計。
MY 站在實驗室門口，說自己有權進去。守衛還是要看證明。員工卡、密碼、Passkey 或裝置簽章，都可能成為這份證明。Credential 常譯成「憑證」或「認證資訊」；在這一課，它指的是支持某個主張、可供系統檢查的證明。
你說「我是 MY」、「我可以進這個實驗室」、「這台裝置是原廠出貨」，系統不會因為你開口就相信。它需要看到某種證明，接著驗證這個證明是真的，最後才決定你能做什麼。這篇用 12 張漫畫，從最直覺的密碼一路講到私鑰、公鑰、憑證、Token、裝置身分與 Attestation。
守衛要做三件事：看你提出什麼證明，檢查證明，再查你能進哪一區。對應的名稱是 Credential、Authentication 與 Authorization。通過前一關，不會自動取得後一關的所有權限。
P1｜Credential 是什麼：用來支持主張的證明
第一頁先把 Credential 放回日常情境：你站在門口，說自己是工程師、可以進安全實驗室。守衛不會只聽你說，會要求你拿出證明。這張證明可能是員工卡、手機 Passkey、安全金鑰、密碼、數位憑證，甚至是裝置內部的晶片金鑰。
所以 Credential 的重點不是「它長什麼樣子」，而是「它支撐了哪個主張」。密碼支撐「我知道這個秘密」，員工卡支撐「我持有公司發的卡」，私鑰簽章支撐「我真的握有那把私鑰」，憑證支撐「這把公鑰屬於某個人、網站或裝置」。
這也解釋了為什麼 Credential 不能只看方便性。越重要的門，系統越不能只問一句「你是誰？」就放人。它要看證明能不能被驗證、能不能被偽造、被偷走後會造成多大損失。
P2｜證明、檢查、放行，不是同一件事
很多安全問題，都是因為把三件事混在一起。Credential 是你拿出來的東西，例如密碼、Passkey、憑證或安全金鑰。Authentication 是系統檢查這個東西對不對，例如比對密碼、驗證簽章、檢查憑證是否有效。Authorization 則是通過檢查後，系統決定你能進哪裡、能不能改設定、能不能讀資料。
遊樂園的例子很直覺：票是 Credential，驗票是 Authentication，能進一般區、互動體驗區或 VIP 區，才是 Authorization。驗票成功不代表全園區都能進，只代表「這張票是真的」。你能進哪一區，還要看票種、身分、時間與權限設定。
在網站、雲端服務與裝置安全裡也是一樣。登入成功只代表身分驗證通過，不代表你應該拿到管理員權限。好的系統會把「你是誰」和「你可以做什麼」分開處理，這樣權限才不會越給越大。
P3｜說出秘密很簡單，也最容易出事
最簡單的驗證方式，是你直接說出秘密。門口問通關密語，你答對就進去。密碼登入也是這個概念：系統檢查你輸入的秘密，和它保存或推導出的資料是否吻合。
問題是，只要秘密在傳輸、輸入或儲存過程被偷走，攻擊者就可能假裝成你。鍵盤側錄、釣魚網站、惡意 App、資料庫外洩、log 誤記錄，都會把「知道秘密」變成「拿到秘密的人都可以冒充」。
密碼登入必須處理這些外洩途徑，不能只要求使用者換一個更複雜的字串。釣魚抵抗型的驗證器可以減少把可重用祕密交給假網站的風險；具體保證仍取決於協定、裝置保護與帳號復原流程。系統要依自己的風險選擇驗證方式。
P4｜不交出秘密，也能證明你知道秘密
Challenge-Response 讓系統送出新 challenge，例如足夠長、難預測的 nonce。裝置用祕密產生 response，驗證端檢查回應與本次 challenge。送出去的是計算結果，祕密本身留在裝置裡。
若驗證端確實產生新 challenge，並檢查回應綁定的 challenge、服務與協定情境，舊回應就不能原樣回答新題目。需要單次使用的流程，還必須記錄 challenge 已消耗。只把欄位叫做 nonce，卻重複出題或漏掉檢查，沒有這個保證。
驗證端藉此確認對方能為指定情境產生合格回應。這個思路會出現在私鑰簽章、Passkey 與裝置認證，但各協定的綁定內容與安全條件不同。回應驗證通過後，服務仍要另外檢查操作權限。
P5｜Password 和真正的 Key 差在哪裡
密碼和密碼學金鑰常被混在一起，但安全強度差很多。Password 通常短、可記憶、帶有人類習慣，所以容易被猜、被字典攻擊、被重複使用。Cryptographic Key 則應該是長、隨機、難預測，適合拿來簽章、加密或產生驗證碼。
有時候系統會用適合密碼的 KDF，配合 salt 與計算成本，推導驗證資料或金鑰。Salt 限制預先計算與跨帳號共用猜測結果；計算成本讓每次猜測付出更多代價。這些設計不會憑空增加原始密碼的熵，弱密碼仍可能遭離線猜測。一般用途的快速 KDF 也不能直接當成抗密碼猜測的保證。
所以工程上常見的分工是：Password 是人記得住的入口，Random Key 或硬體保護的私鑰才適合當真正的安全根基。能用 Passkey、硬體安全金鑰或裝置內私鑰時，通常比只靠密碼更穩。
P6｜私鑰留在手上，送出去的是簽章
非對稱認證讓裝置保留私鑰，驗證端只需公鑰。裝置簽署 challenge 與協定要求的情境，驗證端用公鑰檢查。在適當參數與正確實作下，合格簽章提供對應私鑰被使用的證據；它還沒有單獨回答這把公鑰屬於誰。
伺服器不必保存使用者的私鑰，降低了驗證端資料外洩時直接取得私鑰的風險。公鑰反推私鑰的難度仍依賴演算法與參數。新 challenge 可以擋下原樣重放，但驗證端必須實際核對它。若私鑰被偷，攻擊者也能簽；若公鑰來源不可信，驗證端可能從一開始就信錯人。
Passkey、FIDO 安全金鑰、裝置認證與 Secure Boot 都會使用非對稱密碼學，但金鑰保管方式不同。Passkey 可以是裝置綁定型，也可以透過受保護的同步機制備份到其他裝置。驗證伺服器不需要私鑰，不代表所有 Passkey 私鑰都永遠不離開同一硬體；還要評估同步、備份與帳號復原邊界。
P7｜Certificate 把公鑰和身分綁在一起
有公鑰還不夠。問題是：這把公鑰到底屬於誰？如果每台伺服器都說「這是我的公鑰」，使用者仍然不知道哪一把是真的。Certificate 的角色，就是把身分資訊、公鑰、用途、有效期限與簽發者簽章綁在一起。
網站 HTTPS 憑證就是一個例子。驗證端要檢查通往本機信任錨點的路徑、服務名稱、有效期與用途等條件。撤銷處理則取決於平台與政策，不能假設所有瀏覽器都逐次查完所有撤銷來源。憑證簽章有效，也不能替錯誤網域名稱放行。
裝置憑證也類似。製造商或 CA 可以替裝置簽發憑證，證明這把公鑰屬於某台裝置、某個型號或某個安全元件。系統因此不只驗簽，還知道這個簽章應該信到什麼程度。
P8｜Token 是短期入場券，不是永久身分證
Token 常出現在登入後。你先用密碼、Passkey 或憑證證明自己，系統驗證通過後，發給你一張短期入場券。之後你拿這張 Token 去存取服務，不需要每次重新拿原始 Credential 出來。
服務可以限制 Token 的期限、受眾與操作範圍。OAuth Access Token、Session Cookie 與 JWT 可能出現在這條路徑，但用途與驗證方式不同。期限、撤銷與輪替必須由發行端及使用端共同落實；尤其自包含 Token 的即時撤銷，不會因為格式叫 JWT 就自動存在。
但 Token 也要保護好，尤其是 Bearer Token。Bearer 的意思很直接：誰持有它，誰就能用它。這也是為什麼 Token 要走 HTTPS、期限不能太長、權限不能太大，前端儲存位置也要小心。
P9｜Credential 住在哪裡，安全等級就不同
安全不只看演算法，也看秘密住在哪裡。把金鑰放在普通檔案裡很方便，但如果檔案權限、備份、log 或惡意程式沒管好，就容易被讀走。OTP 或 eFuse 適合放固定 Root Data，但寫入後不容易改。Secure Element、TPM、HSM 則把金鑰與運算放進受保護的環境，降低外流風險。
PUF 則更特別：它不一定直接保存完整金鑰，而是利用晶片本身的物理差異，在需要時重建或導出 Root Key。這對抗「靜態金鑰被讀出」很有價值，但也需要錯誤校正、穩定性設計與安全封裝一起配合。
所以問「用了什麼演算法」還不夠。還要問：金鑰在哪裡產生？在哪裡使用？會不會離開安全邊界？有沒有被備份、複製、匯出或搬移的路徑？很多安全事故不是演算法壞掉，而是 Credential 放錯地方。
P10｜Device Identity：每台裝置都該有自己的名字
人需要身分，裝置也需要。Device Identity 用來回答「我是哪一台裝置」。它通常會結合唯一識別碼、裝置金鑰與裝置憑證，讓伺服器或驗證者可以分辨不同裝置。
如果一萬台裝置共用同一把秘密，只要其中一台被破解，整批裝置都可能受影響。好的 Device Credential 應該每台唯一、不容易複製、能追溯來源，出事時也能撤銷或隔離。
這在 IoT、車用、工業控制、雲端邊緣設備都很重要。系統不只要知道「有人登入」，還要知道「是哪台設備在連線」。人、裝置、服務帳號都應該有清楚邊界。
P11｜Attestation：不只問你是誰，也問你現在可不可信
Device Identity 說明裝置是誰，但這還不夠。裝置可能是真的，韌體卻被改過；裝置可能是原廠出貨，Debug 介面卻被打開；金鑰可能還在，系統狀態卻已經不安全。
Attestation 要回答的是「這台裝置現在處於什麼狀態」。常見證據包括韌體雜湊、Secure Boot 狀態、安全版本、Debug 狀態、設定值、錯誤或健康資訊。驗證者根據這些證據，決定要不要信任這台裝置。
驗證者還需要可信證據來源、freshness 檢查、參考值與服務政策。新 nonce 綁定這次回應，不代表每一項量測都剛剛發生，也不能凍結之後的執行狀態。設備即使通過評估，服務仍須按風險限制操作；身分與狀態證據都不能取代授權。
P12｜總結：小小 Credential，大大保護
Credential 可以是密碼、Passkey、Token、Session、API Key、私鑰、憑證或裝置身分。它們形式不同，但都在做同一件事：幫你支持某個主張，讓系統有理由相信你。
PUF 可以在裝置 credential 背後，支援根材料的重建或保護。服務通常驗證的是由它支援的金鑰證明、憑證或 attestation evidence。不能只看到「物理來源」就直接放行；根材料保護與上層證明的檢查，各有自己的條件。
真正的安全不是把所有東西都叫「憑證」就結束，而是分清楚它們的角色。原始 Credential 用來證明身分，Token 用來短期代表你，Certificate 用來把公鑰和身分綁在一起，Attestation 用來補上現在狀態是否可信。
回到門口，守衛需要知道證明由誰發出、怎麼檢查，以及失竊後如何撤銷或更換。祕密要妥善保存，期限與更新要依 credential 類型安排，權限則只給本次需要的範圍。這些規則必須在實際驗證和存取路徑裡生效，不能只寫在管理文件上。
Hashtags
#Credential #Authentication #Authorization #Token #Session #Passkey #Certificate #DeviceIdentity #Attestation #PublicKey #PrivateKey #KeyManagement #HardwareSecurity #Cybersecurity #ZeroTrust #身分驗證 #授權 #憑證 #裝置身分 #硬體安全 #漫畫小教室
References
- NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
- OWASP Authentication Cheat Sheet
- OWASP Session Management Cheat Sheet
- RFC 6749: The OAuth 2.0 Authorization Framework
- RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC 7519: JSON Web Token (JWT)
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- W3C Web Authentication: An API for accessing Public Key Credentials
- FIDO Alliance: Passkeys
- RFC 9334: Remote ATtestation procedureS (RATS) Architecture
一份證明，過了驗證就能放行嗎？
先走完正常登入，再只取消操作權限。接著載入「重放舊回應」：MAC 仍正確，新 challenge 卻不同。最後改服務名稱，比較內容綁定失敗與 freshness 失敗。
瀏覽器真的產生隨機 nonce 與 HMAC-SHA-256。雙方在本頁共用一次性教學金鑰；它不是 Passkey、WebAuthn 或完整登入協定。服務名稱、單次 challenge 與授權檢查只示範一種明確流程。每次載入都是新實驗，請勿輸入祕密。