共用方式為

應用程式中的驗證與授權

  • 發行項

安全性對於現代 Web 應用程式至關重要。 流體架構是 Web 應用程式架構的一部分，對於保護基礎結構也是相當重要的部分。 流體架構是分層架構，且驗證相關概念會根據所連線的流體服務來實作。 這表示，雖然所有流體服務都有常見的驗證主題，但每個服務的詳細資料和細節會有所不同。

Azure 流體轉送服務

您建立的每個 Azure 流體轉送服務租用戶都會獲指派一個租用戶識別碼及其專屬唯一的租用戶秘密金鑰。

秘密金鑰是共用密碼。 您的應用程式/服務知道，而 Azure 流體轉送服務也知道。 由於租用戶秘密金鑰只會與租用戶唯一繫結，因此使用它來簽署要求保證給 Azure 流體轉送服務，其中要求來自租用戶的授權使用者。

秘密金鑰是 Azure 流體轉送服務知道要求來自您的應用程式或服務的方式。 這很重要，因為一旦 Azure 流體轉送服務可以信任這是您的應用程式發出的要求，它就可以信任您傳送的資料。 這也是必須安全地處理密碼的原因。

警告

有密碼存取權的任何人都可以在與 Azure 流體轉送服務通訊時模擬您的應用程式。

JSON Web 權杖與 Azure 流體轉送服務

Azure 流體轉送會使用 JSON Web 權杖 (JWT) 來編碼和驗證使用秘密金鑰簽署的資料。 JSON Web 權杖是一個已簽署的 JSON 位元，可包含權限相關的其他資訊。

注意

JWT 的特性超出本文的範圍。 如需 JWT 標準的詳細資訊，請參閱 JSON Web 權杖簡介。

雖然流體服務之間的驗證詳細資料各有不同，但一律必須擁有數個值。

  • containerId 流體服務需要容器識別碼，來識別哪些服務對應至呼叫容器。 注意：JWT 呼叫此欄位為 documentId，但流體服務期待在此欄位中看到容器識別碼。
  • tenantId：Azure 流體轉送服務使用租用戶識別碼來擷取用於驗證要求的共用密碼。
  • scopes：範圍可定義呼叫容器的權限。 範圍欄位的內容具有彈性，可讓您建立自己的自訂權限。
{
  "alg": "HS256",
  "typ": "JWT"
}.{
  "documentId": "azureFluidDocumentId",
  "scopes": [ "doc:read", "doc:write", "summary:write" ],
  "user": {
    "name": "TestUser",
    "id": "Test-Id-123"
  },
  "iat": 1599098963,
  "exp": 1599098963,
  "tenantId": "AzureFluidTenantId",
  "ver": "1.0"
}.[Signature]

使用者模式會指出連線處於讀取或是讀取/寫入模式。 這可以在 AzureAudience 的 connections 欄位中檢視。 權杖範圍權限可以在 generateToken 函式下的無伺服器 Azure 函式中更新。

const token = generateToken(
  tenantId,
  documentId,
  key,
  scopes ?? [ "Token Scope" ],
  user
);

權杖範圍以及容器行為和模式如下所示：

權杖範圍 我的文件行為 適用對象文件行為
DocRead 讀取和寫入文件。 對文件進行的變更不會反映到任何其他適用對象文件中。
模式：讀取		 讀取和寫入文件。 變更不會反映到任何其他適用對象文件中。
模式：寫入
DocWrite 讀取和寫入文件。 進行的變更會反映到所有其他適用對象文件中。
模式：寫入		 讀取和寫入文件。 進行的變更會反映到所有其他適用對象文件中。
模式：寫入
DocRead、DocWrite 讀取和寫入文件。 進行的變更會反映到所有其他適用對象文件中。
模式：寫入		 讀取和寫入文件。 進行的變更會反映到所有其他適用對象文件中。
模式：寫入

注意

請注意，權杖也包含使用者資訊 (請參閱上方第 7-9 行)。 您可以使用此功能來增強透過適用對象功能自動提供給流體程式碼的使用者資訊。 如需詳細資訊，請參閱將自訂資料新增至權杖。

權杖提供者

Azure 流體轉送的每個要求都必須以有效的 JWT 簽署。 流體會將建立和簽署這些權杖的責任委派給權杖提供者。

權杖提供者負責建立和簽署權杖，讓 @fluidframework/azure-client 用來向 Azure 流體轉送服務提出要求。 您必須提供自己的安全權杖提供者實作。 不過，流體提供可接受租用戶密碼的 InsecureTokenProvider，並在本機產生並傳回已簽署的權杖。 此權杖提供者適用於測試，但無法在生產案例中使用。

安全的無伺服器權杖提供者

建置安全權杖提供者的其中一個選項是建立無伺服器 Azure 函式，並將其公開為權杖提供者。 這可讓您將租用戶秘密金鑰儲存在安全伺服器上。 接著，您的應用程式會呼叫 Azure 函式來產生權杖，而不是像 InsecureTokenProvider 那樣本機簽署權杖。 如需詳細資訊，請參閱如何：使用 Azure 函式寫入 TokenProvider。

將使用者驗證連線至流體服務驗證

流體服務會使用共用的用戶端密碼來驗證來電，這些密碼不會綁定特定使用者。 您可以根據流體服務的詳細資料來新增使用者驗證。

使用者驗證的其中一個簡單選項是使用 Azure 函式作為權杖提供者，並強制執行使用者驗證作為取得權杖的條件。 如果應用程式嘗試呼叫函式，除非您的驗證系統通過驗證，否則將會失敗。 舉例來說，如果您使用 Microsoft Entra ID，您可以為 Azure 函式建立 Microsoft Entra 應用程式，並繫結到組織的驗證系統。

在此情況下，使用者會使用 Microsoft Entra ID 登入您的應用程式，而您會透過它取得用來呼叫 Azure 函式的權杖。 Azure 函式本身的行為相同，但現在只有同樣使用 Microsoft Entra ID 驗證的人員能存取。

由於 Azure 函式現在是取得有效權杖的進入點，因此只有已正確驗證函式的使用者，才能從其用戶端應用程式將該權杖提供給 Azure 流體轉送服務。 這個雙步驟方法可讓您搭配 Azure 流體轉送服務使用自己的自訂驗證流程。

另請參閱