標準化身份管理爲何重要?

現在，用戶身份的管理變得愈來愈複雜，不只消耗工做人員的時間，還會提升開發管理的成本，緣由有不少:

• 應用程序的激增: 許多組織將早先遺留的應用程序與現代應用程序組合起來，而且不斷往其中添加新的應用程序。就像亞馬遜首席執行官傑夫·貝佐斯的「兩份披薩」規則同樣：他們避免了須要兩份以上披薩才能知足全體員工的大型會議，而是選擇了小團隊工做。雖然小團隊的方法使協做和創新更加容易，但同時也對應用程序產生了更多需求。每一個應用程序都有本身的功能和用戶，這還會致使員工、客戶和合做夥伴須要使用多個應用程序，以及登陸這些程序所須要的單獨的用戶名和密碼。
• 防止數據泄露: 根據賽門鐵克2019年互聯網安全威脅報告，近年來，網絡犯罪分子一直在擴大他們的目標，並使用更復雜的方法來進行身份盜竊和欺詐。隨着數據泄露的數量持續上升，企業正努力保護本身的信息不受入侵。雖然多因素身份驗證和異常檢測等措施增長了另外一層保護，但企業仍須要付出更多的時間和精力。
• 隱私規定的增長: 爲了應對消費者對於我的信息的安全需求，隱私規定在不斷增長。今天的企業須要作更多來保護人們的我的數據隱私。

有了全部這些需求和和變化，那麼問題來了: 如何跟上這些變化?

不幸的是，許多企業被迫陷入「非此即彼」的境地。他們在提升應用程序的安全性時，犧牲了用戶體驗；或者，他們只專一於構建應用程序給用戶提供的良好體驗，而忽略了安全性。不管哪一方的缺失都不是一個好的選擇。

Authing 認爲，用戶體驗和安全性是不衝突的。組織不該該被迫在改善用戶體驗和減小安全風險之間作出沒必要要的權衡。相反，標準化的身份識別策略能夠保證，每一個客戶所體驗到的服務都是安全且友好的。

標準化身份策略的好處

身份管理沒有標準化的公司將面臨更高的成本和更大的安全風險。在分佈式環境中，每次更新需求時，開發人員都必須分別更新每一個單獨的應用程序，這不只增長了他們的開發時間，還會出現更多的安全漏洞。

重複登陸讓用戶體驗更差。用戶被要求重複輸入用戶名和密碼的頻率越高，他們對服務就越不滿意。糟糕的用戶體驗會下降您公司的生產力，還會阻礙用戶登陸應用程序的客戶端。

身份標準化的好處

經過標準化身份，您能夠將身份管理從多個環境轉移到單個環境，從而減輕身份驗證的負擔。使用標準化的方案，您能夠進行統一的身份管理而且得到許多好處，而這在分佈式環境中是困難又昂貴的。這些好處包括:

• 聯邦身份提供商: 讓全部應用程序均可以進行社交媒體登陸。
• 增長多因素身份驗證 (MFA) : 經過在須要的狀況下要求 MFA 來防止數據泄露。
• 管理贊成: 當與合做夥伴一塊兒工做時，能夠輕鬆地管理贊成請求。
• 漸進式分析: 啓用漸進式分析，能夠持續收集更多訪問您的網站的客戶信息。
• 異常檢測: 監視用戶的異常行爲，以幫助識別欺詐的訪問請求。
• 管理用戶: 輕鬆地管理用戶對全部系統、設備、應用程序和網絡的訪問。
• 遵照隱私規定: 知足愈來愈多的隱私規定，確保只有通過受權才能訪問敏感數據。

高教社: 經過單一登陸體驗簡化身份

高等教育出版社（如下簡稱高教社）成立於1954年5月，是新中國最先設立的專業教育出版機構之一。高教社現有在職員工1700餘人，年出書萬餘種，發行近1.3億冊。

高教社主要面臨着如下需求挑戰：

A.3500 萬用戶分佈在幾十個平臺

