Fluxos de autenticação

O processo de autenticação com grupos de usuários do Amazon Cognito pode ser melhor descrito como um fluxo no qual que os usuários fazem uma escolha inicial, enviam credenciais e respondem a desafios adicionais. Quando você implementa a autenticação de login gerenciado na sua aplicação, o Amazon Cognito gerencia o fluxo dessas solicitações e desafios. Ao implementar fluxos com um SDK da AWS no backend da aplicação, você deve construir a lógica das solicitações, solicitar informações aos usuários e responder aos desafios.

Como administrador da aplicação, as características do usuário, os requisitos de segurança e o modelo de autorização ajudam a determinar como você deseja permitir que os usuários façam login. Pergunte-se as questões a seguir.

Quando tiver as respostas para essas perguntas, poderá aprender como ativar os recursos relevantes e implementá-los nas solicitações de autenticação que sua aplicação realiza.

Após configurar os fluxos de login para um usuário, você poderá verificar o status atual dos fatores de MFA e autenticação baseada em opções com solicitações à operação de API GetUserAuthFactors. Essa operação requer autorização com o token de acesso de um usuário conectado. Ela retorna os fatores de autenticação do usuário e as configurações de MFA.

Fazer login com IdPs de terceiros

Os grupos de usuários do Amazon Cognito servem como intermediários para sessões de autenticação entre IdPs, como os serviços Sign in with Apple, Login with Amazon e OpenID Connect (OIDC). Esse processo também é chamado de login federado ou autenticação federada. A autenticação federada não usa nenhum dos fluxos de autenticação que você pode implementar no cliente da aplicação. Em vez disso, você atribui IdPs de grupos de usuários configurados ao cliente da aplicação. O login federado ocorre quando os usuários selecionam seu IdP no login gerenciado ou sua aplicação invoca uma sessão com um redirecionamento para a página de login do IdP.

Com o login federado, você delega fatores de autenticação principal e de MFA ao IdP do usuário. O Amazon Cognito não adiciona os outros fluxos avançados desta seção a um usuário federado, a menos que você os vincule a um usuário local. Usuários federados não vinculados possuem nomes de usuário, mas eles são um repositório de dados de atributos mapeados que normalmente não são usados para login, independentemente do fluxo baseado em navegador.

Fazer login com senhas persistentes

Nos grupos de usuários do Amazon Cognito, cada usuário tem um nome de usuário. Pode ser um número de telefone, endereço de e-mail ou um identificador escolhido ou fornecido pelo administrador. Usuários desse tipo podem fazer login com seu nome de usuário e senha e, opcionalmente, fornecer MFA. Grupos de usuários podem realizar login com nome de usuário e senha com operações de API públicas ou autorizadas pelo IAM e métodos de SDK. A aplicação pode enviar diretamente a senha ao grupo de usuários para autenticação. O grupo de usuários responde com desafios adicionais ou com os tokens web JSON (JWTs) resultantes de uma autenticação bem-sucedida.

Activate password sign-in

Para ativar a autenticação baseada em clientes com nome de usuário e senha, configure o cliente da aplicação para permitir isso. No console do Amazon Cognito, navegue até o menu Clientes da aplicação em Aplicações na configuração do grupo de usuários. Para permitir o login com senha simples em uma aplicação nativa ou um aplicativo móvel do lado do cliente, edite um cliente da aplicação e selecione Fazer login com nome de usuário e senha: ALLOW_USER_PASSWORD_AUTH em Fluxos de autenticação. Para permitir o login com senha simples em uma aplicação do lado do servidor, edite um cliente da aplicação e clique em Fazer login com credenciais administrativas do lado do servidor: ALLOW_ADMIN_USER_PASSWORD_AUTH.

Para ativar a autenticação baseada em opções com nome de usuário e senha, configure o cliente da aplicação para permitir isso. Edite o cliente da aplicação e selecione Login baseado em opções: ALLOW_USER_AUTH.

Para verificar se a autenticação por senha está disponível em fluxos de autenticação baseada em opções, navegue até o menu Fazer login e revise a seção em Opções para login baseado em opções. Você pode fazer login com autenticação por senha simples se a senha estiver visível em Opções disponíveis. A opção Senha inclui as variantes simples e SRP da autenticação por nome de usuário e senha.

Configure ExplicitAuthFlows com suas opções preferenciais de autenticação por nome de usuário e senha em uma solicitação CreateUserPoolClient ou UpdateUserPoolClient.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_PASSWORD_AUTH",
   "ALLOW_ADMIN_USER_PASSWORD_AUTH",
   "ALLOW_USER_AUTH"
]

Em uma solicitação CreateUserPool ou UpdateUserPool, configure Policies com os fluxos de autenticação baseada em opções que você deseja oferecer suporte. O valor PASSWORD em AllowedFirstAuthFactors inclui as opções de fluxo de autenticação por senha simples e SRP.

"Policies": {
   "SignInPolicy": {
      "AllowedFirstAuthFactors": [
         "PASSWORD",
         "EMAIL_OTP",
         "WEB_AUTHN"
      ]
   }
}

Choice-based sign-in with a password

