驗證和授權的基本知識

驗證和授權在大部分應用程式套件中起到重要作用。本頁提供了相關概念和術語的概覽。如果您不熟悉該主題或者想要回顧複習，這些內容將很有幫助。如果您對自己的整體理解有信心，您可以繼續學習如何在 CXone 中驗證和授權。

當使用者登入任何應用程式套件（包括 CXone）時，一般會按順序顯示以下兩個步驟：

所有使用者必須通過驗證並取得授權，然後才能存取 CXone。

使用者可以是人員或應用程式。例如，聊天機器人和虛擬助理通常由使用者帳戶執行。大部分應用程式套件都對真人和虛擬使用者使用相同的流程。在關於驗證和授權的線上說明頁面中，我們將人員和應用程式統一稱作使用者。若有差異，會有明確說明。

從使用者的角度，他們只是登入。而驗證和授權會在後台執行，以確保其登入成功。登入開始時，使用者均未通過驗證。這表示系統並不知道他們的身分。登入結束時，使用者都進行了驗證並取得授權。這表示系統現在知道是哪些使用者在登入，他們需要哪些存取權限。

系統會執行下列操作，以驗證使用者並授權：

確定要使用哪種驗證流程（若支援多種）。很多系統都支援多種驗證方式。例如，系統可以透過使用者名稱及密碼、單一登入或多重要素驗證 (MFA)。通常，使用者可從登入頁面上的驗證選項清單中選擇，但系統會在必要時要求使用特定驗證流程。
收集驗證認證（例如，要求使用者輸入使用者名稱和密碼）。
使用身分識別提供者驗證認證。身分識別提供者是一種單獨的系統，用於保留使用者及其身分的資訊，包括其認證。
授權已驗證的個人或程式。使用者通過驗證後，系統會使用授權伺服器為使用者授予存取權。系統將根據使用者的角色和權限收取存取權。系統僅會授予使用者存取他們有權查看或使用的功能。

驗證相關術語

身分識別提供者 (IdP) 是指建立使用者身分資訊的系統，可能是：

IdP 可以託管或基於雲端。Microsoft ADFS 和 Shibboleth 是常見的託管 IdP。Microsoft Azure AD、Okta 和 Ping 等則是雲端 IdP。

驗證通訊協定用於在應用程式和 IdP 之間或不同 IdP 之間建立通訊。常見的驗證通訊協定有 OpenID Connect 和 SAML 2.0。有些驗證通訊協定提供附加功能，例如加密，但應用程式可能會或不會使用這些功能。如果系統使用了內建的 IdP，則不會考慮驗證通訊協定。

大部分外部 IdP 都支援以下一種或兩種驗證流程：

聯合身分管理有時也稱為 FIM 或聯合，是使用單一外部 IdP 為一或多個應用程式提供驗證的流程的總稱。聯合身分管理通常在某種程度上有時間限制。例如，使用者可以在開始登入時登入一次。這將向他們每天使用的所有應用程式驗證其身分。但是，即使使用者前一天沒有登出，第二天也必須重新登入以重新驗證身分。

單一登入 (SSO) 用於透過一次登入提供多個應用程式的存取權限。例如，使用者登入 Microsoft 365 後，將取得公司授權其使用的所有 Microsoft 應用程式的存取權。SSO 一詞有時也用於聯合身分管理，雖然兩者的概念不完全相同。

多重要素驗證 (MFA) 在使用者名稱/密碼驗證的基礎之上，增加了一層安全性。MFA 要求使用者輸入驗證碼、回答問題或使用權標來使 IdP 確認其能否通過身分驗證。

在身分驗證中，信任是指應用程式或系統與外部 IdP 共用的資訊或知識。這種知識在兩者之間建立了一種關係，因此雙方均知道與對方的通訊準確而真實。建立信任的方式因驗證通訊協定而異。以下範例基於 OpenID Connect 和 SAML 2.0。

OpenID Connect

OpenID Connect 中的信任基於簽發者。簽發者是一個類似於 URL 的值，用於建立身分識別提供者。例如，Google 支援 OpenID Connect，簽發者為 https://accounts.google.com。

基於簽發者，還有幾個附加配置項。例如在 OpenID Connect 中，透過簽署公用/私人認證建立信任。它使用的是被稱為 JWKS 的行業標準。因此，部分配置決定了如何獲得這些公用認證。

大部分身分識別提供者都支援發現此資訊，只需在簽發者中附加 /.well-known/openid-configuration 即可。Google 發現文件位於 https://accounts.google.com/.well-known/openid-configuration。

SAML 2.0

在 SAML 2.0 中，信任基於實體識別碼。與 OpenID Connect 不同的是，實體識別碼與其他配置值之間沒有很強的聯繫。有幾個配置參數可用於與 SAML 2.0 建立信任：