託管身分驗證

這是什麼

託管身分驗證就是你應用程式的登入系統：註冊、登入、密碼重設、工作階段，以及讓每個使用者只能存取該看到的資料。在 ybuild 上，它被內建進每一個需要它的應用程式，使用者因此得到真正的帳戶，而你完全不用碰任何安全性程式碼。角色與權限會直接依你的描述設定好。

為什麼重要

一旦你的系統有了客戶、員工或會員，它就必須分清誰是誰，並把每個人的資料彼此隔離、妥善保護。身分驗證做錯了，不是外洩資料，就是把人擋在門外——無論哪一種都會摧毀顧客對這門生意的信任。把它交給平台託管、做正確，才能讓這套系統安全地交到真實使用者手裡。

在 ybuild 上怎麼用

描述誰來登入、他們能看到什麼，ybuild 就會把帳戶、工作階段與權限建進這個正在運作的應用程式裡。它託管在 ybuild 上，並透過你自己的網域對外提供服務，所以使用者是在你的網址上登入，而不是某個第三方入口網站。敏感的憑證由平台負責儲存與保護，不需要你手動管理。

ybuild 會把哪些東西接進你的登入系統

當你描述誰來登入時，ybuild 會打造完整的帳戶生命週期——註冊表單、登入、透過電子郵件重設密碼，以及讓使用者在應用程式裡四處走動時保持登入狀態的工作階段。這每一個步驟背後，都藏著一大堆很容易在細節上出錯的安全性細節。密碼絕不會以使用者輸入時的原樣被儲存：平台會讓每個密碼經過一次緩慢、加鹽的單向雜湊——正是 OWASP 明確規定的做法，使用 Argon2id 或 bcrypt——這樣即使資料庫有朝一日被外洩，裡面也沒有明文密碼可拿。NIST 的現行指引同樣形塑了登入所強制執行的規則：允許最長 64 個字元的長通行密語，捨棄那套只會逼出 Password1! 的老舊「必須包含符號」組合規則，並把新密碼與已知的外洩密碼清單比對，而不是強制進行毫無意義的定期重設。

一旦有人登入，工作階段就會讓他們保持在登入狀態，而不必每點一次都重新輸入密碼。ybuild 透過 HTTPS 發出這個工作階段，在登入的那一刻重新產生工作階段識別碼，好讓舊的識別碼無法被重放，並讓它在閒置逾時與絕對存活時間兩個面向上都會到期——這正是 OWASP 記載在案的工作階段衛生規範。登出會在伺服器端讓工作階段失效，而不只是關掉瀏覽器分頁而已。正是這些小細節，決定了一個帳戶會不會被挾持，而平台會替你處理好它們，而不是把它們當成一份留給你的檢查清單。

身分驗證不只是「這個人有沒有登入」——更是「這個具體的人被允許看到什麼」。當你告訴 ybuild：客戶只看自己的紀錄、員工看自己經手的全部案件、而擁有者看得到一切，它就會打造出這些角色，並在每一次讀取與寫入時強制執行，這樣一個客戶絕不可能靠改一改 URL 裡的某個數字，就叫出另一個客戶的資料。這種針對每個使用者的隔離，是依你的描述接進去的，運作在 ybuild 上，並透過你自己的網域對外提供服務。

自己打造身分驗證，還是在 ybuild 上直接取得它

一個登入表單看起來像一個下午就能做完的活，結果卻變成要花上一整季的工程。看得見的部分——一個電子郵件欄位、一個密碼欄位、一個送出按鈕——微不足道。真正的系統是它背後的一切：正確地對密碼做雜湊與加鹽、產生密碼重設權杖並讓它到期、真正把重設郵件寄出去、儲存工作階段、在登出與變更密碼時讓工作階段失效、對失敗的嘗試進行速率限制，以及在生意有需要時加上第二道驗證因子。每一塊都有一種被明確記載下來的正確做法，和十來種無聲無息的錯誤做法，而這些錯誤做法並不會拋出錯誤——它們只是留下一個破洞。

這些陷阱非常具體。NIST 要求有一套速率限制機制，把同一帳戶連續失敗的嘗試次數上限設在不超過 100 次，正是因為攻擊者不會去猜某一個密碼——他們會拿數以百萬計被竊的密碼輪番重放。Verizon 2025 年的資料外洩研究發現，在它所研究的組織裡，撞庫攻擊占了全部登入嘗試的中位數 19%，而被竊憑證是 22% 的外洩事件最初的入侵途徑。一個永不到期的重設權杖、一個改了密碼後依然有效的工作階段、一次只在頁面上執行卻沒在其背後 API 上執行的權限檢查——這裡面隨便哪一個，都是那種要等到被利用之後你才會發現、而不是之前的漏洞。