Para conectar um usuário a uma aplicação com autenticação por nome de usuário e senha, configure o corpo da solicitação AdminInitiateAuth ou InitiateAuth da forma a seguir. Essa solicitação de login será bem-sucedida ou continuará até o próximo desafio se o usuário atual for elegível para a autenticação por nome de usuário e senha. Caso contrário, ela responderá com uma lista de desafios de autenticação de fator primário disponíveis. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}

Você também pode omitir o valor PREFERRED_CHALLENGE e receber uma resposta contendo uma lista de fatores de login elegíveis para o usuário.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}

Se você não enviou um desafio preferencial ou o usuário enviado não for elegível para o desafio preferencial, o Amazon Cognito retornará uma lista de opções em AvailableChallenges. Quando AvailableChallenges inclui um ChallengeName de PASSWORD, você pode continuar a autenticação com uma resposta de desafio RespondToAuthChallenge ou AdminRespondToAuthChallenge no formato a seguir. Você deve transmitir um parâmetro Session que associe a resposta do desafio à resposta da API à solicitação inicial de login. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "ChallengeName": "PASSWORD",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's Password]"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response"
}

O Amazon Cognito responde a solicitações de desafio preferencial elegíveis e bem-sucedidas e respostas do desafio PASSWORD com tokens ou um desafio adicional obrigatório, como autenticação multifator (MFA).

Client-based sign-in with a password

Para conectar um usuário a uma aplicação do lado do cliente com autenticação por nome de usuário e senha, configure o corpo da solicitação InitiateAuth da forma a seguir. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "AuthFlow": "USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}

Para conectar um usuário a uma aplicação do lado do servidor com autenticação por nome de usuário e senha, configure o corpo da solicitação AdminInitiateAuth da forma a seguir. A aplicação deve assinar essa solicitação com as credenciais da AWS. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "AuthFlow": "ADMIN_USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}

O Amazon Cognito responde a solicitações bem-sucedidas com tokens ou um desafio adicional obrigatório, como autenticação multifator (MFA).

Fazer login com senhas persistentes e carga útil segura

Outra forma dos métodos de login com nome de usuário e senha em grupos de usuários é com o protocolo de senha remota segura (SRP). Essa opção envia uma prova de conhecimento de uma senha (um hash de senha e um salt) que o grupo de usuários pode verificar. Sem nenhuma informação secreta legível na solicitação ao Amazon Cognito, a aplicação é a única entidade que processa as senhas inseridas pelos usuários. A autenticação SRP envolve cálculos matemáticos melhor executados por um componente existente que você pode importar no SDK. A SRP é geralmente implementada em aplicações do lado do cliente, como aplicativos móveis. Para obter mais informações sobre o protocolo, consulte The Stanford SRP Homepage. A Wikipedia também tem recursos e exemplos. Uma variedade de bibliotecas públicas estão disponíveis para realizar os cálculos de SRP para fluxos de autenticação.

A sequência de iniciação-desafio-resposta da autenticação do Amazon Cognito valida os usuários e suas senhas com a SRP. É necessário configurar o grupo de usuários e o cliente da aplicação para oferecer suporte à autenticação SRP e, em seguida, implementar a lógica das solicitações de login e das respostas do desafio na aplicação. Suas bibliotecas de SRP podem gerar números aleatórios e valores calculados que demonstram ao grupo de usuários que você possui a senha de um usuário. Sua aplicação preenche esses valores calculados nos campos AuthParameters e ChallengeParameters formatados em JSON e nas operações de API e métodos de SDK para autenticação de grupos de usuários do Amazon Cognito.

Activate SRP sign-in

Para ativar a autenticação baseada em clientes com nome de usuário e SRP, configure o cliente da aplicação para permitir isso. No console do Amazon Cognito, navegue até o menu Clientes da aplicação em Aplicações na configuração do grupo de usuários. Para permitir o login com SRP em uma aplicação nativa ou um aplicativo móvel do lado do cliente, edite um cliente da aplicação e selecione Fazer login com senha remota segura (SRP): ALLOW_USER_SRP_AUTH em Fluxos de autenticação.

Para ativar a autenticação baseada em opções com nome de usuário e SRP, edite o cliente da aplicação e selecione Login baseado em opções: ALLOW_USER_AUTH.

Para verificar se a autenticação por SRP está disponível em fluxos de autenticação baseada em opções, navegue até o menu Fazer login e revise a seção em Opções para login baseado em opções. Você pode fazer login com autenticação por SRP se a senha estiver visível em Opções disponíveis. A opção Senha inclui as variantes de autenticação por nome de usuário e senha em texto simples e por SRP.

Configure ExplicitAuthFlows com suas opções preferenciais de autenticação por nome de usuário e senha em uma solicitação CreateUserPoolClient ou UpdateUserPoolClient.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_SRP_AUTH",
   "ALLOW_USER_AUTH"
]

Em uma solicitação CreateUserPool ou UpdateUserPool, configure Policies com os fluxos de autenticação baseada em opções que você deseja oferecer suporte. O valor PASSWORD em AllowedFirstAuthFactors inclui as opções de fluxo de autenticação por senha de texto simples e SRP.

