Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Kunden- und Zielgruppenvalidierung für OIDC-Anbieter
<a name="oidc-validation"></a>

Wenn Sie einem Richtlinienspeicher eine Identitätsquelle hinzufügen, verfügt Verified Permissions über Konfigurationsoptionen, mit denen überprüft wird, ob ID und Zugriffstoken wie vorgesehen verwendet werden. Diese Überprüfung erfolgt bei der Verarbeitung von `IsAuthorizedWithToken` und `BatchIsAuthorizedWithToken` API-Anfragen. Das Verhalten unterscheidet sich zwischen ID- und Zugriffstoken Amazon Cognito sowie zwischen OIDC-Identitätsquellen. Bei Anbietern von Amazon Cognito Cognito-Benutzerpools kann Verified Permissions die Client-ID sowohl in ID- als auch in Zugriffstoken validieren. Bei OIDC-Anbietern kann Verified Permissions die Client-ID in ID-Token und die Zielgruppe in Zugriffstoken validieren.

Eine *Client-ID* ist eine Kennung, die beispielsweise der Identitätsanbieter-Instanz zugeordnet ist, die Ihre Anwendung verwendet. `1example23456789` Eine *Zielgruppe* ist beispielsweise ein URL-Pfad, der der *vertrauenden Partei* oder dem Ziel des Zugriffstokens zugeordnet ist`https://mytoken.example.com`. Bei der Verwendung von Zugriffstoken ist der `aud` Anspruch immer mit der Zielgruppe verknüpft.

Für OIDC-ID-Tokens gibt es einen `aud` Anspruch, der den Client enthält IDs, z. B. `1example23456789`

OIDC-Zugriffstoken haben einen `aud` Anspruch, der die Zielgruppen-URL für das Token enthält, wie z. B., und einen `client_id` Anspruch`https://myapplication.example.com`, der den Client IDs enthält, wie z. B. `1example23456789`

Geben Sie beim Einrichten Ihres Richtlinienspeichers einen oder mehrere Werte für die **Zielgruppenvalidierung** ein, die Ihr Richtlinienspeicher verwendet, um die Zielgruppe eines Tokens zu validieren.
+ **ID-Tokens** — Verified Permissions validiert die Kunden-ID, indem überprüft wird, ob mindestens ein Mitglied des Kunden IDs im `aud` Antrag einem Wert für die Zielgruppenvalidierung entspricht.
+ **Zugriffstoken** — Verifizierte Berechtigungen validieren die Zielgruppe, indem überprüft wird, ob die URL im `aud` Anspruch mit einem Zielgruppenvalidierungswert übereinstimmt. Wenn kein `aud` Anspruch besteht, kann die Zielgruppe anhand der `client_id` Ansprüche `cid` oder bestätigt werden. Erkundigen Sie sich bei Ihrem Identitätsanbieter nach der korrekten Angabe und dem richtigen Format für die Zielgruppe.

## Clientseitige Autorisierung für JWTs
<a name="oidc-validation-other-idp"></a>

Möglicherweise möchten Sie JSON-Webtoken in Ihrer Anwendung verarbeiten und deren Ansprüche an Verified Permissions weiterleiten, ohne eine Identitätsquelle für den Richtlinienspeicher zu verwenden. Sie können Ihre Entitätsattribute aus einem JSON-Webtoken (JWT) extrahieren und in verifizierte Berechtigungen umwandeln.

Dieses Beispiel zeigt, wie Sie verifizierte Berechtigungen von einer Anwendung aus aufrufen könnten, die ein JWT verwendet¹.

```
async function authorizeUsingJwtToken(jwtToken) {
  
    const payload = await verifier.verify(jwtToken);
   
    let principalEntity = {
        entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
        entityId: payload["sub"], // the application need to use the claim that represents the user-id
    };
    let resourceEntity = {
        entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
        entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
    };
    let action = {
        actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
        actionId: "GetPhoto", //the application needs to fill in the relevant action type
    };
    let entities = {
        entityList: [],
    };
    entities.entityList.push(...getUserEntitiesFromToken(payload));
    let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
    
    const authResult = await client
        .isAuthorized({
        policyStoreId: policyStoreId,
        principal: principalEntity,
        resource: resourceEntity,
        action: action,
        entities,
        })
        .promise();
        
    return authResult; 
  
}

function getUserEntitiesFromToken(payload) {
  let attributes = {};
  let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
  Object.entries(payload).forEach(([key, value]) => {
    if (claimsNotPassedInEntities.includes(key)) {
        return;
    }
    if (Array.isArray(value)) {
      var attibuteItem = [];
      value.forEach((item) => {
        attibuteItem.push({
          string: item,
        });
      });
      attributes[key] = {
        set: attibuteItem,
      };
    } else if (typeof value === 'string') {
      attributes[key] = {
        string: value,
      } 
    } else if (typeof value === 'bigint' || typeof value ==='number') {
        attributes[key] = {
            long: value,
          } 
    } else if (typeof value === 'boolean') {
        attributes[key] = {
            boolean: value,
       } 
    }

  });

  let entityItem = {
    attributes: attributes,
    identifier: {
      entityType: "PhotoFlash::User",
      entityId: payload["sub"], // the application needs to use the claim that represents the user-id
    }
  };
  return [entityItem];
}
```

¹ In diesem Codebeispiel wird die [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)Bibliothek zur Überprüfung JWTs verwendet, die mit OIDC-kompatibel signiert wurde. IdPs