B.須要優質的用戶體驗設計

C.須要防欺詐保護、安全保障

D.須要跨品牌單一登陸

Authing 開發團隊針對高教社的需求，給出了針對性的解決方案：

A.一個下午兩我的即完成部署測試，輕鬆集成千萬用戶

B.統一登陸，在一處、用一個帳號登陸

C.經過多因素認證、登陸環境監測，提供專業的安全防禦

D.平臺彈性靈活，文檔、軟件包豐富，可集成各類品牌系統，下降了開發成本，減小維護工做

成本效益分析很快證實，高教社將更好地利用其員工資源來實現核心業務目標。使用 Authing 進行身份管理能夠打破企業內部的障礙，解決具備挑戰性的身份集成問題。Authing 還提供了一個強健而靈活的解決方案，它以開發人員爲中心，易於集成。該平臺對 Web 和移動設備友好，支持開放標準，並提供有力的特性和將來驗證，支持普遍的身份提供者而且易於遷移。

選擇 Authing 有許多好處。使用 Authing 的身份管理解決方案減小了額外的開發工做，從而爲 IT 創新釋放了更多的資源。統一身份管理能夠助推增加，加快上市時間，系統從增長的安全性和最佳實踐中獲益。Authing 還能夠快速完全地反應漏洞。高教社這樣評價Authing： 「Authing 是一個通過思考作出來的產品。」

標準化身份管理的起源

開發人員一直在追求身份的標準化管理，近年來，有兩種協議實現了這一點。過去，若是想要建立一個可供其餘人員編寫的應用程序 (API)，須要提供用戶的用戶名和密碼，而後在數據庫中進行加密。但問題是，若是您用戶的用戶名和密碼儲存在了其餘程序當中，安全風險就會大大提升。

• OAuth 能夠解決這個問題。OAuth 是一個訪問受權的開放標準，它可讓第三方 web 應用程序和網站使用用戶的賬戶信息，但無需將帳戶憑據暴露給第三方。OAuth 向須要帳戶信息的應用程序提供訪問令牌，來受權對用戶數據的訪問。
• OpenID Connect 進一步爲聯邦身份認證提供了一個行業標準——例如，容許用戶使用谷歌或 Facebook 憑證登陸到第三方應用程序或網站。OpenID Connect 是在 OAuth 2.0 協議之上構建的一個簡單的身份驗證層，它提供了一種簡單的方法，能夠根據受權服務器執行的身份驗證驗證用戶的身份，而用戶無需共享其登陸信息。

雖然這些標準是爲第三方訪問而創建的，但它們也能夠用於公司內部應用程序之間的交互。即便一家公司的應用程序的編程語言不一樣，它也可使用 Authing 的軟件開發工具包 (SDKs) 對全部應用程序的身份進行標準化管理。

經過應用程序的標準化身份管理，開發人員能夠減小維護應用程序的時間，同時經過減小用戶登陸次數，來改善用戶體驗；他們還能夠經過整合最佳實踐和下降用戶證書被盜的風險來提升安全性。

將標準化的身份變成現實

標準化的身份管理爲您帶來許多好處，但如何實現呢?

在採用此功能以前須要制定一個詳細的計劃，包括考慮到您公司的需求。您須要可視化當前和將來可使用 Authing 的應用程序；您將須要肯定如何遷移用戶，如何實時將新用戶引入系統，以及如何管理全部這些用戶配置文件；你須要找到一種方法來改善登陸體驗；您還須要考慮對用戶進行身份驗證和受權的特定規則，以及如何將退出系統的用戶從系統中註銷。

雖然須要考慮的事情不少，但一旦肯定了具體的需求，Authing 能夠快速設置標準方案，其中大部分均可以開箱即用。您可能有一些特殊的需求，咱們可使用 Authing 的預構建擴展或編寫自定義代碼來知足。

如下是你計劃實施時須要考慮的七個方面:

1. 架構: 如何在應用程序中創建標準化的身份