"Policies": {
   "SignInPolicy": {
      "AllowedFirstAuthFactors": [
         "PASSWORD",
         "EMAIL_OTP",
         "WEB_AUTHN"
      ]
   }
}

Choice-based sign-in with SRP

Para conectar um usuário a uma aplicação com autenticação por nome de usuário e senha com SRP, configure o corpo da solicitação AdminInitiateAuth ou InitiateAuth da forma a seguir. Essa solicitação de login será bem-sucedida ou continuará até o próximo desafio se o usuário atual for elegível para a autenticação por nome de usuário e senha. Caso contrário, ela responderá com uma lista de desafios de autenticação de fator primário disponíveis. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD_SRP",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789"
}

Você também pode omitir o valor PREFERRED_CHALLENGE e receber uma resposta contendo uma lista de fatores de login elegíveis para o usuário.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}

Se você não enviou um desafio preferencial ou o usuário enviado não for elegível para o desafio preferencial, o Amazon Cognito retornará uma lista de opções em AvailableChallenges. Quando AvailableChallenges inclui um ChallengeName de PASSWORD_SRP, você pode continuar a autenticação com uma resposta de desafio RespondToAuthChallenge ou AdminRespondToAuthChallenge no formato a seguir. Você deve transmitir um parâmetro Session que associe a resposta do desafio à resposta da API à solicitação inicial de login. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

{
   "ChallengeName": "PASSWORD_SRP",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response"
}

O Amazon Cognito responde a solicitações de desafio preferencial elegíveis e respostas do desafio PASSWORD_SRP com um desafio PASSWORD_VERIFIER. Seu cliente deve concluir os cálculos de SRP e responder ao desafio em uma solicitação RespondToAuthChallenge ou AdminRespondToAuthChallenge.

{
   "ChallengeName": "PASSWORD_VERIFIER",
   "ChallengeResponses": { 
      "PASSWORD_CLAIM_SIGNATURE" : "string",
      "PASSWORD_CLAIM_SECRET_BLOCK" : "string",
      "TIMESTAMP" : "string"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}

Em uma resposta bem-sucedida do desafio PASSWORD_VERIFIER, o Amazon Cognito emite tokens ou outro desafio obrigatório, como a autenticação multifator (MFA).

Client-based sign-in with SRP

A autenticação SRP é mais comum na autenticação do lado do cliente do que na autenticação do lado do servidor. No entanto, você pode usar a autenticação SRP com InitiateAuth e AdminInitiateAuth. Para conectar um usuário a uma aplicação, configure o corpo da solicitação InitiateAuth ou AdminInitiateAuth da forma a seguir. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

O cliente gera SRP_A por meio de um gerador módulo N g elevado à potência de um inteiro aleatório secreto a.

{
   "AuthFlow": "USER_SRP_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789"
}

O Amazon Cognito responde com um desafio PASSWORD_VERIFIER. Seu cliente deve concluir os cálculos de SRP e responder ao desafio em uma solicitação RespondToAuthChallenge ou AdminRespondToAuthChallenge.

{
   "ChallengeName": "PASSWORD_VERIFIER",
   "ChallengeResponses": { 
      "PASSWORD_CLAIM_SIGNATURE" : "string",
      "PASSWORD_CLAIM_SECRET_BLOCK" : "string",
      "TIMESTAMP" : "string"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}

Em uma resposta bem-sucedida do desafio PASSWORD_VERIFIER, o Amazon Cognito emite tokens ou outro desafio obrigatório, como a autenticação multifator (MFA).

Fazer login sem senha com senhas de uso único

As senhas podem ser perdidas ou roubadas. Talvez você queira verificar somente se seus usuários têm acesso a um endereço de e-mail, número de telefone ou aplicação autenticadora verificado. A solução para isso é o login sem senha. A aplicação pode solicitar que os usuários insiram o nome de usuário, o endereço de e-mail ou o número de telefone. O Amazon Cognito então gera uma senha de uso único (OTP), um código que eles devem confirmar. Um código bem-sucedido conclui a autenticação.

Fluxos de autenticação sem senha não são compatíveis com a autenticação multifator (MFA) obrigatória no grupo de usuários. Se a MFA for opcional no grupo de usuários, os usuários que ativaram a MFA não poderão fazer login com um primeiro fator sem senha. Usuários que não têm uma preferência de MFA em um grupo de usuários com MFA opcional podem fazer login sem senha. Para obter mais informações, consulte Informações importantes sobre a MFA de grupo de usuários.

Quando um usuário insere corretamente um código recebido por SMS ou e-mail como parte da autenticação sem senha, além de autenticar o usuário, o grupo de usuários marca o atributo de endereço de e-mail ou número de telefone não verificado do usuário como verificado. O status do usuário também muda de UNCONFIRMED para CONFIRMED, independentemente de você ter configurado o grupo de usuários para verificar automaticamente endereços de e-mail ou números de telefone.

Novas opções com login sem senha

Quando você ativa a autenticação sem senha no grupo de usuários, o funcionamento de alguns fluxos de usuários é alterado.

Login automático com OTPs

Os usuários que se cadastram e confirmam suas contas com OTPs enviadas por e-mail ou SMS podem fazer login automaticamente com o fator sem senha que corresponde à mensagem de confirmação. Na IU do login gerenciado, os usuários que confirmam suas contas e estão elegíveis para o login por OTP com o método de entrega do código de confirmação passam automaticamente para o primeiro login após fornecerem o código. Em sua aplicação personalizada com um SDK da AWS, transmita os parâmetros a seguir para uma operação InitiateAuth ou AdminInitiateAuth.

Você pode transmitir um PREFERRED_CHALLENGE de EMAIL_OTP ou SMS_OTP, mas não é obrigatório. O parâmetro Session fornece prova de autenticação e o Amazon Cognito o ignora AuthParameters quando você transmite um código de sessão válido.

A operação de login retorna a resposta que indica autenticação bem-sucedida, AuthenticationResult, sem desafios adicionais se as condições a seguir forem verdadeiras.

Activate passwordless sign-in

Console

Para ativar o login sem senha, configure o grupo de usuários para permitir o login primário com um ou mais tipos sem senha e, em seguida, configure o cliente da aplicação para permitir o fluxo USER_AUTH. No console do Amazon Cognito, navegue até o menu Fazer login em Autenticação na configuração do grupo de usuários. Edite Opções para login baseado em opções e selecione Senha única para mensagem de e-mail ou Senha única para mensagem SMS. É possível ativar as duas opções. Salve as alterações.

Navegue até o menu Clientes da aplicação e escolha um cliente ou crie um. Clique em Editar e selecione Selecionar um tipo de autenticação no login: ALLOW_USER_AUTH.

API/SDK

Na API de grupos de usuários, configure SignInPolicy com as opções sem senha apropriadas em uma solicitação CreateUserPool ou UpdateUserPool.

"SignInPolicy": { 
    "AllowedFirstAuthFactors": [ 
        "EMAIL_OTP",
        "SMS_OTP"
    ]
}

Configure o cliente da aplicação ExplicitAuthFlows com a opção obrigatória em uma solicitação CreateUserPoolClient ou UpdateUserPoolClient.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]

Sign in with passwordless

O login sem senha não tem um AuthFlow baseado em clientes que você possa especificar em InitiateAuth e AdminInitiateAuth. A autenticação por OTP está disponível somente no AuthFlow baseado em clientes de USER_AUTH, onde você pode solicitar uma opção de login preferencial ou escolher a opção sem senha no AvailableChallenges de um usuário. Para conectar um usuário a uma aplicação, configure o corpo da solicitação InitiateAuth ou AdminInitiateAuth da forma a seguir. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

Neste exemplo, não sabemos como o usuário deseja fazer login. Se adicionarmos um parâmetro PREFERRED_CHALLENGE e o desafio preferencial estiver disponível para o usuário, o Amazon Cognito responderá com esse desafio.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}

