Trace Id is missing
跳到主要內容
Microsoft 安全性

什麼是 OIDC？

了解 OpenID Connect (OIDC)，這是一種驗證通訊協定，用於在使用者登入時驗證使用者識別以存取數位資源。

OpenID Connect (OIDC) 定義

OpenID Connect (OIDC) 是身分驗證通訊協定，其為Open Authorization (OAuth) 2.0 的延伸模組，用於標準化使用者登入存取數位服務時進行驗證及授權的流程。OIDC 提供驗證，這表示驗證使用者的身分是否屬實。OAuth 2.0 授權這些使用者可以存取哪些系統。OAuth 2.0 通常用來讓兩個不相關的應用程式共用資訊，而不會危害使用者資料。例如，許多人會使用電子郵件或社交媒體帳戶來登入第三方網站，而不是建立新使用者名稱和密碼。OIDC 也可用來提供單一登入。組織可以使用安全的身分識別和存取權管理 (IAM) 系統 (例如 Microsoft Entra ID，前身為 Azure Active Directory) 做為身分識別的主要驗證器，然後使用 OIDC 將驗證傳遞至其他應用程式。如此一來，使用者只需要使用一個使用者名稱和密碼來登入一次，就能存取多個應用程式。

 

 

OIDC 的主要構成要素

OIDC 有六個主要構成要素：

  • 驗證是驗證使用者的身分是否屬實。

  • 用戶端軟體 (例如網站或應用程式) 會要求用來驗證使用者或存取資源的權杖。

  • 信賴憑證者是使用 OpenID 提供者來驗證使用者的應用程式。  

  • 身分識別權杖包含身分識別資料，包括驗證流程的結果、使用者識別碼，以及使用者的驗證方式和時間資訊。 

  • OpenID 提供者為使用者已有帳戶的應用程式。他們在 OIDC 中的角色是驗證使用者，並傳遞該資訊給信賴憑證者。

  • 使用者是尋求不建立新帳戶或提供使用者名稱和密碼，即可存取應用程式的人員或服務。 

 

OIDC 驗證如何運作？

OIDC 驗證的運作方式是允許使用者登入單一應用程式，並接收另一個應用程式的存取權。例如，如果使用者想要在新聞網站上建立帳戶，他們可以選擇使用 Facebook 來建立自己的帳戶，而不是在新聞網站上建立新帳戶。如果選擇 Facebook，他們使用的便是 OIDC 驗證。Facebook (稱為 OpenID 提供者) 會處理驗證流程，並取得使用者同意，以提供特定資訊 (例如使用者設定檔) 給新聞網站 (即信賴憑證者)。 

識別碼權杖 

OpenID 提供者使用識別碼權杖將驗證結果和任何相關資訊傳送至信賴憑證者。傳送的資料類型範例包括識別碼、電子郵件地址和名稱。

範圍

範圍定義使用者可以使用存取權執行的操作。OIDC 提供標準範圍來定義為其產生權杖的信賴憑證者、產生權杖的時間、權杖過期的時間，以及用於對使用者進行驗證的加密強度等內容。 

一般的 OIDC 驗證流程包括下列步驟：

  1. 使用者前往要存取的應用程式 (信賴憑證者)。
  2. 使用者輸入其使用者名稱和密碼。
  3. 信賴憑證者傳送要求給 OpenID 提供者。
  4. OpenID 提供者驗證使用者的認證並取得授權。
  5. OpenID 提供者傳送身分識別權杖和存取權杖給信賴憑證者。
  6. 信賴憑證者將存取權杖傳送至使用者的裝置。
  7. 根據存取權杖和信賴憑證者提供的資訊給予使用者存取權。 

OIDC 流程為何？

