公用用戶端和機密用戶端應用程式
Microsoft 驗證程式庫 (MSAL) 會定義兩類用戶端：公用用戶端和機密用戶端。 用戶端是軟體實體，其具有識別提供者指派的唯一標識碼。 可透過授權伺服器安全驗證用戶端類型，以及保存敏感性的身分識別證明資訊，以便使用者無法在其存取範圍內存取或知道該資訊。
| 公用用戶端應用程式 | 機密用戶端應用程式 |
|---|---|
 傳統型應用程式 |
 Web 應用程式 |
 無瀏覽器 API |
 Web API |
 行動裝置應用程式 |
服務/精靈 |
公用用戶端和機密用戶端授權
檢查指定用戶端的公用或機密性質時，我們會評估該用戶端向授權伺服器證明其身分識別的能力。 這很重要，因為授權伺服器必須能夠信任用戶端的身分識別，才能發出存取令牌。
公用用戶端應用程式 在傳統型、無瀏覽器 API、行動裝置或用戶端瀏覽器應用程式等裝置上執行。 不能信任這些應用程式可以安全地保存應用程式祕密，因此只會代表使用者存取 Web API。 每當指定應用程式的來源或已編譯位元組程序代碼, 在可讀取、反組譯或由未受信任方檢查的任何位置傳輸時，它是公用用戶端。 由於它們同樣僅支援公用用戶端流程，公用用戶端無法保存設定時間祕密，因此無法有用戶端密碼。
機密用戶端應用程式是在伺服器上執行的應用程式，例如 Web 應用程式、Web API 應用程式，或是服務/精靈應用程式。 用戶或攻擊者會將其視為難以存取，因此可以充分保存設定時間秘密，以判斷其身分識別的證明。 用戶端識別碼是透過網頁瀏覽器公開，但祕密只會在後端通道中傳遞，而且絕對不會直接公開。
何時應該啟用允許應用程式註冊中的公用用戶端流程？
在判斷您要建置的用戶端應用程式類型之後，您可以決定是否要在應用程式註冊中啟用公用用戶端流程。 根據預設，除非您或開發人員正在建置公用用戶端應用程式，並使用下列 OAuth 授權通訊協定或功能，否則應該停用應用程式註冊中的公用用戶端流程：
| OAuth 授權通訊協定/功能 | 公用用戶端應用程式的類型 | 範例/附註 |
|---|---|---|
| 原生驗證 | Microsoft Entra 外部 ID 需要完整自定義使用者介面的應用程式，包括設計元素、標誌放置和版面配置，以確保一致且品牌的外觀。 | 注意：原生驗證僅適用於 Microsoft Entra 外部 ID 租使用者中的應用程式註冊。 請於此處深入了解 |
| 裝置碼流程 | 在輸入限制裝置上執行的應用程式，例如智慧型手機電視、IoT 裝置或印表機 | |
| 資源擁有者密碼認證流程 | 處理密碼使用者直接輸入的應用程式，而不是將使用者重新導向至 Entra 託管的登入網站，並讓 Entra 以安全的方式處理用戶密碼。 | Microsoft建議您不要使用 ROPC 流程。 在大部分情況下，有更安全的替代方案，例如授權碼流程，可供使用並建議使用。 |
| Windows 整合式驗證流程 | 使用 Windows 整合式驗證流程，而不是 Web 帳戶管理員，在 Windows 或連線到 Windows 網域的電腦上執行桌面或行動應用程式（Microsoft Entra 標識符或已加入Microsoft Entra） | 使用者已使用 Microsoft Entra 認證登入 Windows 計算機系統之後，應該自動登入的桌面或行動應用程式 |
秘密及其在證明身分識別方面的重要性
以下是用戶端如何向授權伺服器證明其身分識別的部分範例：
- Azure 資源受控識別 – 針對僅限應用程式驗證案例，在 Azure 上建置的應用程式和服務開發人員可以選擇將秘密管理、輪替和保護卸除給平台本身。 使用受控識別時，會使用 Azure 資源提供和刪除身分識別，且包括 全域管理員 在內沒有人可以存取基礎認證。 使用受控識別可以防止洩漏秘密的風險，並且讓提供者為您處理安全性。
- 用戶端識別碼和秘密 – 在此模式中，註冊用戶端時，授權伺服器會產生一對值。 用戶端識別碼是識別應用程式的公用值，而用戶端密碼是用來證明應用程式身分識別的機密值。
- 證明擁有憑證 - 公開金鑰基礎結構（PKI），包括 X.509 等標準，是能夠透過網際網路安全通訊並形成網際網路隱私權骨幹的基本技術。 PKI 可用來發行數位憑證，以驗證參與線上通訊之各方的身分識別，而且是支援 HTTPS 等通訊協定的基礎技術，該通訊協定廣泛用於保護網路流量。 同樣地，憑證可用來保護 Azure 中的服務對服務 (S2S) 通訊，方法是在服務之間啟用相互驗證。 這牽涉到每個服務將憑證呈現給另一個服務，以證明其身分識別的方式。
- 已簽署–判斷提示呈現，在工作負載身分識別同盟中使用已簽署判斷提示，可讓信任的第三方識別提供者權杖與 Microsoft 身分識別平台交換，以取得存取權杖來呼叫 Microsoft Entra 受保護的資源。 工作負載身分識別同盟可用來啟用各種同盟案例，包括 Azure Kubernetes Service、Amazon Web Services EKS、GitHub Actions 等等。
證明用戶端身分識別何時很重要？
證明用戶端身分識別在授與敏資料或資源的存取權之前，需要驗證用戶端應用程式的真實性和授權時很重要。 這些範例包含：
- 控制 API 存取 – 如果您有計量付費的 API（例如計費），或公開敏感資料或資源，您必須先驗證用戶端的身分識別，再授與存取權。 例如，這在確保只有授權的應用程式可以存取 API 時很重要，且正確的客戶會針對其計量 API 使用量計費。
- 保護使用者免受應用程式模擬 – 如果您有服務部署、供使用者使用的應用程式（例如後端驅動 Web 應用程式）存取敏感資料或服務，使用用戶端密碼來保護該應用程式所使用的資源，可能會防止不良執行者模擬合法用戶端給網路釣魚使用者，並且外泄資料或濫用存取權。
- S2S 通訊 – 如果您有多個需要彼此通訊的後端服務（例如下游 API），您可以驗證每個服務的身分識別，以確保它們只能存取必要的資源來執行其功能。
一般而言，證明用戶端身分識別在需要驗證和授權與用戶無關或以外的用戶端時很重要。
機密用戶端：管理秘密的最佳做法
使用受控識別來簡化部署和安全性 - 受控識別在 Microsoft Entra ID 中提供自動受控識別，讓應用程式在連結到支援 Microsoft Entra 驗證的資源時使用。 應用程式可以使用受控識別來取得 Microsoft Entra ID 僅限應用程式權杖，而無需管理認證。 這樣可以省去許多與秘密管理有關的複雜度，同時提高安全性和復原能力。 如果您使用受控識別，則以下大部分 (如果不是全部) 的最佳做法都已經為您處理。
使用安全儲存體 – 將用戶端密碼儲存在安全位置，例如 Key Vault 或 加密組態檔。 請避免將客戶端密碼儲存為純文字或簽入檔案至版本控制系統。
限制存取 - 將用戶端密碼的存取限制為僅限授權人員。 使用 角色型存取控制 ，將客戶端密碼的存取限制為僅需要客戶端密碼來執行其作業職責的人員。
輪替用戶端密碼 – 視需要或排程輪替用戶端密碼，可以將降低使用遭入侵的機密來獲得未經授權的存取的風險降到最低。 套用時，建議金鑰繼續使用的時間範圍會受到所使用的密碼編譯演算法強度和/或遵守標準或法規做法的影響。
使用長秘密和增強式加密 – 與上一點密切相關，針對傳輸中資料（在網路上）和待用資料（磁碟上）使用增強式加密演算法，有助於確保高度加密的秘密仍不太可能受到暴力破解。 AES-128（或更高版本）等演演算法有助於保護待用資料，而 RSA-2048 （或更高版本）則有助於有效率地保護傳輸中的資料。 由於網路安全性的本質不斷演變，建議最好諮詢您的安全性專家與定期檢閱您選擇使用的演算法。
避免硬式編碼秘密， – 不要在原始程式碼中硬式編碼客戶端密碼。 避免原始程式碼中的秘密可將不良執行者取得原始程式碼存取權的值降到最低。 它也可以避免這類秘密意外被推送至不安全的存放庫，或是提供給可能具有來源存取權，但無法存取秘密的專案參與者使用。
監視洩露秘密的存放庫 - 可惜在處理原始程式碼時會發生錯誤簽入的情況。 Git 預先認可攔截是防止意外簽入的建議方式，但也不是用來替代監視的辦法。 自動監視存放庫可以識別洩露的秘密，並且透過計劃輪替遭入侵的認證，有助於減少安全性事件。
監視可疑活動 – 監視 與客戶端密碼有關可疑活動的記錄和稽核線索。 盡可能使用自動化警示和回應流程通知人員，並且訂定與用戶端密碼有關的異常活動應變方式。
在建立應用程式時牢記客戶端保密性 — 您的安全性模型強度取決於鏈中最薄弱的環節。 請勿將安全性認證或權杖從機密轉送至公用用戶端，因為這可能會將用戶端密碼資料移至公用用戶端，以模擬機密用戶端。
使用來自受信任來源的最新程式庫和 SDK – Microsoft 身分識別平台提供各種用戶端和伺服器 SDK 和中介軟體，其設計目的是提升您的生產力，同時保護應用程式的安全。 Microsoft.Identity.Web 等程式庫簡化在 Microsoft 身分識別平台上將驗證和授權新增至 Web 應用程式和 API 的作業。 不斷更新相依性有助於確保您的應用程式和服務受益於最新的安全性創新和更新。
比較客戶端類型及其功能
以下是公用和機密用戶端應用程式之間的一些相似之處和差異：
- 這兩類應用程式都會維護使用者權杖快取，而且可以透過無訊息方式取得權杖 (當權杖已經在快取中時)。 機密用戶端應用程式也有應用程式權杖快取，適用於應用程式本身取得的權杖。
- 這兩類應用程式都會管理使用者帳戶，而且從使用者權杖快取取得帳戶、從其識別碼取得帳戶，或移除帳戶。
- 在 MSAL，公用用戶端應用程式有四種透過獨立驗證流程取得權杖的方式。 機密用戶端應用程式只有三種方式可取得權杖 ，以及用來計算識別提供者授權端點 URL 的一種方式。 在建構應用程式時會一次傳遞 用戶端標識碼 ，而且在應用程式取得權杖時無需再次傳遞。 如需詳細資訊，請參閱 取得權杖。
公用客戶端對於啟用使用者委派存取受保護的資源時可以派上用場，但無法證明自己的應用程式身分識別。 另一方面，機密用戶端可以同時執行使用者和應用程式驗證和授權，而且必須考慮到安全性，以確保其秘密不會分享給公用用戶端或其他第三方。
在某些情況下，例如 S2S 通訊，受控識別的基礎結構可大幅簡化開發與部署服務事宜，並且省去通常與秘密管理有關的許多複雜度。 無法使用受控識別時，’請務必備妥原則、預防措施和應變措施，以保護秘密，並且回應與其有關的安全性事件。
另請參閱
如需應用程式設定和具現化的詳細資訊，請參閱：