Práticas recomendadas de multilocação por escopo personalizado - Amazon Cognito
Exemplo de recurso

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Práticas recomendadas de multilocação por escopo personalizado

O Amazon Cognito oferece suporte a escopos OAuth 2.0 personalizados para servidores de recursos. Você pode implementar a multilocação de clientes de aplicativos em grupos de usuários para modelos de autorização machine-to-machine (M2M) com escopos personalizados. A multilocação baseada em escopo reduz o esforço necessário para implementar a multilocação M2M ao definir o acesso no cliente de aplicação ou na configuração da aplicação.

nota

Atualmente, você não pode personalizar tokens de acesso para adicionar reivindicações ou escopos personalizados nos fluxos de autorização de credenciais do cliente (M2M).

O diagrama a seguir ilustra uma opção para multilocação de escopo personalizado. Ele mostra cada locatário com um cliente de aplicação dedicado que tem acesso aos escopos relevantes em um grupo de usuários.

Um diagrama que ilustra o fluxo de escopos personalizados em uma arquitetura multilocatários.
Quando implementar a multilocação de escopos personalizados

Quando seu uso é autorização M2M com credenciais de cliente em um cliente confidencial. Como prática recomendada, crie servidores de recursos exclusivos para um cliente de aplicação. A multilocação de escopo personalizado pode depender da solicitação ou do cliente.

Dependente da solicitação

Implemente a lógica de aplicação para solicitar somente os escopos que correspondam aos requisitos do seu locatário. Por exemplo, um cliente de aplicação pode emitir acesso de leitura e gravação à API A e à API B, mas a aplicação de locatário A solicita somente o escopo de leitura da API A e o escopo que indica locação. Esse modelo permite combinações mais complexas de escopos compartilhados entre locatários.

Dependente do cliente

Solicite todos os escopos atribuídos a um cliente de aplicação em suas solicitações de autorização. Para fazer isso, omita o parâmetro de solicitação scope da solicitação para o Endpoint de token. Esse modelo permite que os clientes de aplicação armazenem os indicadores de acesso que você deseja adicionar aos escopos personalizados.

Nos dois casos, suas aplicações recebem tokens de acesso com escopos que indicam seus privilégios para as fontes de dados das quais dependem. Os escopos também podem apresentar outras informações à aplicação:

  • Designar a locação

  • Contribuir com o registro de solicitações

  • APIs Indique que o aplicativo está autorizado a consultar

  • Informar as verificações iniciais para clientes ativos.

Nível de esforço

A multilocação com escopo personalizado exige um nível variável de esforço em relação à escala da sua aplicação. Você deve criar uma lógica de aplicação que permita que as aplicações analisem tokens de acesso e façam as solicitações de API apropriadas.

Por exemplo, um escopo de servidor de recursos vem no formato [resource server identifier]/[name]. É improvável que o identificador do servidor de recursos seja relevante para a decisão de autorização do escopo do locatário, exigindo que o nome do escopo seja analisado de forma consistente.

Exemplo de recurso

O AWS CloudFormation modelo a seguir cria um grupo de usuários para multilocação de escopo personalizado com um servidor de recursos e um cliente de aplicativo.

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"