在 ybuild 上，這一切都不需要你親手拼裝。你描述誰來登入、每個角色能做什麼，平台就會把帳戶、雜湊、工作階段、重設、速率限制與權限檢查建進這個正在運作的應用程式裡——沒有身分驗證函式庫要設定，也沒有安全性程式碼要審查。它託管在 ybuild 上，並透過你自己的網域對外提供服務，因此憑證以受管密鑰的形式存放在平台上，而你的使用者是在你的網址上登入。日後當你要新增一個角色，或改變某人能看到的內容時，你只需用日常語言說一聲，正在運作的應用程式就會就地更新。

託管身分驗證對一門正在營運的生意意味著什麼

當一套系統有了真實使用者——客戶在下單預約、員工在辦公、會員在付費——的那一刻，身分驗證就不再只是一項功能，而成了整門生意所倚靠的邊界。它決定誰是誰，把一個人的資料與另一個人的隔開，並擋在你的紀錄與網際網路上所有拿著被竊密碼來碰運氣的人之間。做對了，它就是隱形的；做錯了，它就會以兩種響亮的方式之一崩掉——不是外洩、把客戶資料暴露出去，就是把付費使用者擋在門外的封鎖。無論哪一種，花掉的都是你很難輕易再賺回來的信任。

這種威脅並非假想。Verizon 2025 年的資料外洩研究把被竊憑證列在組織遭到入侵的各種途徑之首，而另有分析長期以來一直發現，針對日常 Web 應用程式的攻擊中，絕大多數都是靠著某人手裡早已握有的憑證混進來的。一家小生意的預約應用程式或 CRM，和一家銀行處在同一張公共網際網路上；唯一的差別在於，這個登入是由一個認真考量過雜湊、速率限制與逐一使用者存取的人打造的，還是為了趕快上線而胡亂拼湊起來的。託管身分驗證意味著這些決定被一次性地、為每一個應用程式都做對了，並且由平台來維護，而不是由你在晚上 11 點親自扛著。

說到實處，正是這一點讓你敢把這套系統擺到它本該服務的人面前。客戶擁有自己的帳戶，只看得到屬於自己的預約、發票或紀錄；員工恰好拿到其角色所需的存取權限；而你握有全局的主檢視。這一切都運作在 ybuild 上，並透過你自己的網域對外提供服務，所以登入感覺起來就是你生意的一部分，而不是繞道去某個第三方入口網站——那些敏感的部分始終儲存並受保護在平台上，而不是散落在一張試算表或某個你悄悄背著責任的旁路工具裡。這正是「幾個人隨便試試的應用程式」和「一門真生意賴以運轉的系統」之間的差別。

常見問題

我必須自己打造登入系統嗎？

不用。描述誰來登入、每個人各自該看到什麼，ybuild 就會把整套東西——註冊、登入、密碼重設、工作階段，以及逐一使用者的權限——建進這個正在運作的應用程式裡。沒有身分驗證函式庫要設定，也沒有安全性程式碼要你去寫或審查。

我的使用者密碼存在哪裡，安全嗎？

存在 ybuild 上，而且絕不是明文。每個密碼都經過一次緩慢、加鹽的單向雜湊——正是 OWASP 推薦的做法——所以即使資料有朝一日被外洩，裡面也沒有真正的密碼。憑證以受管密鑰的形式保存在平台上，並透過你自己的網域對外提供服務。

不同的人可以有不同層級的存取權限嗎？

可以。告訴 ybuild：客戶只看得到自己的紀錄、員工看得到自己手頭的全部工作、而擁有者看得到一切，它就會打造出這些角色，並在每一次讀取與寫入時強制執行。一個使用者沒辦法靠改一改 URL 裡的數字就叫出另一個使用者的資料，而且你日後隨時可以用日常語言調整誰能看到什麼。

有什麼能阻止攻擊者猜密碼或重用被竊的密碼？

登入會對失敗的嘗試進行速率限制，並依照 NIST 的指引把新密碼與已知的外洩密碼清單比對——這一點很重要，因為在 Verizon 2025 年的外洩研究裡，撞庫攻擊占了登入嘗試的中位數 19%。這層防護內建在每一個 ybuild 應用程式裡，並由平台負責維護，而不是留給你自己去加。

我的使用者是在我自己的網域上登入，還是在第三方頁面上登入？

在你自己的網域上。帳戶、登入與工作階段都託管在 ybuild 上，並在你的網址上對外提供服務，所以登入感覺起來是你生意的一部分，而不是繞道去別人的入口網站。你的使用者登入進去的那個應用程式，和他們信任的那個網站，是同一個東西。