OIDC 流程定義如何要求權杖及傳遞給信賴憑證者。以下提供一些範例：

  • OIDC 授權流程：OpenID 提供者傳送獨一無二的代碼給信賴憑證者。信賴憑證者接著將獨一無二的代碼傳送回 OpenID 提供者，以交換權杖。使用此方法，OpenID 提供者可以在傳送權杖之前驗證信賴憑證者。瀏覽器在這個方法中看不到權杖，這有助於保護其安全。

  • 具有 PKCE 延伸模組的 OIDC 授權流程：此流程與 OIDC 授權流程相同，只是會使用公開金鑰進行代碼交換 (PKCE) 延伸模組以雜湊傳送通訊。這樣可減少權杖遭攔截的機會。

  • 用戶端認證：此流程使用應用程式本身的身分識別提供 Web API 的存取權。這通常用於伺服器對伺服器通訊，以及不需要使用者互動的自動化指令碼。

  • 裝置代碼：此流程可讓使用者在沒有瀏覽器或鍵盤體驗不佳 (例如智慧電視) 的網際網路連線裝置上登入及存取 Web API。 

由於存在安全性風險，因此不建議使用其他流程，例如專為瀏覽器型應用程式設計的 OIDC 隱含流程。

OIDC 與OAuth 2.0

OIDC 建立在 OAuth 2.0 上，用於新增驗證。OAuth 2.0 通訊協定較早開發，然後新增 OIDC 以增強其功能。兩者的差異在於 OAuth 2.0 提供授權，而 OIDC 則提供驗證。OAuth 2.0 能讓使用者使用其帳戶和 OpenID 提供者存取信賴憑證者，而 OIDC 能讓 OpenID 提供者將使用者設定檔傳遞給信賴憑證者。OIDC 也可讓組織為使用者提供單一登入。

 

 

OIDC 驗證的優點

OIDC 減少使用者存取應用程式所需的帳戶數目，為個人和組織提供諸多好處：

  • 降低密碼遭竊的風險

    使用者需要使用多個密碼來存取工作和個人生活所需的應用程式時，通常會挑選容易記住的密碼 (例如Password1234!)，然後在多個帳戶使用相同的密碼。這會增加惡意執行者猜中密碼的風險。一旦他們知道一個帳戶的密碼，也可以存取其他帳戶。減少使用者必須記住的密碼數目能增加使用更強大、更安全密碼的可能性。

  • 增強安全性控制項

    透過在單一應用程式中集中驗證，組織也可以使用強大的存取控制保護多個應用程式的存取權。OIDC 支援雙重要素驗證和多重要素驗證，要求人員至少使用下列其中兩項來驗證其身分：

    • 使用者知道的資訊 (通常是密碼)。

    • 使用者持有的物品，例如手機或權杖等不易複製的受信任裝置。 

    • 使用者的身體特徵，例如指紋或臉部掃描。

    多重要素驗證是一種經證實的方法，可減少帳戶入侵。組織也可以跨多個應用程式使用 OIDC 來應用其他安全性措施，例如特殊存取權管理、密碼保護、登入安全性或身分識別保護。 

  • 簡化使用者體驗

    一天中登入多個帳戶對人員來說可能很耗時且令人挫折。此外，如果他們遺失或忘記密碼，重設密碼可能會中斷生產力。使用 OIDC 為員工提供單一登入的企業可協助確保員工在生產工作上花費更多時間，而不是嘗試取得應用程式的存取權。如果客戶允許個人使用其 Microsoft、Facebook 或 Google 帳戶登入，則使用者更有可能註冊及使用其服務。 

  • 標準化驗證

    包括 Microsoft 和 Google 在內的知名品牌的 OpenID Foundation 都已建置 OIDC。其設計為可交互作業，並支援許多平台和程式庫，包括 iOS、Android、Microsoft Windows，以及主要雲端和識別提供者。

  • 簡化身分識別管理

    使用 OIDC 為員工和合作夥伴提供單一登入的組織可以減少需要管理的身分識別管理解決方案數目。這可讓組織更輕鬆地追蹤變更的權限，並讓系統管理員使用單一介面將存取原則與規則套用至多個應用程式。使用 OIDC 允許人員使用 OpenID 提供者來登入其應用程式的公司能減少需要管理的身分。 

OIDC 範例和使用案例

