選擇身分識別管理解決方案
大部分的 Web 應用程式都支援驗證,以確保使用者就是其宣告的身分。 「使用者」可能是個人或另一個應用程式。 存取權的管理可確保使用者只能查看和修改其有權查看和修改的資訊。 例如,使用者不應該有權存取網站的系統管理區段。 建置 Identity 管理解決方案旨在處理驗證和授權相關工作的需求。 若要深入了解身分識別管理,請參閱什麼是身分識別與存取管理?。 有許多適用於 .NET Web 應用程式的身分識別管理解決方案可供使用,每個解決方案都有不同的功能及其使用或安裝需求。 本文提供如何選擇正確解決方案的指引。
使用 ASP.NET Core Identity 進行基本身分識別管理
ASP.NET Core 隨附內建驗證提供者:ASP.NET Core Identity。 提供者包含 API、UI 和後端資料庫組態,以支援管理使用者身分識別、儲存使用者認證,以及授與或撤銷權限。 其支援的其他功能包括:
- 外部登入
- 雙重要素驗證 (2FA)
- 密碼管理
- 帳戶鎖定和重新啟用
- 驗證器應用程式
對於大部分案例,這可能是唯一需要的提供者。
若要深入了解:
- 閱讀 ASP.NET Core 上的Identity簡介
- 請遵循教學課程來建置您自己的安全 .NET Web 應用程式:使用 ASP.NET Core Identity 架構保護 .NET Web 應用程式。
在其他案例中,管理驗證和身分識別的伺服器或服務可能很有用。
判斷是否需要 OIDC 伺服器
Web 應用程式需要一種方式來「記住」過去的動作,因為 Web 預設為無狀態。 否則,每次使用者瀏覽至新頁面時,將被強制輸入其認證。 用於記住狀態的常見解決方案是 cookie,這是用於儲存資料的瀏覽器型機制。 Web 伺服器會傳送初始 cookie,然後瀏覽器會將其儲存,並與每個要求一起傳回。 此動作會自動完成,而不需要開發人員撰寫任何程式碼。 Cookie 易於使用並內建在瀏覽器中,但專為在單一網站或 Web 網域內使用而設計。 ASP.NET Core 內建的預設解決方案會使用 cookie 型驗證。
權杖是具有中繼資料的容器,其會明確地透過 HTTP 要求的標頭或本文傳遞。 權杖超過 cookie 的主要優點是,其不會系結至特定的應用程式或網域。 相反地,權杖通常會使用非對稱密碼編譯進行「簽署」。 例如,OIDC 伺服器會使用包含簽署的 JSON Web 權杖 (JWT) 格式來發出權杖,其中具有身分識別的相關資訊。 非對稱密碼編譯會使用私密金鑰 (只有簽署者知道) 與公開金鑰 (每個人都可以知道) 的組合。 權杖也可以進行加密。
由於私密金鑰,無法竄改已簽署的權杖。 公開金鑰:
- 可以驗證權杖,以確保權杖未被變更。
- 保證其是由持有私密金鑰的實體所產生。
使用權杖的主要缺點是這些權杖需要服務 (通常為 OIDC 伺服器) 來發出權杖並提供權杖驗證。 您必須安裝、設定和維護此服務。
需要 OIDC 伺服器的常見原因是應用程式會公開其他應用程式所取用的 Web 型 API。 針對公開的 Web 型 API,單頁應用程式 (SPA)、行動用戶端和桌面用戶端等用戶端 UI 會被視為相同應用程式的一部分。 SPA 範例包括 Angular、React 和 Blazor WebAssembly。 如果您的 Web 應用程式以外的應用程式或任何用戶端 UI 必須對您的應用程式進行安全的 API 呼叫,您可能想要使用權杖。 如果您只有用戶端 UI,ASP.NET Core Identity 會提供在驗證期間獲得權杖的選項。 ASP.NET Core Identity 所發出的驗證權杖:
- 行動和桌面用戶端可以使用。 基於安全性與簡單性,Cookie 優先於權杖。
- 不適合從協力廠商應用程式管理存取權。
需要 OIDC 伺服器的另一個原因,就是與其他應用程式共用登入。 這項功能通常稱為「單一登入」,可讓使用者:
- 使用 Web 應用程式的表單登入一次。
- 使用產生的認證搭配其他應用程式進行驗證,而不必再次登入或選擇不同的密碼。
OIDC 伺服器通常偏好提供安全且可調整的解決方案進行單一登入。
對於未與其他應用程式共用登入的應用程式,快速保護應用程式的最簡單方式,就是使用內建的 ASP.NET Core Identity 提供者。 否則,需要協力廠商身分識別管理解決方案所提供的 OIDC 伺服器。 OIDC 伺服器可以用作:
- 您在伺服器上安裝的產品,稱為「自我裝載」。
- 容器會在 Docker 之類的主機中執行。
- 您與其整合以管理身分識別的 Web 型服務。
有些解決方案是免費的開放原始碼,有些解決方案則以商業方式授權。 如需可用選項的清單,請參閱身分識別管理解決方案。 您的組織可能已使用識別提供者。 在此情況下,合理的做法可能是使用現有的提供者,而不是使用不同的解決方案。 所有主要解決方案都會提供文件,用於將 ASP.NET Core 設定為使用其產品或服務。
中斷連線的案例
許多解決方案 (例如 Microsoft Entra ID) 都是雲端式解決方案,且需要網際網路連線才能運作。 如果您的環境不允許網際網路連線,您將無法使用服務。
ASP.NET Core Identity 在中斷連線的情況下運作得非常好,例如:
- 應用程式無法存取網際網路。
- 即使網際網路中斷連線,應用程式仍須在區域網路上運作。
如果您需要完整 OIDC 伺服器用於中斷連線案例,請選擇下列其中一個選項:
- 一種解決方案,可讓您在自己的電腦上安裝和執行服務。
- 以容器形式在本機執行驗證服務。
決定儲存使用者資料 (例如登入) 的位置
另一個要考慮的重要因素是儲存使用者登入資料的位置。 許多開發人員會選擇外部雲端式服務 (例如 Microsoft Entra ID) 來管理身分識別。 雲端式服務提供者:
- 負責安全地儲存資料。
- 使用最新的安全性修補檔和版本,讓軟體保持最新狀態。
- 遵守隱私權法規。
由於法規、合規性、原則或其他原因,其他人偏好將資料儲存在自己的伺服器上。
如果資料儲存在您的伺服器上,您最可能需要選擇可安裝或容器型解決方案。
Identity 與 OIDC 伺服器
使用下圖來協助您決定是要使用 ASP.NET Core Identity 系統,還是 OIDC 伺服器進行驗證和授權:
下表列出選擇您的身分識別管理解決方案時要考慮的一些事項。
功能 | 自我裝載 (基礎結構或容器) | 雲端 |
---|---|---|
應用程式整合 | 實作為程式庫或架構的本機解決方案通常可以直接在您自己的應用程式中進行整合。 容器型解決方案需要在 Web 應用程式與容器型服務之間進行交接。 | 雲端式解決方案通常會在登入流程中的特定點整合,並提供設定來更新 UI 以符合您的佈景主題,但可用的自訂層級會受到限制。 |
Configuration | 除了設定您想要如何管理身分識別之外,自我裝載解決方案還需要針對環境設定軟體。 容器型解決方案通常會提供 Web 型 UI 進行設定。 | 雲端式解決方案通常會提供 Web 型 UI 進行設定。 |
自訂 | 自我裝載解決方案通常可高度自訂,包括程式碼型變更。 雖然容器化解決方案提供擴充性選項,但其通常受到更多的限制。 | 雲端式服務允許自訂,但通常限制為設定型變更。 |
維護 | 已安裝的產品需要專用資源,確保以及時的方式套用所有安全性修補檔,以及管理升級。 容器的升級和修補過程通常衝突較小,且僅涉及安裝提供的容器映像。 | 服務提供者會維護其雲端式解決方案,包括套用所需的修補檔和處理升級。 |
使用者認證儲存體 | 您負責資料治理和處理缺口。 | 管理與處理使用者認證相關聯的風險,並遵守法規。 委派給服務提供者。 |
如需可用選項的詳細資訊,請參閱 ASP.NET Core 的Identity管理解決方案。