Em vez disso, você pode adicionar "PREFERRED_CHALLENGE": "EMAIL_OTP" ou "PREFERRED_CHALLENGE": "SMS_OTP" a AuthParameters nesse exemplo. Se o usuário for elegível para esse método preferencial, o grupo de usuários enviará imediatamente um código para o endereço de e-mail ou número de telefone do usuário e retornará "ChallengeName": "EMAIL_OTP" ou "ChallengeName": "SMS_OTP".

Se você não especificar um desafio preferencial, o Amazon Cognito responderá com um parâmetro AvailableChallenges.

{
   "AvailableChallenges": [ 
      "EMAIL_OTP", 
      "SMS_OTP",
      "PASSWORD"
    ],
   "Session": "[Session ID]"
}

Esse usuário é elegível para login sem senha com OTP por e-mail, OTP por SMS e nome de usuário e senha. A aplicação pode solicitar que o usuário faça a seleção ou pode fazer uma seleção com base na lógica interna. Em seguida, ele executa uma solicitação RespondToAuthChallenge ou AdminRespondToAuthChallenge que seleciona o desafio. Suponha que o usuário queira concluir a autenticação sem senha com uma OTP enviada por e-mail.

{
   "ChallengeName": "SELECT_CHALLENGE",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "ANSWER" : "EMAIL_OTP" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}

O Amazon Cognito responde com um desafio EMAIL_OTP e envia um código para o endereço de e-mail verificado do usuário. Sua aplicação deve então responder novamente a esse desafio.

Essa também seria a próxima resposta do desafio se você solicitasse EMAIL_OTP como PREFERRED_CHALLENGE.

