什麼是認證權杖
認證權杖是一則簽章聲明，用以表明請求來自真正的瀏覽器或裝置。裝置向其所屬平台證明自己，平台簽發一枚權杖，你的網站便收到這枚權杖，而不必要求使用者去解一道驗證碼。權杖不攜帶任何身分資訊，因此不會跨網站追蹤使用者。
在 Web 上，這建立於 Private Access Tokens 與 Privacy Pass（RFC 9576）之上。較新的延伸機制 PACT——Private Access Control Tokens——於 2026 年 6 月由 Cloudflare、Chrome、Firefox、Edge 與 Shopify 提出，旨在拓展這類權杖的簽發與使用方式。
其目標是讓真實使用者更常得以略過挑戰，同時讓驗證在設計上即保有隱私。
PACT 仍是早期提案，距離廣泛部署尚有數年。CaptchaLa 今日即支援既有的 Private Access Tokens / Privacy Pass 機制，並持續關注該提案的發展。這一切都不需要你等待。
CaptchaLa 如何運用它們
我們將認證權杖視為眾多信任訊號之一，而非整個決策本身。流程很簡單：
權杖已驗證，略過挑戰
若存在有效的認證權杖，我們會以簽發者的公鑰加以驗證。持有已驗證權杖的低風險訪客，可免互動挑戰直接通過。
回退至基於風險的驗證
若沒有權杖，或權杖無法驗證，CaptchaLa 會改用自有的風險引擎——裝置、網路與行為訊號——僅在請求看似可疑時才顯示挑戰。
適用情形：Web 與原生 App
裝置認證在各處並不一致。以下是哪些自動生效、哪些需要你自行設定的準確說明。
Web — Private Access Tokens / Privacy Pass
自動在 Web 上，CaptchaLa 會以簽發者的公鑰驗證 Private Access Tokens。你無須做任何設定——支援的瀏覽器與裝置會產生權杖，我們負責讀取。
iOS App Attest / Android Play Integrity
選用，需你自行設定這類原生認證綁定於你 App 自身的開發者身分，而非公開簽發者。它們只能作為你為自家 App 設定的選用訊號運作，因此並非對所有人自動生效。
其餘原生 App
我們自有的風險訊號在未設定平台認證之處，原生 App 依賴 CaptchaLa 自有的裝置與行為風險訊號——也就是保護 Web 回退路徑的同一套引擎。
裝置認證說的是「真實裝置」。我們再加上「真實且未濫用」。
裝置認證能確認請求來自真正的裝置，卻無法告訴你該裝置是否正被用來濫用你的服務。這道缺口正是 CaptchaLa 持久價值的所在——而且它不會因裝置認證上線而消失。
撞庫攻擊
用竊得的帳號密碼清單跑撞庫的真實裝置，在認證權杖看來依然是真實裝置。我們的風險引擎能識破這種模式。
代理與機器人農場
來自大量真實裝置的分散式濫用能通過裝置認證，卻無法通過行為與網路評分。
OTP 與註冊濫用
大量註冊帳號與一次性密碼農場都來自真實手機。我們評估的是意圖，而不只是裝置真偽。
詐欺與內容濫用
支付詐欺、垃圾訊息與有害上傳關乎行為，而裝置認證並不衡量行為——這正是我們的風險引擎與內容審核所衡量的。