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.

# Meilleures pratiques en matière de mutualisation sur mesure
<a name="scope-based-multi-tenancy"></a>

[Amazon Cognito prend en charge les étendues OAuth 2.0 personnalisées pour les serveurs de ressources.](cognito-user-pools-define-resource-servers.md) Vous pouvez implémenter la mutualisation des clients d'applications dans les groupes d'utilisateurs pour les modèles d'autorisation machine-to-machine (M2M) avec des étendues personnalisées. La mutualisation basée sur le périmètre réduit les efforts nécessaires à la mise en œuvre de la mutualisation M2M en définissant l'accès dans le client de votre application ou dans la configuration de l'application.

 Le schéma suivant illustre une option pour la mutualisation d'une portée personnalisée. Il montre à chaque locataire un client d'application dédié qui a accès aux étendues pertinentes d'un pool d'utilisateurs.

![\[Schéma illustrant le flux des étendues personnalisées dans une architecture à locataires multiples.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-custom-scope.png)


**Quand mettre en œuvre la mutualisation personnalisée**  
 Lorsque vous utilisez une autorisation M2M avec les informations d'identification du client dans un client confidentiel. Il est recommandé de créer des serveurs de ressources exclusifs à un client d'application. *La mutualisation à périmètre personnalisé peut dépendre de la *demande ou du client.**

**En fonction de la demande**  
 Mettez en œuvre une logique d'application pour ne demander que les étendues correspondant aux exigences de votre locataire. Par exemple, un client d'application peut être en mesure de délivrer un accès en lecture et en écriture à l'API A et à l'API B, mais l'application cliente A demande uniquement l'étendue de lecture de l'API A et la portée indiquant la location. Ce modèle permet des combinaisons plus complexes d'étendues partagées entre les locataires.

**Dépendant du client**  
 Demandez toutes les étendues attribuées à un client d'application dans vos demandes d'autorisation. Pour ce faire, omettez le paramètre de `scope` requête dans votre demande adressée au[Point de terminaison de jeton](token-endpoint.md). Ce modèle permet aux clients de l'application de stocker les indicateurs d'accès que vous souhaitez ajouter à vos étendues personnalisées.

 Dans les deux cas, vos applications reçoivent des jetons d'accès dont les étendues indiquent leurs privilèges pour les sources de données dont elles dépendent. Les scopes peuvent également présenter d'autres informations à votre application :
+ Désigner le bail
+ Contribuer à l'enregistrement des demandes
+ Indiquez APIs que l'application est autorisée à interroger
+ Indiquez les vérifications initiales pour les clients actifs.

**Niveau d'effort**  
 La mutualisation sur mesure nécessite un niveau d'effort variable en fonction de l'échelle de votre application. Vous devez concevoir une logique d'application qui permette à vos applications d'analyser les jetons d'accès et de faire les demandes d'API appropriées.

 Par exemple, l'étendue d'un serveur de ressources est disponible au format`[resource server identifier]/[name]`. Il est peu probable que l'identifiant du serveur de ressources soit pertinent pour la décision d'autorisation prise par le locataire, ce qui nécessite que le nom de l'étendue soit analysé de manière cohérente.

## Exemple de ressource
<a name="scope-based-multi-tenancy-example"></a>

 Le AWS CloudFormation modèle suivant crée un groupe d'utilisateurs pour une mutualisation personnalisée avec un serveur de ressources et un client d'application.

```
AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template illustrating scope-based multi-tenancy
Resources:
  MyUserPool:
    Type: "AWS::Cognito::UserPool"
  MyUserPoolDomain:
    Type: AWS::Cognito::UserPoolDomain
    Properties:
      UserPoolId: !Ref MyUserPool
      # Note that the value for "Domain" must be unique across all of AWS.
      # In production, you may want to consider using a custom domain.
      # See: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html#cognito-user-pools-add-custom-domain-adding
      Domain: !Sub "example-userpool-domain-${AWS::AccountId}"
  MyUserPoolResourceServer:
    Type: "AWS::Cognito::UserPoolResourceServer"
    Properties:
      Identifier: resource1
      Name: resource1
      Scopes:
        - ScopeDescription: Read-only access
          ScopeName: readScope
      UserPoolId: !Ref MyUserPool
  MyUserPoolTenantBatch1ResourceServer:
    Type: "AWS::Cognito::UserPoolResourceServer"
    Properties:
      Identifier: TenantBatch1
      Name: TenantBatch1
      Scopes:
        - ScopeDescription: tenant1 identifier
          ScopeName: tenant1
        - ScopeDescription: tenant2 identifier
          ScopeName: tenant2
      UserPoolId: !Ref MyUserPool
  MyUserPoolClientTenant1:
    Type: "AWS::Cognito::UserPoolClient"
    Properties:
      AllowedOAuthFlows:
        - client_credentials
      AllowedOAuthFlowsUserPoolClient: true
      AllowedOAuthScopes:
        - !Sub "${MyUserPoolTenantBatch1ResourceServer}/tenant1"
        - !Sub "${MyUserPoolResourceServer}/readScope"
      GenerateSecret: true
      UserPoolId: !Ref MyUserPool
Outputs:
  UserPoolClientId:
    Description: User pool client ID
    Value: !Ref MyUserPoolClientTenant1
  UserPoolDomain:
    Description: User pool domain
    Value: !Sub "https://${MyUserPoolDomain}.auth.${AWS::Region}.amazoncognito.com"
```