{
   "ChallengeName": "EMAIL_OTP",
   "ChallengeResponses": {
      "USERNAME" : "testuser", 
      "EMAIL_OTP_CODE" : "123456" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}

Fazer login sem senha com chaves de acesso do WebAuthn

As chaves de acesso são seguras e impõem um nível de esforço relativamente baixo aos usuários. O login com chave de acesso usa autenticadores, dispositivos externos que permitem a autenticação dos usuários. Senhas comuns expõem os usuários a vulnerabilidades como phishing, adivinhação de senhas e roubo de credenciais. Com as chaves de acesso, a aplicação pode se beneficiar de medidas de segurança avançadas em telefones celulares e outros dispositivos conectados ou integrados a sistemas de informação. Um fluxo de trabalho comum de login com chave de acesso começa com uma chamada para o dispositivo que invoca o gerenciador de senhas ou credenciais, por exemplo, o Keychain do iOS ou o gerenciador de senhas do Google Chrome. O gerenciador de credenciais do dispositivo solicita que o usuário selecione uma chave de acesso e a autorize com uma credencial existente ou um mecanismo de desbloqueio do dispositivo. Os telefones modernos têm leitores faciais, leitores de impressão digital, padrões de desbloqueio e outros mecanismos, alguns dos quais satisfazem simultaneamente os princípios de algo que você sabe e algo que você tem da autenticação forte. No caso da autenticação por chave de acesso com biometria, as chaves de acesso representam algo que você é.

Você pode querer substituir as senhas pela autenticação por impressão digital, reconhecimento facial ou chave de segurança. Isso é conhecido como autenticação por chave de acesso ou WebAuthn. É comum que os desenvolvedores de aplicações permitam que os usuários cadastrem um dispositivo biométrico após o primeiro login com senha. Com os grupos de usuários do Amazon Cognito, sua aplicação pode configurar essa opção de login para os usuários. A autenticação por chave de acesso não é elegível para autenticação multifator (MFA).

Fluxos de autenticação sem senha não são compatíveis com a autenticação multifator (MFA) obrigatória no grupo de usuários. Se a MFA for opcional no grupo de usuários, os usuários que ativaram a MFA não poderão fazer login com um primeiro fator sem senha. Usuários que não têm uma preferência de MFA em um grupo de usuários com MFA opcional podem fazer login sem senha. Para obter mais informações, consulte Informações importantes sobre a MFA de grupo de usuários.

O que são chaves de acesso?

As chaves de acesso simplificam a experiência do usuário, eliminando a necessidade de lembrar senhas complexas ou inserir OTPs. As chaves de acesso são baseadas nos padrões WebAuthn e CTAP2 elaborados pelo World Wide Web Consortium (W3C) e pela FIDO (Fast Identity Online) Alliance. Os navegadores e as plataformas implementam esses padrões, fornecem APIs para aplicações web ou aplicativos móveis para iniciar um processo de registro ou autenticação de chave de acesso e também uma IU para o usuário selecionar e interagir com um autenticador de chave de acesso.

Quando um usuário registra um autenticador em um site ou aplicação, o autenticador cria um par de chaves pública e privada. Os navegadores e plataformas WebAuthn enviam a chave pública para o backend da aplicação do site ou aplicação. O autenticador mantém a chave privada, os IDs da chave e os metadados sobre o usuário e a aplicação. Quando o usuário deseja se autenticar na aplicação registrada com seu autenticador registrado, a aplicação gera um desafio aleatório. A resposta a esse desafio é a assinatura digital do desafio gerada com a chave privada do autenticador dessa aplicação e usuário, além de metadados relevantes. O navegador ou a plataforma da aplicação recebe a assinatura digital e a envia para o backend da aplicação. A aplicação então valida a assinatura com a chave pública armazenada.

Veja a seguir alguns dos exemplos e recursos dos autenticadores atualmente disponíveis no mercado. Um autenticador pode atender a uma ou a todas estas categorias.

Na terminologia do WebAuthn, sites e aplicações são partes confiáveis. Cada chave de acesso está associada a um ID de parte confiável específico, um identificador unificado que representa os sites ou aplicações que aceitam a autenticação por chave de acesso. Os desenvolvedores devem selecionar cuidadosamente o ID de parte confiável para garantir o escopo correto de autenticação. Um ID de parte confiável típico é o nome de domínio raiz de um servidor web. Uma chave de acesso com essa especificação de ID de parte confiável pode autenticar nesse domínio e em seus subdomínios. Navegadores e plataformas negam a autenticação por chave de acesso quando o URL do site que o usuário deseja acessar não corresponde ao ID de parte confiável. Da mesma forma, para aplicativos móveis, uma chave de acesso só pode ser usada se o caminho da aplicação estiver presente nos arquivos de associação .well-known que a aplicação disponibiliza no caminho indicado pelo ID de parte confiável.

As chaves de acesso são detectáveis. Elas podem ser reconhecidas e usadas automaticamente por um navegador ou plataforma sem exigir que o usuário insira um nome de usuário. Quando um usuário visita um site ou aplicação compatível com a autenticação por chave de acesso, ele pode selecionar uma chave de acesso em uma lista que o navegador ou a plataforma já conhece, ou pode escanear um código QR.

Como o Amazon Cognito implementa a autenticação por chave de acesso?

As chaves de acesso são um recurso opcional disponível em todos os planos de recursos, exceto no Lite. Elas estão disponíveis somente no fluxo de autenticação baseada em opções. Com o login gerenciado, o Amazon Cognito lida com a lógica da autenticação por chave de acesso. Você também pode usar a API de grupos de usuários do Amazon Cognito nos SDKs da AWS para realizar a autenticação por chave de acesso no backend da aplicação.

O Amazon Cognito reconhece chaves de acesso criadas usando um dos dois algoritmos criptográficos assimétricos, ES256(-7) e RS256(-257). A maioria dos autenticadores é compatível com os dois algoritmos. Por padrão, os usuários podem configurar qualquer tipo de autenticador, por exemplo, tokens de hardware, smartphones móveis e aplicações autenticadoras de software. No momento, o Amazon Cognito não é compatível com a aplicação de atestados.

No grupo de usuários, é possível configurar a verificação de usuário como preferencial ou obrigatória. Essa configuração é definida como preferencial por padrão em solicitações de API que não fornecem um valor, e é selecionada por padrão no console do Amazon Cognito. Quando você define a verificação de usuário como preferencial, os usuários podem configurar autenticadores que não têm o recurso de verificação de usuário, e as operações de registro e autenticação podem ser bem-sucedidas sem a verificação de usuário. Para exigir a verificação de usuário no registro e na autenticação por chave de acesso, altere essa configuração para obrigatória.

A definição do ID de parte confiável (RP) na configuração da chave de acesso é uma decisão importante. Quando você não especifica o contrário e a versão de marca do domínio é login gerenciado, o grupo de usuários considera, por padrão, o nome do domínio personalizado como o ID de RP. Se você não tiver um domínio personalizado e não especificar o contrário, o grupo de usuários utilizará como padrão o ID de RP do domínio de prefixo. Você também pode configurar o ID de RP para ser qualquer nome de domínio que não esteja na lista de sufixos públicos (PSL). A entrada do ID de RP se aplica ao registro e à autenticação por chave de acesso no login gerenciado e na autenticação do SDK. A chave de acesso só funciona em aplicativos móveis se o Amazon Cognito conseguir localizar um arquivo de associação .well-known com o ID de RP como domínio. Como prática recomendada, determine e defina o valor do ID de parte confiável antes que o site ou a aplicação esteja disponível publicamente. Se você alterar o ID de RP, os usuários deverão se registrar novamente com o novo ID de RP.

Cada usuário pode registrar até vinte chaves de acesso. O registro de uma chave de acesso só é possível após o usuário ter feito login no grupo de usuários pelo menos uma vez. O login gerenciado elimina grande parte do esforço necessário para o registro de chaves de acesso. Quando você habilita a autenticação por chave de acesso para um grupo de usuários e um cliente da aplicação, o grupo de usuários com um domínio de login gerenciado lembra os usuários finais de registrarem uma chave de acesso após se cadastrarem em uma nova conta. Você também pode invocar os navegadores dos usuários a qualquer momento para direcioná-los a uma página de login gerenciado para registro da chave de acesso. Os usuários devem fornecer um nome de usuário antes que o Amazon Cognito possa iniciar a autenticação por chave de acesso. O login gerenciado lida com isso automaticamente. A página de login solicita um nome de usuário, valida se o usuário tem pelo menos uma chave de acesso registrada e, em seguida, solicita o login por chave de acesso. Da mesma forma, as aplicações baseados em SDK devem solicitar um nome de usuário e fornecê-lo na solicitação de autenticação.

Quando você configura a autenticação do grupo de usuários com chaves de acesso e tem um domínio personalizado e um domínio de prefixo, o ID de RP usa como padrão o nome de domínio totalmente qualificado (FQDN) do domínio personalizado. Para definir um domínio de prefixo como o ID de RP no console do Amazon Cognito, exclua seu domínio personalizado ou insira o FQDN do domínio de prefixo como um domínio de terceiros.

Activate passkey sign-in

Console

Para ativar o login com chaves de acesso, configure o grupo de usuários para permitir o login primário com um ou mais tipos sem senha e, em seguida, configure o cliente da aplicação para permitir o fluxo USER_AUTH. No console do Amazon Cognito, navegue até o menu Fazer login em Autenticação na configuração do grupo de usuários. Edite Opções para login baseado em opções e adicione Chave de acesso à lista Opções disponíveis.

Navegue até o menu Métodos de autenticação e edite Chave de acesso.

• Verificação de usuário é a configuração para determinar se o grupo de usuários exige dispositivos com chave de acesso que realizem verificações adicionais para garantir que o usuário atual esteja autorizado a usar uma chave de acesso. Para incentivar os usuários a configurar um dispositivo com a verificação de usuário, mas não a tornar obrigatória, selecione Preferencial. Para oferecer suporte somente a dispositivos com verificação de usuário, selecione Obrigatório. Para obter mais informações, consulte User verification em w3.org.

• Domínio para ID de parte confiável é o identificador que a aplicação transmitirá nas solicitações de registro de chave de acesso dos usuários. Ele define a meta da relação de confiança com o emissor das chaves de acesso dos usuários. O ID de parte confiável pode ser: o domínio do seu grupo de usuários, se

  Domínio do Cognito

  O domínio de prefixo do Amazon Cognito do seu grupo de usuários.

  Domínio personalizado

  O domínio personalizado do seu grupo de usuários.

  Domínio de terceiros

  O domínio para aplicações que não usam as páginas de login gerenciado dos grupos de usuários. Essa configuração está geralmente associada a grupos de usuários que não têm um domínio e realizam a autenticação com um SDK da AWS e a API de grupos de usuários no backend.

Navegue até o menu Clientes da aplicação e escolha um cliente ou crie um. Clique em Editar e, em Fluxos de autenticação, selecione Selecionar um tipo de autenticação no login: ALLOW_USER_AUTH.

API/SDK

Na API de grupos de usuários, configure SignInPolicy com as opções de chave de acesso apropriadas em uma solicitação CreateUserPool ou UpdateUserPool. A opção WEB_AUTHN para autenticação por chave de acesso deve ser acompanhada por pelo menos uma outra opção. O registro da chave de acesso requer uma sessão de autenticação existente.

"SignInPolicy": { 
    "AllowedFirstAuthFactors": [ 
        "PASSWORD",
        "WEB_AUTHN"
    ]
}

Configure sua preferência de verificação de usuário e ID de RP no parâmetro WebAuthnConfiguration de uma solicitação SetUserPoolMfaConfig. RelyingPartyId, o destino pretendido dos resultados da autenticação por chave de acesso, pode ser o domínio personalizado ou de prefixo do grupo de usuários ou um domínio de sua escolha.

"WebAuthnConfiguration": { 
   "RelyingPartyId": "example.auth.us-east-1.amazoncognito.com",
   "UserVerification": "preferred"
}

Configure o cliente da aplicação ExplicitAuthFlows com a opção obrigatória em uma solicitação CreateUserPoolClient ou UpdateUserPoolClient.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]

