繁體中文（台灣）
你需要為應用程式建立自己的驗證系統嗎？
我看到很多開發者在問類似「我應該為我的應用程式建立自己的驗證系統嗎？」這樣的問題。雖然答案不能簡單地是「是」或「否」，我想寫一篇文章來細分實現和演示其優缺點以幫助你做出決策。
Gao
Founder
Founder
我看到很多開發者在問類似「我應該為我的應用程式建立自己的驗證系統嗎？」這樣的問題。雖然答案不能簡單地是「是」或「否」，我想寫一篇文章來細分實現和演示其優缺點以幫助你做出決策。
我看到很多開發者在問類似「我應該為我的應用程式建立自己的驗證系統嗎？」這樣的問題。雖然答案不能簡單地是「是」或「否」，我想寫一篇文章來細分實現和演示其優缺點以幫助你做出決策。
總結 除非你真的希望完全控制或仍在學習軟體開發，否則有必要找到符合需求的現有解決方案。
作為一名開發者，在我的職業生涯中我構建了許多應用程式。不論使用何種程式語言，我始終需要構建的一個共同基礎是用戶驗證。
回到 20 年前，這是個微不足道的部分，因為一切都是直接明了的：
就是這樣。然後我可以專注於「真正的業務」。沒聽過 MD5？你錯過了軟體開發的「好時光」。如今，開發者在建立登入/註冊時面臨更多挑戰。
這聽起來有點危言聳聽，但讓我舉個例子來說明。
假設你想建立一個有 API 服務和網頁前端應用的線上書店。
首先，需要定義「驗證」的範圍。驗證可以解釋為身份驗證和授權，它們有完全不同的定義和用例：
我寫了一篇文章 CIAM 101: 身份驗證、身份、單一登入 來詳細討論這些概念。
讓我們從「身份驗證」開始，這是我們例子中的用戶登入。除了用戶名和密碼的方法，這裡有一些人們為了更好的用戶轉換和安全性而採用的流行方法：
方法的選擇取決於商業決策，同時我們可以看看技術工作量：
[email protected] 登入時，你可以將這個電子郵件地址連結到書店中的用戶 foo。這個過程幫助你建立一個統一的身份系統，並允許用戶將來修改或取消連結其社交身份。在你決定身份驗證方法後，為你的最終用戶提供一個優雅且流暢的登入體驗是下一個目標。這裡的轉換是基本的但對業務至關重要，因為這是一種自然的方式留下持久的客戶數據。
當我在 Airbnb 工作時，有一整個團隊專注於優化多平台的登入體驗。他們進行了無數次 A/B 測試以確定哪種組合具有最高的轉換率。
當業務剛起步時，這樣做不切實際。但我們仍需盡最大努力使每個環節都正確。你想在哪些平台上運行書店？你可能從移動端、網頁或兩者一起開始。具體設計將取決於你選擇的身份驗證方法：
考慮更多使其更好的因素：
如果你選擇原生開發，對於新增一個平台，工作量將幾乎加倍。
安全性可能是個隱藏的大障礙。如果你熟悉 OpenID Connect 或 OAuth 2.0，這將會很棒，因為它們被廣泛使用且經過實踐檢驗。OpenID Connect 相對較新，但設計用于「用戶身份驗證」，這非常適合一個線上書店。
不深入討論標準的細節，還是有一些事情需要考慮：
最終，你可以提供給用戶良好的登入體驗。
作為書店，你需要分隔客戶和賣家的資源。例如，客戶可以瀏覽所有書籍，而賣家可以管理他們在售的書籍。起初使用簡單的 if-else 檢查即可，但隨著業務增長，你可能需要利用更靈活的模型，例如基於角色的訪問控制（RBAC）或基於屬性的訪問控制（ABAC）。
我也撰寫了一篇文章 CIAM 102: 授權與基於角色的訪問控制 來展示基本的授權概念和 RBAC 模型。
你可以看到驗證並不是「全有或全無」的問題，因為它涉及多個技術組件，你或你的團隊在這些領域可能擁有不同的技術專長。將其拆分為較小的部分有助於更好地理解現狀。
要做出決策，我會問自己以下問題：
考慮上述問題後，我發現兩個事實：
所以我決定為驗證（Logto）開始一個專案，並從第一天起擁抱開源社群。
希望這篇文章能幫助你。