實現標準化身份要從理解應用程序體系的結構開始。今天的開發團隊更傾向於將難以管理的大型應用程序拆分爲幾套較小的應用程序，全部這些應用程序都須要與數據庫通訊。您的組織中有哪些應用程序，又有哪些用戶使用它們？您的組織使用哪些移動應用程序、單頁應用程序和 web 應用程序？將來的應用程序需求是什麼？

可視化現有的計劃和架構是利用 Authing 來知足您的需求的關鍵。

2. 供應: 如何讓用戶進入個人系統

• 用戶遷移：若是您直接將用戶遷移到標準化身份管理系統，那麼這個過程頗有可能不是從零開始的。您的組織可能已經有許多應用程序——每一個應用程序都有本身的用戶集，不管他們是僱員、客戶仍是合做夥伴。那麼如何將用戶遷移到標準化系統中呢?是否要將這些用戶直接轉移到 Authing 中。仍是將用戶保留在原來的應用程序中，只是將數據庫鏈接到 Authing?
• 用戶聯合：您是否但願實現單點登陸，不用再爲每一個用戶管理多個用戶名和密碼？若是是這樣的話，您如何將社交登陸融入其中，並讓外部公司提供他們本身的身份認證呢?
• 自我註冊和用戶邀請：您如何向您的系統添加新用戶? 若是您是 B2C 公司，你會創建一個自我註冊表格，爲新的網頁客戶填寫? 若是您是一家 B2B 公司，管理員會邀請用戶進入您的系統嗎?

3. 身份驗證：如何驗證用戶

• 單點登陸（SSO）: 用戶不但願每次在應用程序之間切換時都要登陸。所以須要實現單點登陸，這樣用戶就能夠保持他們的生產力，而不須要不斷地被提示登陸憑證。
• 全屏 VS 彈窗：有幾種方法能夠實現單點登陸。爲了創造無縫體驗，你能夠 "徹底重定向 "你的應用，讓用戶在同一個瀏覽器窗口內看到登陸頁面，登陸，而後最終回到他們的應用。或者，若是你不想讓用戶離開你的頁面，另外一個選擇是建立一個 "彈出"方案，即在同一屏幕上彈出登陸頁面。
• 第三方應用：另外一個須要考慮的因素是，如何驗證第三方應用程序的用戶，例如社區論壇或支持中心，將用戶發送到第三方應用程序。用戶不會想要建立一個單獨的用戶名和密碼來登陸全部這些系統，而集中式受權服務器比將登陸信息嵌入到全部這些應用程序中更簡單。若是你決定不使用單點登陸，最起碼要讓用戶在每次登陸你的應用時都有一個一致的登陸頁面，給他們一個統一的體驗，讓他們以爲輸入憑證是安全的。

4. 受權: 容許用戶作什麼

一旦用戶進行了身份驗證，您將受權他們作什麼?對於某些應用程序，您可能但願向每一個用戶發出相同的權限。可是對於其餘用戶，您可能但願授予不一樣級別的權限，以指定不一樣組的用戶能夠訪問哪些信息，以及他們能夠在應用程序中採起哪些操做。Authing 提供了一個基於角色的訪問控制 (RBAC) 系統，容許您建立角色並分配權限，以知足您對每一個用戶和應用程序的需求。一旦您建立了規則，它就能夠提供了您須要的信息，您的應用程序就能夠執行這些權限。

5. 品牌: 如何創造符合品牌的用戶體驗

• Authing 託管頁面: 從營銷的角度來看，不只品牌身份體驗很重要，確保用戶不會受到網絡釣魚攻擊也一樣重要。一體化的體驗始於使用自定義域在開頭顯示的 URL。Authing 容許您配置全部與身份相關的頁面——包括您的登陸、更改密碼、多因素身份驗證和錯誤頁面——以匹配公司標識與外觀。
• Guardian SDK: Authing 還提供了一個 Guardian SDK，可讓你在 web 和移動應用程序中構建 MFA。這樣你的用戶就沒必要爲 MFA 下載一個單獨的應用程序了。定製的 MFA 推送通知提供了另外一個保持品牌一致性的機會，並且有了 Guardian SDK，設置起來很簡單。