Register a passkey (managed login)

O login gerenciado gerencia o registro das chaves de acesso dos usuários. Quando a autenticação por chave de acesso está ativa no grupo de usuários, o Amazon Cognito solicita que os usuários configurem uma chave de acesso ao se registrarem em uma nova conta.

O Amazon Cognito não solicita que os usuários configurem uma chave de acesso quando eles já se cadastraram e não configuraram uma chave de acesso, ou se você criou a conta deles como administrador. Os usuários nesse estado devem fazer login com outro fator, como uma senha ou uma OTP sem senha, antes de poderem registrar uma chave de acesso.

Como registrar uma chave de acesso

1. Direcione o usuário para a página de login.

   https://auth.example.com/oauth2/authorize/?client_id=1example23456789&response_type=code&scope=email+openid+phone&redirect_uri=https%3A%2F%2Fwww.example.com

2. Processe o resultado da autenticação do usuário. Neste exemplo, o Amazon Cognito o redireciona para www.example.com com um código de autorização que a aplicação troca por tokens.

3. Direcione o usuário para a página de registro de chave de acesso. O usuário terá um cookie de navegador que mantém a sessão ativa. O URL da chave de acesso aceita os parâmetros client_id e redirect_uri. O Amazon Cognito permite que somente usuários autenticados acessem essa página. Faça login do usuário com uma senha, uma OTP enviada por e-mail ou uma OTP enviada por SMS e, em seguida, invoque um URL que corresponda ao padrão a seguir.

   Você também pode adicionar outros parâmetros Autorizar endpointa essa solicitação, como response_type e scope.

   https://auth.example.com/passkeys/add?client_id=1example23456789&redirect_uri=https%3A%2F%2Fwww.example.com

