Solucionar problemas do Amazon Cognito

Criar um registro A para o domínio principal: você deve criar um registro A na configuração de DNS para o domínio principal do seu domínio personalizado.

Verificar a propagação de DNS (opcional, mas recomendado): para garantir que seu provedor de DNS tenha propagado a alteração, você pode executar um comando dig.

Remover o registro A do domínio principal: após criar com sucesso o domínio personalizado no Amazon Cognito, você poderá remover o registro A criado para o domínio principal, caso seja fictício.

Para usar o nome de domínio para um novo grupo de usuários, é necessário excluir o domínio personalizado do grupo de usuários ao qual ele está associado atualmente.

Aguardar após a exclusão: leva algum tempo para o domínio personalizado ser totalmente excluído do primeiro grupo de usuários. Criar um novo domínio personalizado com o mesmo nome imediatamente após a exclusão ainda pode resultar nesse erro. Aguarde alguns minutos antes de tentar novamente.

Opção 1: use um nome de domínio diferente para seu domínio personalizado do Amazon Cognito.

Opção 2: Se você usar o nome de domínio do Amazon Cognito, não o use com outra distribuição da Amazon CloudFront .

Verificar a região do certificado: confirme se o certificado do ACM está na região us-east-1.

Verificar a validade do certificado: verifique se o certificado selecionado não está expirado.

Certificados importados: se você importou o certificado para o ACM, verifique se:

AWS KMS Verificação de política: uma deny declaração explícita em uma política AWS Key Management Service (AWS KMS) para o usuário ou função do IAM que está criando o domínio pode causar esse erro. Especificamente, verifique se há negações explícitas nas ações kms:DescribeKey, kms:CreateGrant e kms:*.

Garantir um ID do cliente da aplicação consistente: ao chamar a API AdminInitiateAuth ou InitiateAuth para atualização de token, você deve usar o mesmo ID do cliente da aplicação usado durante a autenticação inicial que gerou o token de atualização.

Confirme o dispositivo: se você tiver o rastreamento de dispositivos ativado em seu grupo de usuários, mas o dispositivo do usuário não tiver sido confirmado, você deve primeiro chamar a ConfirmDeviceAPI. Depois que o usuário confirmar o dispositivo, você poderá trocar o token de atualização.

Incluir a chave do dispositivo na solicitação de atualização: se o monitoramento de dispositivos estiver habilitado, inclua a chave exclusiva do dispositivo como um AuthParameter ao usar o fluxo REFRESH_TOKEN_AUTH:

{
  "AuthFlow": "REFRESH_TOKEN_AUTH",
  "AuthParameters": {
    "REFRESH_TOKEN": "example_refresh_token",
    "SECRET_HASH": "example_secret_hash", // Required if your app client uses a client secret
    "DEVICE_KEY": "example_device_key" 
  }
}

Usar USER_SRP_AUTH para monitoramento de dispositivos: se você estiver usando o monitoramento de dispositivos, o fluxo de autenticação inicial deverá ser USER_SRP_AUTH.

Verifique os Atributos obrigatórios definidos na configuração do grupo de usuários.

Usando ferramentas de captura de rede em seu navegador, recupere a resposta SAML. Talvez seja necessário realizar a decodificação de URL e base64. Verifique se o atributo está presente na declaração SAML.

Faça login no provedor de identidades e analise os atributos que ele está enviando para o Amazon Cognito. Verifique se o IdP está configurado para enviar o atributo obrigatório usando o nome correto.

Para atributos imutáveis, execute o seguinte AWS CLI comando para identificá-los:. aws cognito-idp describe-user-pool --user-pool-id USER-POOL-ID --query 'UserPool.SchemaAttributes[?Mutable==`false`].Name'

Nos mapeamentos de atributos SAML do IdP, exclua qualquer mapeamento que tenha como alvo um atributo imutável do Amazon Cognito. Como alternativa, atualize o atributo de destino para um atributo diferente e mutável.

No console de gerenciamento do IdP, atualize a aplicação com o formato de URL do ACS correto, garantindo que ele use a vinculação HTTP POST.

Formato de domínio padrão: https://cognito-idp.Region.amazonaws.com/your user pool ID/saml2/idpresponse

Formato de domínio personalizado: https://auth.example.com/saml2/idpresponse

Para fluxos iniciados pelo provedor de serviços (iniciados pelo SP): sempre inicie a autenticação no endpoint /oauth2/authorize do grupo de usuários. As declarações SAML que não retornam parâmetros RelayState da visita inicial do usuário ao Amazon Cognito não são solicitações válidas iniciadas pelo SP.

Para fluxos iniciados pelo provedor de identidades (iniciados pelo IdP): o IdP deve incluir o parâmetro RelayState com a declaração SAML no endpoint /saml2/idpresponse, usando o formato obrigatório: redirect_uri=REDIRECT_URI&state=STATE.

Para aplicativos públicos: use SetUserMFAPreferencecom um token de acesso válido para permitir que os usuários definam suas próprias preferências de MFA

Para aplicativos gerenciados pelo administrador: use AdminSetUserMFAPreferencecom AWS credenciais para configurar as preferências de MFA do usuário

Verifique as pastas de spam e lixo eletrônico do usuário.

Confirme se o usuário existe no grupo de usuários.

Verifique se o status do usuário não é FORCE_CHANGE_PASSWORD. Se esse for o caso, o usuário foi criado por um administrador e o Amazon Cognito solicitará que ele defina uma senha quando fizer login com a senha temporária.

Verifique se o usuário tem um atributo de e-mail ou telefone verificado.

Verifique o limite de gastos da sua conta para mensagens SMS.

Verifique a cota de envio de mensagens do Amazon Simple Email Service (Amazon SES).

Verifique se o SMS e o Amazon SES (se o grupo de usuários estiver configurado para Enviar e-mail com o Amazon SES) foram retirados do sandbox. Se eles não tiverem sido retirados do sandbox, endereços de e-mail ou números de telefone que não foram verificados pelo Amazon SES ou não AWS End User Messaging SMS poderão receber códigos de redefinição de senha.

Se o usuário tiver um fator de MFA ativo, verifique se ele não está tentando gerar uma mensagem para o mesmo fator. Por exemplo, usuários com MFA por e-mail ativa não podem enviar códigos de redefinição de senha por e-mail.

Verifique as configurações de recuperação: em seu grupo de usuários, navegue até Entrar > Recuperação de conta de usuário. Verifique se a recuperação da conta de autoatendimento está ativada e revise a configuração do método de entrega da mensagem de recuperação.

Verifique a verificação do atributo do usuário: verifique se o usuário tem um endereço de e-mail ou número de telefone verificado que corresponda à configuração do seu método de recuperação. No console, acesse o perfil do usuário, selecione Atributos do usuário > Editar e marque o atributo apropriado como verificado.

Resolver conflitos de MFA: usuários cujo método preferido de MFA é e-mail não podem receber códigos de redefinição de senha por e-mail, e usuários com MFA por SMS não podem receber códigos por SMS. Atualize seu método de entrega de mensagens de recuperação para fornecer opções alternativas, como SMS, se disponível, caso contrário, e-mail ou e-mail, se disponível, caso contrário, SMS.

Verificação administrativa: use a operação da API AdminUpdateUserAttributespara verificar programaticamente os atributos do usuário quando o acesso ao console não estiver disponível.