6. 配置文件管理: 如何維護用戶管理

• 管理 API ：在全部應用程序中創建標準化的身份，能夠方便地管理用戶配置文件，並在實時更新信息——不管是用戶提供的新信息、組織需求，仍是因爲法律法規的變更而進行的更改。Authing 管理 API 容許您經過直觀的管理儀表板集中管理用戶。經過管理 API，您能夠輕鬆地構造一個應用程序，使管理員可以管理用戶。您能夠將其合併到已經存在的應用程序中，或者建立具備與當前應用程序匹配的用戶界面的新應用程序。
• 委託管理擴展: 經過 Authing 委託管理擴展，您能夠控制如何委託管理訪問，例如，指定管理員來管理特定的用戶組和應用程序組。
• 漸進式配置: 在這種配置中，企業經過讓用戶輸入電子郵件和密碼，容許用戶快速登陸應用程序，而後隨着時間的推移收集更多的用戶信息。若是須要此功能，能夠在 Authing 身份管理 API 中建立定向規則，給用戶發送單獨的登陸頁面，以便從集中式系統中收集更多的用戶信息。
• 賬戶鏈接: 隨着時間的推移，您可能還但願創建賬戶連接，將不一樣的身份信息聚集到一個用戶配置文件中。例如，您可能但願容許從多個身份提供者 (如 Facebook 和谷歌) 以及 Authing 用戶名和密碼進行登陸。默認狀況下，每一個登陸都有一個單獨的用戶配置文件。使用 Authing，您能夠將這些用戶賬戶鏈接在一塊兒，未來自不一樣渠道的身份信息聚集到單一的配置文件當中。
• 阻塞用戶: 您還須要肯定阻塞和解除阻塞用戶的需求。Authing 面板提供了一種開箱即用的機制來阻止或取消用戶對全部應用程序的訪問。您還能夠利用更優化的訪問控制來禁用用戶對某些應用程序的訪問，而不是其餘應用程序。
• 用戶元數據: 使用 Authing，能夠根據用戶配置文件存儲元數據，從而捕獲其餘信息，如用戶的語言偏好，以加強用戶體驗。元數據能夠用來存儲用戶能夠更改和不能更改的信息。此功能的目的不是取代 CRM 系統或用戶數據庫，而是增強用戶的身份信息，以便您隨時掌握用戶的數據。

7. 註銷: 如何關閉用戶會話

• 單次註銷: 單次註銷與在不一樣的平臺進行分別註銷不用，指的是用戶從正在使用的每一個應用程序，以及受權服務器中註銷帳戶。一種方法是發出短時間令牌，這容許用戶只能在短期內訪問應用程序。只要用戶登陸，新的令牌就會悄無聲息地發出，但一旦單點登陸會話結束，令牌就會被刪除，用戶就必須從新輸入他們的憑證。
• 另外一種方法是構建一個能夠跟蹤和銷燬應用程序會話的註銷服務。每一個應用程序都將在建立和刪除會話時發通知用戶的登陸與註銷信息。這種技術能夠解決用戶數據到達系統的延遲問題，可是也更加複雜，須要更多的開發時間。

使用 Authing 標準化管理身份

身份管理的標準化可能會很複雜，但 Authing 爲客戶承擔了全部的工做——將一套複雜的決策轉化爲一個簡單的系統，幫助客戶簡化身份管理。

其中大部分服務均可以經過 Authing 的「開箱即用」功能完成。對於有特殊需求的組織，咱們提供易於使用的擴展功能，使您可以全面自定義標準化身份。不管您是想在特定狀況下要求多因素認證，爲第三方應用程序提供用戶贊成，仍是經過漸進分析從用戶那裏得到更多信息，您均可以定製您的身份以知足特定的需求。Authing 能夠爲您在標準化身份管理上提供一個簡單而靈活的解決方案。