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