你需要為應用程式建立自己的驗證系統嗎？

背景#

我看到很多開發者在問類似「我應該為我的應用程式建立自己的驗證系統嗎？」這樣的問題。雖然答案不能簡單地是「是」或「否」，我想寫一篇文章來細分實現和演示其優缺點以幫助你做出決策。

總結 除非你真的希望完全控制或仍在學習軟體開發，否則有必要找到符合需求的現有解決方案。

介紹#

作為一名開發者，在我的職業生涯中我構建了許多應用程式。不論使用何種程式語言，我始終需要構建的一個共同基礎是用戶驗證。

回到 20 年前，這是個微不足道的部分，因為一切都是直接明了的：

• 實現一個用戶名和密碼的註冊和登入系統。
• 創建一個機制來維護用戶的會話。
• 有關安全性？MD5 是答案。

就是這樣。然後我可以專注於「真正的業務」。沒聽過 MD5？你錯過了軟體開發的「好時光」。如今，開發者在建立登入/註冊時面臨更多挑戰。

這聽起來有點危言聳聽，但讓我舉個例子來說明。

範例：一個線上書店#

假設你想建立一個有 API 服務和網頁前端應用的線上書店。

首先，需要定義「驗證」的範圍。驗證可以解釋為身份驗證和授權，它們有完全不同的定義和用例：

我寫了一篇文章 CIAM 101: 身份驗證、身份、單一登入 來詳細討論這些概念。

選擇身份驗證方法#

讓我們從「身份驗證」開始，這是我們例子中的用戶登入。除了用戶名和密碼的方法，這裡有一些人們為了更好的用戶轉換和安全性而採用的流行方法：

• 無密碼，即動態驗證碼（通過電子郵件或短信）
• 社交登入（Google、Facebook 等）

方法的選擇取決於商業決策，同時我們可以看看技術工作量：

• 對於無密碼，你需要找到一個供應商通過電子郵件或短信發送驗證碼；然後與你的 API 服務集成（可能需要新的 API）。
• 對於社交登入，你必須遵循你想使用的社交身份提供者的集成指南。此外，你必須創建一個映射在你的書店用戶 ID 和身份提供者之間。
  • 例如，當用戶用 Gmail 帳戶 [email protected] 登入時，你可以將這個電子郵件地址連結到書店中的用戶 foo。這個過程幫助你建立一個統一的身份系統，並允許用戶將來修改或取消連結其社交身份。

設計和實現登入體驗#

在你決定身份驗證方法後，為你的最終用戶提供一個優雅且流暢的登入體驗是下一個目標。這裡的轉換是基本的但對業務至關重要，因為這是一種自然的方式留下持久的客戶數據。

當我在 Airbnb 工作時，有一整個團隊專注於優化多平台的登入體驗。他們進行了無數次 A/B 測試以確定哪種組合具有最高的轉換率。

當業務剛起步時，這樣做不切實際。但我們仍需盡最大努力使每個環節都正確。你想在哪些平台上運行書店？你可能從移動端、網頁或兩者一起開始。具體設計將取決於你選擇的身份驗證方法：

• 用戶名和密碼：最簡單的，只需幾個輸入框和按鈕。
• 無密碼：輸入電話/電子郵件，然後發送和驗證動態碼。
• 社交登入：閱讀所選社交身份提供者的文件，遵循視覺指導，處理重定向邏輯，最終將社交身份與書店身份連結。

考慮更多使其更好的因素：

• 你需要為一種特定的方法結合登入和註冊過程嗎？
• 你需要一個「忘記密碼」流程允許用戶自行重設密碼嗎？

如果你選擇原生開發，對於新增一個平台，工作量將幾乎加倍。

安全與令牌交換#

安全性可能是個隱藏的大障礙。如果你熟悉 OpenID Connect 或 OAuth 2.0，這將會很棒，因為它們被廣泛使用且經過實踐檢驗。OpenID Connect 相對較新，但設計用于「用戶身份驗證」，這非常適合一個線上書店。

不深入討論標準的細節，還是有一些事情需要考慮：

• 應該使用哪種加密方法來處理密碼？
• 標準身份驗證和授權的過程是什麼？
• 令牌交換如何運作（訪問令牌、刷新令牌、ID 令牌等）？
• 如何在令牌中使用簽名密鑰，以及如何驗證簽名以保護資源？
• 如何防止客戶端和服務器攻擊？

最終，你可以提供給用戶良好的登入體驗。

授權模型#

作為書店，你需要分隔客戶和賣家的資源。例如，客戶可以瀏覽所有書籍，而賣家可以管理他們在售的書籍。起初使用簡單的 if-else 檢查即可，但隨著業務增長，你可能需要利用更靈活的模型，例如基於角色的訪問控制（RBAC）或基於屬性的訪問控制（ABAC）。

我也撰寫了一篇文章 CIAM 102: 授權與基於角色的訪問控制 來展示基本的授權概念和 RBAC 模型。

做出決策#

你可以看到驗證並不是「全有或全無」的問題，因為它涉及多個技術組件，你或你的團隊在這些領域可能擁有不同的技術專長。將其拆分為較小的部分有助於更好地理解現狀。

要做出決策，我會問自己以下問題：

• 專案的急迫性如何？
• 我預期將多少努力放在驗證與業務上？
• 用戶體驗、安全性和可維護性的優先順序是什麼？
• 我需要在哪些部分擁有完全控制？我應對它們有多熟悉？
• 如果我選擇某些框架/解決方案，它們是否足夠好可以進行客製化或擴展？
• 如果業務增長，我會需要引入新的身份驗證模型嗎？
• 如果我找到合適的供應商，使用是否足夠安全？如果供應商發生任何問題，我需要退路計劃嗎？

考慮上述問題後，我發現兩個事實：

• 精心打造一個可靠的驗證系統是非常複雜的。
• 現有供應商無法滿足所有必要標準。

所以我決定為驗證（Logto）開始一個專案，並從第一天起擁抱開源社群。

希望這篇文章能幫助你。