本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 Amazon Verified Permissions 進行授權

Amazon Verified Permissions 是一項授權服務，適用於您建置的應用程式。當您新增 Amazon Cognito 使用者集區做為身分來源時，您的應用程式就可以將使用者集區存取權或身分 (ID) 權杖傳遞給 Verified Permissions 以決定允許或拒絕。Verified Permissions 會根據您使用 Cedar 政策語言撰寫的政策來考量您使用者的屬性和請求內容。請求內容可包括所請求文件、影像或其他資源的識別符，以及您的使用者想要對資源執行的動作。

您的應用程序可以在或BatchIsAuthorizedWithTokenAPI請求中向「已驗證權限」提供用戶的身份IsAuthorizedWithToken或訪問令牌。這些API作業會接受您的使用者，Principal並針對他們想要存取Action的Resource項目做出授權決定。其他自訂Context可以有助於詳細的存取決策。

當您的應用程序在IsAuthorizedWithTokenAPI請求中顯示令牌時，「已驗證權限」會執行以下驗證。

撤銷的權杖和刪除的使用者

Verified Permissions 只會驗證從您的身分來源得知的資訊，以及您使用者的權杖到期時間資訊。Verified Permissions 不會檢查權杖是否撤銷或使用者是否存在。即使您撤銷了使用者的權杖，或是從使用者集區刪除了使用者的設定檔，在權杖過期之前，Verified Permissions 仍會將該權杖視為有效。

政策評估

將您的使用者集區設定為政策存放區的身分來源。設定讓您的應用程式在請求中提交使用者的權杖給 Verified Permissions。Verified Permissions 會針對每個請求，將權杖中的宣告與政策進行比較。驗證權限政策與中的IAM策略類似 AWS。它會宣告主體、資源和動作。Allow如果「已驗證權限」符合允許的動作且不符合明確Deny動作，則會以「驗證權限」回應您的要求；否則，它會以回應Deny。如需詳細資訊，請參閱《Amazon Verified Permissions User Guide》中的 Amazon Verified Permissions policies。

自訂權杖

若要變更、新增和移除您要呈現給已驗證權限的使用者宣告，請使用產生權杖前 Lambda 觸發程序. 使用權杖產生前觸發程序，您就可以新增和修改權杖中的宣告。例如，您可以查詢資料庫中的其他使用者屬性，並將這些屬性編碼到您的 ID 權杖中。

API使用已驗證權限授權

您的 ID 或存取權杖可以授權對RESTAPIs具有已驗證許可的後端 Amazon API 閘道的請求。您可以建立原則存放區，其中包含指向您的使用者集區和的直接連結API。使用 [使用 Cognito 和API閘道設定] 啟動選項，已驗證的權限會將使用者集區身分識別來源新增至政策存放區，並將 Lambda 授權者新增至. API 當您的應用程式將使用者集區承載權杖傳遞給時API，Lambda 授權者會叫用已驗證的權限。授權者將 Token 作為主體傳遞，並將請求路徑和方法作為動作傳遞。

下圖說明API具有已驗證權限之API閘道的授權流程。如需詳細細資料，請參閱 Amazon 驗證許可使用者指南中的API連結政策存放區。

已驗證的權限結構使用者集區群組的API授權。由於 ID 和存取權杖都包含cognito:groups宣告，因此您的原則存放區可以針對您在各種應用程式前後關聯APIs中管理以角色為基礎的存取控制 (RBAC)。

選擇策略存放區設定

在原則存放區上設定身分識別來源時，您必須選擇要處理存取權或 ID Token。這項決定對您的政策引擎的運作方式非常重要。ID 令牌包含用戶屬性。訪問令牌包含用戶訪問控制信息：OAuth範圍。雖然這兩種權杖類型都有群組成員資格資訊，但我們通常建議您使用已驗證權限原則存放區使RBAC用存取權杖。訪問令牌添加到具有範圍的組成員資格中，這些範圍可以促進授權決策。訪問令牌中的聲明成為授權請求中的上下文。

當您將使用者集區設定為身分識別來源時，也必須設定使用者和群組實體類型。實體類型是主參與者、動作和資源識別元，您可以在已驗證的權限原則中參照。原則存放區中的實體可以具有成員資格關係，其中一個實體可以是父實體的成員。有了成員資格，您就可以參照主參與者群組、動作群組和資源群組。在使用者集區群組的情況下，您指定的使用者實體類型必須是群組實體類型的成員。當您在 [已驗證的權限] 主控台中設定API連結的原則存放區或遵循 [引導式] 設定時，您的原則存放區會自動具有此父成員關係。

ID 令牌可以RBAC與基於屬性的訪問控制（）ABAC結合使用。建立API連結的原則存放區之後，您可以使用使用者屬性和群組成員資格來增強原則。ID 令牌中的屬性聲明成為授權請求中的主要屬性。您的原則可以根據主參與者屬性做出授權決策。

您也可以設定政策存放區，以接受符合您提供之可接受應用程式用戶端清單的aud或client_id宣告的權杖。

以角色為基礎的授API權範例原則

以下範例原則是由 [已驗證權限] 原則存放區的設定所建立，PetStore例如範例RESTAPI。

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

在以下情況下，已驗證的權限會返回應用程序的授權請求的Allow決定：

Amazon Cognito 使用者的政策範例

您的使用者集區也可以在要求以外的情況下，產生對已驗證權限的授權API要求。您可以將應用程式中的任何存取控制決策提交至原則存放區。例如，您可以在任何請求傳輸網路之前，使用以屬性為基礎的存取控制來補充 Amazon DynamoDB 或 Amazon S3 安全性，從而減少配額使用。

以下範例使用 Cedar 政策語言，允許透過某一個使用者集區應用程式用戶端進行驗證的財務使用者讀取和寫入 example_image.png。John 是您的應用程序中的用戶，從您的應用程序客戶端接收 ID 令牌，並將其在GET請求中傳遞給需URL要授權的 ID 令牌https://example.com/images/example_image.png。John 的 ID 權杖內有您的使用者集區應用程式用戶端 ID 1234567890example 的 aud 宣告。您的權杖產生前 Lambda 函數還針對 John 插入了一個值為 Finance1234 的新宣告 costCenter。

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

以下請求內文會產生 Allow 回應。

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

若您想要在 Verified Permissions 政策中指定主體，請使用下列格式：

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

以下是識別碼為 sub 或使用者 ID us-east-1_Example 之使用者集區中之使用者的範例主體973db890-092c-49e4-a9d0-912a4c0a20c7。

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

當您要在 [已驗證權限] 原則中指定使用者群組時，請使用下列格式：

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

下面是一個例子

屬性型存取控制

針對您的應用程式具有已驗證許可的授權，以及適用於 AWS 登入資料的 Amazon Cognito 身分集區的存取控制功能的屬性，都是以屬性為基礎的存取控制 ()。ABAC以下是「已驗證許可」和「Amazon CognitoABAC」功能的比較。在中ABAC，系統會檢查實體的屬性，並根據您定義的條件做出授權決定。