許多組織使用 OIDC 提供 Web 與行動應用程式的安全驗證。以下提供一些範例：

  • 使用者註冊 Spotify 帳戶時，系統提供三個選項：使用 Facebook 註冊、使用 Google 註冊、使用您的電子郵件地址註冊。選擇使用 Facebook 或 Google 註冊的使用者正在使用 OIDC 來建立帳戶。系統會將使用者重新導向至所選的任何 OpenID 提供者 (Google 或 Facebook)，一旦他們註冊，OpenID 提供者就會傳送 Spotify 基本設定檔詳細資料。使用者不需要為 Spotify 建立新帳戶，且其密碼仍受到保護。

  • LinkedIn 也提供使用者使用 Google 帳戶建立帳戶的方式，而不必另外為LinkedIn 建立帳戶。 

  • 公司希望為因工作需要存取 Microsoft Office 365、Salesforce、Box 和 Workday 的員工提供單一登錄。公司使用 OIDC 提供這四種應用程式的存取權，而不是要求員工為每個應用程式建立個別帳戶。員工建立一個帳戶，每次登入時，就能存取工作所需的所有應用程式。  

針對安全驗證實作 OIDC

OIDC 提供驗證通訊協定，可簡化使用者的登入體驗並增強安全性。對於想鼓勵客戶註冊其服務，卻想省去管理帳戶的企業來說，這是一個很棒的解決方案。這也讓組織能為員工和其他使用者提供多個應用程式的安全單一登入。組織可以使用支援 OIDC (例如 Microsoft Entra) 的身分識別與存取解決方案，在單一位置管理其所有身分識別與驗證安全原則。

   

 

深入了解 Microsoft 安全性

常見問題集

  • OIDC 是一種身分識別驗證通訊協定，可與 OAuth 2.0 一起運作，以標準化使用者登入存取數位服務時驗證及授權的流程。OIDC 提供驗證，這表示驗證使用者的身分是否屬實。OAuth 2.0 授權這些使用者可以存取哪些系統。OIDC 和 OAuth 2.0 通常用來讓兩個不相關的應用程式共用資訊，而不會危害使用者資料。 

  • OIDC 和安全性聲明標記語言 (SAML) 都是身分識別驗證通訊協定，可讓使用者安全地登入一次並存取多個應用程式。SAML 是一種較舊的通訊協定，已廣泛用於單一登入。它使用 XML 格式傳輸資料。OIDC 是較新的通訊協定，使用 JSON 格式來傳輸使用者資料。由於 OIDC比 SAML 更容易執行，而且更適用於行動應用程式，因此越來越熱門。

  • OIDC 代表 OpenID Connect 通訊協定，這是一種身分識別驗證通訊協定，用來讓兩個不相關的應用程式共用使用者設定檔資訊，而不會危害使用者認證。

  • OIDC 建立在 OAuth 2.0 上，用於新增驗證。OAuth 2.0 通訊協定較早開發，然後新增 OIDC 以增強其功能。兩者的差異在於 OAuth 2.0 提供授權，而 OIDC 則提供驗證。OAuth 2.0 能讓使用者使用其帳戶和 OpenID 提供者存取信賴憑證者，而 OIDC 能讓 OpenID 提供者將使用者設定檔傳遞給信賴憑證者。此功能也可讓組織為使用者提供單一登入。OAuth 2.0 和 OIDC 流程類似，只是使用稍微不同的術語。 

    一般的 OAuth 2.0 流程有下列步驟：

    1. 使用者前往要存取的應用程式 (資源伺服器)。
    2. 資源伺服器會將使用者重新導向至他們擁有帳戶的應用程式 (用戶端)。
    3. 使用者使用用戶端的認證來登入。
    4. 用戶端驗證使用者的存取權。
    5. 用戶端傳送存取權杖至資源伺服器。
    6. 資源伺服器授予使用者存取權。

    一般的 OIDC 流程有下列步驟：

    1. 使用者前往要存取的應用程式 (信賴憑證者)。
    2. 使用者輸入其使用者名稱和密碼。
    3. 信賴憑證者傳送要求給 OpenID 提供者。
    4. OpenID 提供者驗證使用者的認證並取得授權。
    5. OpenID 提供者傳送身分識別權杖和存取權杖給信賴憑證者。
    6. 信賴憑證者將存取權杖傳送至使用者的裝置。
    7. 根據存取權杖和信賴憑證者提供的資訊給予使用者存取權。 

  • OpenID 提供者使用識別碼權杖將驗證結果和任何相關資訊傳送至信賴憑證者應用程式。傳送的資料類型範例包括識別碼、電子郵件地址和名稱。

追蹤 Microsoft 365