用戶再也不被屢次登陸困擾,也不須要記住多個 ID 和密碼。另外,用戶忘記密碼並求助於支持人員的狀況也會減小。html
SSO 爲開發人員提供了一個通用的身份驗證框架。實際上,若是 SSO 機制是獨立的,那麼開發人員就徹底不須要爲身份驗證操心。他們能夠假設,只要對應用程序的請求附帶一個用戶名,身份驗證就已經完成了。git
若是應用程序加入了單點登陸協議,管理用戶賬號的負擔就會減輕。簡化的程度取決於應用程序,由於 SSO 只處理身份驗證。因此,應用程序可能仍然須要設置用戶的屬性(好比訪問特權)。github
這些都屬於業務上的優點,除了業務上的優點外,還有軟件架構層面的優點。算法
單點登陸是一種比普通的帳號密碼登陸更加規範化的解決方案,若是有一天你的業務擴大,想要聚合全部平臺的用戶,那麼提早用上了單點登陸的你會使整個過程變得很是容易。有太多前期的用戶系統作的很不規範,系統壯大後須要投入大量人力物力來進行遷移的案例出現。形成軟件前期不使用單點登陸的主要緣由是單點登陸的複雜性,若是單點登陸的複雜性和實施成本能被下降,那麼我相信不少人都願意直接使用。編程
再類比一下,使用單點登陸對你的系統向下兼容就好像 C++ 能夠兼容 C 語言同樣,你在用 C++ 時,使用面向對象編程的同時,不會耽誤你面向過程編程。相反,若是你使用了 C 語言,在理論上你固然也能夠面向對象編程,只不過過程過於複雜,異常痛苦,甚至不符合 C 語言的設計思想。爲何要將不合適的東西強行扭成合適的呢?這就是單點登陸相較於普通登陸方式最本質的區別。安全
教科書爲了讓你快速上手,因此選擇 C 語言開始;PHP 爲了讓你快速上手,選擇讓你學習最簡單的單向「用戶名 - 密碼」登陸開始。可是咱們都知道,軟件最好從一開始就使用面向對象編程,那麼任何的互聯網應用,從一開始就使用「單點登陸」也是一樣的道理。架構
假設你的軟件從一開始就沒有考慮過使用單點登陸,那麼當你的業務拓展成功而且有多個平臺後,多平臺用戶的 Merge 就會變成很大的一個難點,好比如何肯定註冊到 A 平臺的郵箱和 B 平臺的郵箱是同一個、用戶的密碼如何重置、如何肯定 Merge 完成後的用戶信息沒有任何損失等等。app
若是你從一開始就使用了單點登陸,那麼這些問題都將不復存在。將用戶從平臺中遷移出來將像導出 Excel 到 CSV 同樣簡單。框架
進行身份認證的目的是爲了受權用戶可訪問哪些資源,單點登陸都有十分規範化的權限受權系統,RBAC 是業內比較承認的受權管理方案。單點登陸系統通常都自帶開發者友好和組織友好的 RBAC 方案,可讓開發者快速實現中心化受權體系。學習
除此以外,用戶的歷史活動爲斷定可信度提供了豐富的分析素材。系統能夠經過挖掘用戶的歷史操做構建其行爲基線,而後經過比較當前操做和其行爲基線來計算用戶的信任評分。
經過比較當前用戶的地理位置座標能夠發現是否有異常,好比一個用戶的設備在一個較小的時間窗口內忽然出如今某個用戶不可能達到的座標;再好比用戶有多個設備,但其報告了不同的地理位置。可是必須注意,地理位置是存在誤差的,因此地理位置的權重不該該太高,而是做爲一種參考。
成熟的單點登陸系統都會提供這些功能,除此以外還有可定製的加密算法、用戶密碼泄漏檢測等多維化功能,保障整個系統的管理安全和流程安全。
前面咱們講了爲何全部軟件都應該使用單點登陸來管理用戶,那麼如何最低成本的實現單點登陸呢?這裏就要介紹下 Authing 了。
Authing 是一款身份認證雲,提供了開發者優先和極易拓展的開發平臺,簡化了身份管理的流程,使用 Authing 能夠用極短的時間和極低的成本實現單點登陸(用戶量數十萬的應用從遷移進 Authing 到上線到生產環境只須要兩天),若是你對此感興趣,能夠查看這篇文章:用 Authing 10 分鐘實現單點登陸。
最後,但願這篇文章能對你的下一次軟件開發有幫助~
Authing 提供專業的身份認證和受權服務。
咱們爲開發者和企業提供用以保證應用程序安全所需的認證模塊,這讓開發人員無需成爲安全專家。
你能夠將任意平臺的應用接入到 Authing(不管是新開發的應用仍是老應用均可以),同時你還能夠自定義應用程序的登陸方式(如:郵箱/密碼、短信/驗證碼、掃碼登陸等)。
你能夠根據你使用的技術,來選擇咱們的 SDK 或調用相關 API 來接入你的應用。當用戶發起受權請求時,Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。