Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Travailler avec les sources d'identité OIDC
<a name="identity-sources-oidc"></a>

Vous pouvez également configurer n'importe quel IdP OpenID Connect (OIDC) conforme comme source d'identité d'un magasin de politiques. Les fournisseurs OIDC sont similaires aux groupes d'utilisateurs d'Amazon Cognito : ils JWTs produisent leurs produits en tant que produit d'authentification. Pour ajouter un fournisseur OIDC, vous devez fournir l'URL de l'émetteur

Une nouvelle source d'identité OIDC nécessite les informations suivantes :
+ URL de l'émetteur. Les autorisations vérifiées doivent être en mesure de découvrir un `.well-known/openid-configuration` point de terminaison à cette URL.
+ Enregistrements CNAME qui n'incluent pas de caractères génériques. Par exemple, ne `a.example.com` peut pas être mappé à`*.example.net`. Inversement, ne `*.example.com` peut pas être mappé à. `a.example.net`
+ Type de jeton que vous souhaitez utiliser dans les demandes d'autorisation. Dans ce cas, vous avez choisi le **jeton d'identité**.
+ Le type d'entité utilisateur que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::User`.
+ Le type d'entité de groupe que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::UserGroup`.
+ Exemple de jeton d'identification ou définition des revendications contenues dans le jeton d'identification.
+ Préfixe que vous souhaitez appliquer à l'entité IDs utilisateur et groupe. Dans la CLI et l'API, vous pouvez choisir ce préfixe. Dans les magasins de politiques que vous créez à l'aide de l'option **Set up with API Gateway and an identity provider** ou de l'option de **configuration guidée**, Verified Permissions attribue un préfixe au nom de l'émetteur moins`https://`, par exemple. `MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`

Pour plus d'informations sur l'utilisation des opérations d'API pour autoriser les demandes provenant de sources OIDC, consultez[Opérations d'API disponibles pour l'autorisation](authorization.md#authorization-operations).

L'exemple suivant montre comment vous pouvez créer une politique qui autorise l'accès aux rapports de fin d'année aux employés du service de comptabilité, qui ont une classification confidentielle et qui ne travaillent pas dans un bureau satellite. Verified Permissions dérive ces attributs des allégations contenues dans le jeton d'identification du principal.

Notez que lorsque vous référencez un groupe dans le principal, vous devez utiliser l'`in`opérateur pour que la politique soit correctement évaluée.

```
permit(
     principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", 
     action, 
     resource in MyCorp::Folder::"YearEnd2024" 
) when { 
     principal.jobClassification == "Confidential" &&
     !(principal.location like "SatelliteOffice*")
};
```

**Topics**
+ [Création de sources d'identité OIDC Amazon Verified Permissions](oidc-create.md)
+ [Modification des sources d'identité OIDC d'Amazon Verified Permissions](oidc-edit.md)
+ [Mappage des jetons OIDC au schéma](oidc-map-token-to-schema.md)
+ [Validation du client et du public pour les fournisseurs OIDC](oidc-validation.md)