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

背景#

我見過很多開發者問類似“我應該為我的應用程式建立自己的身份驗證嗎？”的問題。雖然答案不能簡單地用 "是" 或 "否" 來回答，但我想寫一篇文章來解析如何實施，並展示利弊來幫助你決定。

懶人包 找到符合你需求的現有解決方案是必要的，除非你真的想要完全控制或你仍在學習軟件開發。

簡介#

作為開發者，我在職業生涯中建立了許多應用程式。無論使用哪種編程語言，我總需要構建一個共同基礎：用戶身份驗證。

回到 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 令牌等）？
• 簽名字如何在令牌中使用，如何驗證簽名以保護資源？
• 如何防止客戶端和服務器的攻擊？

最終，你可以實現一個良好的登入體驗並提供給客戶。

授權模型#

作為一個書店，你需要分隔顧客和賣家的資源。例如，顧客可以瀏覽所有書籍，而賣家可以管理他們列出的書籍。如果-Else 的檢查可以作為開始，但隨著業務增長，你可能需要利用更靈活的模型，如基於角色的訪問控制（RBAC）或基於屬性的訪問控制（ABAC）。

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

作出決定#

你可以看到身份驗證並不是一個“全有或全無”的問題，因為它涉及多個技術組件，而你或者你的團隊在這些領域可能擁有不同的技術專長。重要的是將其拆分成更小的部分，以便更好地了解當前狀況。

為了作出決定，我會問自己以下問題：

• 項目有多緊急？
• 我預計將多少精力投入到身份驗證中，而非業務中？
• 用戶體驗、安全性和可維護性的優先級是什麼？
• 哪個部分是我需要完全控制的？我應該對它們多熟悉？
• 如果我使用框架或解決方案，它們的自定義能力或擴展性如何？
• 如果業務增長，我是否需要引入新的身份驗證模型？
• 如果我找到合適的供應商，它的安全性如何？萬一供應商出了問題，我是否需要一個撤出計劃？

想到這些問題後，我發現了兩個事實：

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

因此，我決定開始一個專門的項目（Logto）用於身份驗證，並從第一天起擁抱開源社群。

希望這篇文章對你有幫助。