Register a passkey (SDK)

Você registra as credenciais da chave de acesso com metadados em um objeto PublicKeyCreationOptions. Você pode gerar esse objeto com as credenciais de um usuário conectado e apresentá-las em uma solicitação de API ao emissor da chave de acesso. O emissor retornará um objeto RegistrationResponseJSON que confirma o registro da chave de acesso.

Para iniciar o processo de registro da chave de acesso, conecte um usuário com uma opção de login existente. Autorize a solicitação de API StartWebAuthnRegistration autorizada pelo token com o token de acesso do usuário atual. Veja a seguir o corpo de um exemplo de solicitação GetWebAuthnRegistrationOptions.

{
   "AccessToken": "eyJra456defEXAMPLE"
}

A resposta do grupo de usuários contém o objeto PublicKeyCreationOptions. Apresente esse objeto em uma solicitação de API para o emissor do usuário. Ele fornece informações como a chave pública e o ID de parte confiável. O emissor responderá com um objeto RegistrationResponseJSON.

Apresente a resposta do registro em uma solicitação de API CompleteWebAuthnRegistration, novamente autorizada com o token de acesso do usuário. Quando o grupo de usuários responder com uma resposta HTTP 200 com um corpo vazio, a chave de acesso do usuário estará registrada.

Sign in with a passkey

O login sem senha não tem um AuthFlow que você possa especificar em InitiateAuth e AdminInitiateAuth. Em vez disso, você deve declarar um AuthFlow de USER_AUTH e solicitar uma opção de login ou escolher a opção sem senha na resposta do grupo de usuários. Para conectar um usuário a uma aplicação, configure o corpo da solicitação InitiateAuth ou AdminInitiateAuth da forma a seguir. Esse conjunto de parâmetros é o mínimo necessário para fazer login. Parâmetros adicionais estão disponíveis.

Neste exemplo, sabemos que o usuário deseja fazer login com uma chave de acesso e adicionamos um parâmetro PREFERRED_CHALLENGE.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "WEB_AUTHN"
   },
   "ClientId": "1example23456789"
}

O Amazon Cognito responde com um desafio WEB_AUTHN. Sua aplicação deve responder a esse desafio. Inicie uma solicitação de login com o provedor da chave de acesso do usuário. Ela retornará um objeto AuthenticationResponseJSON.

{
   "ChallengeName": "WEB_AUTHN",
   "ChallengeResponses": {
      "USERNAME" : "testuser", 
      "CREDENTIAL" : "{AuthenticationResponseJSON}" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}

MFA após o login

Você pode configurar usuários que concluem o login com um fluxo de nome de usuário e senha para serem solicitados a fazer uma verificação adicional com uma senha de uso único enviada por e-mail, SMS ou uma aplicação geradora de código. A MFA é diferente do login sem senha. O login sem senha usa um primeiro fator de autenticação com senhas de uso único ou chaves de acesso do WebAuthn, e não inclui MFA. A MFA em grupos de usuários é um modelo de resposta a desafios, no qual um usuário primeiro demonstra que sabe a senha e, em seguida, demonstra que tem acesso ao dispositivo registrado de segundo fator.

Tokens de atualização

Sua aplicação utiliza tokens de atualização para manter os usuários conectados sem a necessidade de inserir suas credenciais novamente. As aplicações podem apresentar tokens de atualização ao grupo de usuários e trocá-los por novos tokens de ID e acesso. Com o token de atualização, você pode garantir que um usuário conectado ainda esteja ativo, obter informações de atributos atualizadas e atualizar os direitos de controle de acesso sem a intervenção do usuário.

Autenticação personalizada

Você pode querer configurar um método de autenticação para seus usuários que não esteja listado aqui. Você pode fazer isso com a autenticação personalizada usando acionadores do Lambda. Em uma sequência de funções do Lambda, o Amazon Cognito emite um desafio, faz uma pergunta que os usuários devem responder, verifica a precisão da resposta e determina se outro desafio deve ser emitido. As perguntas e respostas podem incluir perguntas de segurança, solicitações a um serviço CAPTCHA, solicitações a uma API de serviço de MFA externa ou tudo isso em sequência.

Fluxo de autenticação personalizado

Os grupos de usuários do Amazon Cognito também permitem usar fluxos de autenticação personalizados, os quais podem ajudar você a criar um modelo de autenticação baseado em desafio/resposta usando acionadores do AWS Lambda.

O fluxo de autenticação personalizado possibilita ciclos personalizados de desafio e resposta para atender a diferentes requisitos. O fluxo começa com uma chamada para a operação de API InitiateAuth que indica o tipo de autenticação que será usado e fornece todos os parâmetros de autenticação inicial. O Amazon Cognito responde à chamada do InitiateAuth com um dos seguintes tipos de informação:

Se o Amazon Cognito responder à chamada InitiateAuth com um desafio, a aplicação reunirá mais entradas e chamará a operação RespondToAuthChallenge. Essa chamada fornece as respostas do desafio e repassa a sessão. O Amazon Cognito responde à chamada RespondToAuthChallenge de forma semelhante à chamada InitiateAuth. Se o usuário tiver feito login, o Amazon Cognito fornecerá tokens ou, se o usuário não estiver conectado, o Amazon Cognito apresentará outro desafio ou um erro. Se o Amazon Cognito retornar outro desafio, a sequência se repetirá e a aplicação chamará RespondToAuthChallenge até que o usuário faça login com êxito ou um erro seja retornado. Mais detalhes sobre as operações de API InitiateAuth e RespondToAuthChallenge são fornecidos na documentação da API.

Fluxo de autenticação personalizado e desafios

Um aplicativo pode iniciar um fluxo de autenticação personalizado chamando InitiateAuth com CUSTOM_AUTH como o Authflow. Com um fluxo de autenticação personalizado, três acionadores do Lambda controlam os desafios e a verificação das respostas.

Um fluxo de autenticação personalizado também pode usar uma combinação de desafios integrados, como verificação de senha SRP e MFA por SMS. Ele pode usar desafios personalizados, como CAPTCHA ou perguntas secretas.

Usar verificação de senha SRP no fluxo de autenticação personalizado

Para incluir a SRP em um fluxo de autenticação personalizado, você deve começar com ele.

Para obter mais informações sobre os acionadores do Lambda, incluindo o código de exemplo, consulte Como personalizar fluxos de trabalho do grupo de usuários com acionadores do Lambda.

Fluxo de autenticação de migração de usuários

Um acionador de migração de usuários do Lambda ajuda a migrar usuários de um sistema de gerenciamento de usuários herdado para seu grupo de usuários. Se você escolher o fluxo de autenticação USER_PASSWORD_AUTH, os usuários não terão que redefinir suas senhas durante a migração de usuários. Esse fluxo envia as senhas dos usuários para o serviço por uma conexão SSL criptografada durante a autenticação.

Quando você concluir a migração de todos os usuários, alterne os fluxos para o fluxo de SRP mais seguro. O fluxo de SRP não envia senhas pela rede.

Para saber mais sobre acionadores do Lambda, consulte Como personalizar fluxos de trabalho do grupo de usuários com acionadores do Lambda.

Para obter mais informações sobre como migrar usuários com um acionador do Lambda, consulte Como importar usuários com um acionador do Lambda de migração de usuários.