Flujos de autenticación - Amazon Cognito

Flujos de autenticación

El proceso de autenticación con grupos de usuarios de Amazon Cognito puede describirse mejor como un flujo en el que los usuarios toman una decisión inicial, envían credenciales y responden a desafíos adicionales. Cuando implementa la autenticación de inicio de sesión administrado en su aplicación, Amazon Cognito gestiona el flujo de estas solicitudes y desafíos. Al implementar flujos con un AWS SDK en el backend de la aplicación, debe crear la lógica de las solicitudes, solicitar a los usuarios que aporten información y responder a los desafíos.

Como administrador de aplicaciones, las características de su usuario, sus requisitos de seguridad y su modelo de autorización ayudan a determinar cómo desea permitir que los usuarios inicien sesión. Hágase las siguientes preguntas:

Cuando tenga las respuestas a estas preguntas, podrá ver cómo activar las características pertinentes e implementarlas en las solicitudes de autenticación que realice su aplicación.

Después de configurar los flujos de inicio de sesión para un usuario, puede comprobar su estado actual para ver si hay factores de autenticación MFA y basados en opciones con solicitudes a la operación de la API GetUserAuthFactors. Esta operación requiere la autorización con el token de acceso de un usuario que haya iniciado sesión. Devuelve los factores de autenticación del usuario y la configuración de MFA.

Inicio de sesión con IdP de terceros

Los grupos de usuarios de Amazon Cognito actúan como intermediario de las sesiones de autenticación entre los IdP, como los servicios Sign in with Apple, Login with Amazon y OpenID Connect (OIDC). Este proceso también se denomina inicio de sesión federado o autenticación federada. La autenticación federada no utiliza ninguno de los flujos de autenticación que puede crear en el cliente de su aplicación. En su lugar, asigna los IdP del grupo de usuarios configurado a su cliente de aplicación. El inicio de sesión federado ocurre cuando los usuarios seleccionan su IdP en el inicio de sesión administrado o cuando la aplicación invoca una sesión con una redirección a su página de inicio de sesión de IdP.

Con el inicio de sesión federado, delega los factores de autenticación principales y de MFA al IdP del usuario. Amazon Cognito no añade los demás flujos avanzados de esta sección a un usuario federado a menos que los vincule a un usuario local. Los usuarios federados no vinculados tienen nombres de usuario, pero son un almacén de datos de atributos mapeados que normalmente no se utilizan para el inicio de sesión independiente del flujo con navegador.

Inicio de sesión con contraseñas persistentes

En los grupos de usuarios de Amazon Cognito, cada usuario tiene un nombre de usuario. Podría ser un número de teléfono, una dirección de correo electrónico o un identificador elegido o proporcionado por el administrador. Los usuarios de este tipo pueden iniciar sesión con su nombre de usuario y contraseña y, de forma opcional, proporcionar una MFA. Los grupos de usuarios pueden iniciar sesión con nombre de usuario y contraseña con operaciones de API públicas o autorizadas por IAM y métodos del SDK. La aplicación puede enviar directamente la contraseña a su grupo de usuarios para su autenticación. Su grupo de usuarios responde con desafíos adicionales o con los tokens web JSON (JWT) que son el resultado de una autenticación correcta.

Activate password sign-in

Para activar la autenticación basada en el cliente con nombre de usuario y contraseña, configure el cliente de la aplicación para que lo permita. En la consola de Amazon Cognito, vaya al menú Clientes de aplicación en Aplicaciones, en la configuración de su grupo de usuarios. Para permitir el inicio de sesión con una contraseña simple en una aplicación móvil o nativa en el cliente, edite un cliente de aplicación y seleccione Iniciar sesión con nombre de usuario y contraseña: ALLOW_USER_PASSWORD_AUTH en Flujos de autenticación. Para permitir el inicio de sesión con una contraseña simple en una aplicación del servidor, edite el cliente de aplicación y elija Iniciar sesión con las credenciales administrativas del servidor: ALLOW_ADMIN_USER_PASSWORD_AUTH.

Para activar la autenticación basada en opciones con nombre de usuario y contraseña, configure el cliente de aplicación para que lo permita. Edite el cliente de aplicación y elija Inicio de sesión basado en opciones: ALLOW_USER_AUTH.

Captura de pantalla de la consola de Amazon Cognito, donde se ve la elección de flujos de autenticación con contraseña simple para un cliente de aplicación Se han seleccionado las opciones ALLOW_USER_PASSWORD_AUTH, ALLOW_ADMIN_USER_PASSWORD_AUTH y ALLOW_USER_AUTH.

Para comprobar que la autenticación mediante contraseña esté disponible en los flujos de autenticación basados en opciones, vaya al menú de inicio de sesión y consulte la sección Opciones para el inicio de sesión basado en opciones. Puede iniciar sesión con una autenticación con contraseña simple si la contraseña está visible en Opciones disponibles. La opción de contraseña incluye las variantes de autenticación simple y SRP con nombre de usuario y contraseña.

Captura de pantalla de la consola de Amazon Cognito, donde se ve la opción de autenticación por contraseña en la configuración de inicio de sesión basada en opciones USER_AUTH para un grupo de usuarios La opción Contraseña aparece activa.

Configure ExplicitAuthFlows con sus opciones de autenticación de nombre de usuario y contraseña preferidas en una solicitud CreateUserPoolClient o UpdateUserPoolClient.

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

En una solicitud CreateUserPool o UpdateUserPool, configure Policies con los flujos de autenticación basados en opciones que desee admitir. El valor PASSWORD en AllowedFirstAuthFactors incluye las opciones de flujo de autenticación con contraseña simple y SRP.

"Policies": { "SignInPolicy": { "AllowedFirstAuthFactors": [ "PASSWORD", "EMAIL_OTP", "WEB_AUTHN" ] } }
Choice-based sign-in with a password

Para iniciar sesión en una aplicación con autenticación de nombre de usuario y contraseña, configure el cuerpo de la solicitud AdminInitiateAuth o InitiateAuth del siguiente modo. Esta solicitud de inicio de sesión se realiza correctamente o continúa hasta el siguiente desafío si el usuario actual cumple los requisitos para la autenticación con nombre de usuario y contraseña. De lo contrario, responde con una lista de los desafíos de autenticación de factor principal disponibles. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

También puede omitir el valor de PREFERRED_CHALLENGE y recibir una respuesta que contenga una lista de los factores de inicio de sesión aptos para el usuario.

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

Si no ha enviado un desafío preferido o el usuario enviado no reúne los requisitos para su desafío preferido, Amazon Cognito devolverá una lista de opciones en AvailableChallenges. Cuando AvailableChallenges incluye un ChallengeName de PASSWORD, puede continuar con la autenticación con una respuesta al desafío RespondToAuthChallenge o AdminRespondToAuthChallenge en el siguiente formato. Debe pasar un parámetro Session que asocie la respuesta al desafío con la respuesta de la API a su solicitud de inicio de sesión inicial. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

Amazon Cognito responde a las solicitudes de desafío preferido aptas y satisfactorias y a las respuestas a desafíos PASSWORD con tokens o un desafío adicional obligatorio, como la autenticación multifactor (MFA).

Client-based sign-in with a password

Para iniciar sesión en una aplicación en el cliente con autenticación de nombre de usuario y contraseña, configure el cuerpo de su solicitud InitiateAuth de la siguiente manera. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

Para iniciar sesión en una aplicación en el servidor con autenticación de nombre de usuario y contraseña, configure el cuerpo de su solicitud AdminInitiateAuth de la siguiente manera. Su aplicación debe firmar esta solicitud con credenciales AWS. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

Amazon Cognito responde a las solicitudes exitosas con tokens o un desafío adicional requerido, como la autenticación multifactor (MFA).

Inicio de sesión con contraseñas persistentes y carga útil segura

Otro método de inicio de sesión con nombre de usuario y contraseña en los grupos de usuarios es el uso del protocolo de contraseña remota segura (SRP). Esta opción envía una prueba del conocimiento de la contraseña (sal y hash de contraseña) que el grupo de usuarios puede verificar. Al no contener información secreta legible en la solicitud a Amazon Cognito, su aplicación es la única entidad que procesa las contraseñas que introducen los usuarios. La autenticación con SRP implica cálculos matemáticos que se pueden realizar mejor con un componente existente que pueda importar a su SDK. El SRP se suele implementar en aplicaciones en el cliente, como las aplicaciones móviles. Para obtener más información acerca del protocolo, consulte The Stanford SRP Homepage. Wikipedia también tiene recursos y ejemplos. Hay distintas bibliotecas públicas disponibles para realizar los cálculos de SRP para sus flujos de autenticación.

La secuencia inicio/desafío/respuesta de la autenticación de Amazon Cognito valida a los usuarios y sus contraseñas con SRP. Debe configurar su grupo de usuarios y el cliente de aplicación para que admitan la autenticación SRP y, a continuación, implementar la lógica de las solicitudes de inicio de sesión y las respuestas a los desafíos en su aplicación. Sus bibliotecas SRP pueden generar números aleatorios y valores calculados que demuestren a su grupo de usuarios que dispone de la contraseña de un usuario. Su aplicación rellena estos valores calculados en los campos con formato JSON AuthParameters y ChallengeParameters en las operaciones de API para grupos de usuarios de Amazon Cognito y los métodos SDK para la autenticación.

Activate SRP sign-in

Para activar la autenticación basada en el cliente con nombre de usuario y SRP, configure el cliente de aplicación para que lo permita. En la consola de Amazon Cognito, vaya al menú Clientes de aplicación en Aplicaciones, en la configuración de su grupo de usuarios. Para permitir el inicio de sesión con SRP en una aplicación móvil o nativa en el cliente, edite un cliente de aplicación y seleccione Iniciar sesión con contraseña remota segura (SRP): ALLOW_USER_SRP_AUTH en Flujos de autenticación.

Para activar la autenticación basada en opciones con nombre de usuario y SRP, edite el cliente de aplicación y elija Inicio de sesión basado en opciones: ALLOW_USER_AUTH.

Captura de pantalla de la consola de Amazon Cognito, donde se ve la elección de flujos de autenticación con contraseña remota y segura para un cliente de aplicación Se han seleccionado las opciones ALLOW_USER_SRP_AUTH y ALLOW_USER_AUTH.

Para comprobar que la autenticación mediante SRP esté disponible en los flujos de autenticación basados en opciones, vaya al menú de inicio de sesión y consulte la sección Opciones para el inicio de sesión basado en opciones. Puede iniciar sesión con una autenticación con SRP si la contraseña está visible en Opciones disponibles. La opción de contraseña incluye las variantes de autenticación simple y SRP con nombre de usuario y contraseña.

Captura de pantalla de la consola de Amazon Cognito, donde se ve la opción de autenticación por contraseña en la configuración de inicio de sesión basada en opciones USER_AUTH para un grupo de usuarios La opción Contraseña aparece como activa.

Configure ExplicitAuthFlows con sus opciones de autenticación de nombre de usuario y contraseña preferidas en una solicitud CreateUserPoolClient o UpdateUserPoolClient.

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

En una solicitud CreateUserPool o UpdateUserPool, configure Policies con los flujos de autenticación basados en opciones que desee admitir. El valor PASSWORD en AllowedFirstAuthFactors incluye las opciones de flujo de autenticación con contraseña simple y SRP.

"Policies": { "SignInPolicy": { "AllowedFirstAuthFactors": [ "PASSWORD", "EMAIL_OTP", "WEB_AUTHN" ] } }
Choice-based sign-in with SRP

Para iniciar sesión en una aplicación con autenticación de nombre de usuario y contraseña con SRP, configure el cuerpo de la solicitud AdminInitiateAuth o InitiateAuth del siguiente modo. Esta solicitud de inicio de sesión se realiza correctamente o continúa hasta el siguiente desafío si el usuario actual cumple los requisitos para la autenticación con nombre de usuario y contraseña. De lo contrario, responde con una lista de los desafíos de autenticación de factor principal disponibles. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

También puede omitir el valor de PREFERRED_CHALLENGE y recibir una respuesta que contenga una lista de los factores de inicio de sesión aptos para el usuario.

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

Si no ha enviado un desafío preferido o el usuario enviado no reúne los requisitos para su desafío preferido, Amazon Cognito devolverá una lista de opciones en AvailableChallenges. Cuando AvailableChallenges incluye un ChallengeName de PASSWORD_SRP, puede continuar con la autenticación con una respuesta al desafío RespondToAuthChallenge o AdminRespondToAuthChallenge en el siguiente formato. Debe pasar un parámetro Session que asocie la respuesta al desafío con la respuesta de la API a su solicitud de inicio de sesión inicial. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

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

Amazon Cognito responde a las solicitudes de desafío preferente y a las respuestas de desafíos de PASSWORD_SRP aptas con un desafío PASSWORD_VERIFIER. Su cliente debe completar los cálculos de SRP y responder al desafío en una solicitud RespondToAuthChallenge o 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]" }

Si la respuesta a un desafío PASSWORD_VERIFIER es correcta, Amazon Cognito emite tokens u otro desafío obligatorio como la autenticación multifactor (MFA).

Client-based sign-in with SRP

La autenticación SRP es más común en la autenticación en el cliente que en el servidor. Sin embargo, puede usar la autenticación SRP con InitiateAuth y AdminInitiateAuth. Para que un usuario inicie sesión en una aplicación, configure el cuerpo de su solicitud InitiateAuth o AdminInitiateAuth de la siguiente manera. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

El cliente genera SRP_A a partir de un módulo generador N g elevado a la potencia de un entero aleatorio secreto a.

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

Amazon Cognito responde con un desafío PASSWORD_VERIFIER. Su cliente debe completar los cálculos de SRP y responder al desafío en una solicitud RespondToAuthChallenge o 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]" }

Si la respuesta a un desafío PASSWORD_VERIFIER es correcta, Amazon Cognito emite tokens u otro desafío obligatorio como la autenticación multifactor (MFA).

Inicio de sesión sin contraseña con contraseñas de un solo uso

Las contraseñas se pueden perder o robar. Es posible que solo desee comprobar si sus usuarios tienen acceso a una dirección de correo electrónico verificada, un número de teléfono o una aplicación de autenticación. La solución a este problema es el inicio de sesión sin contraseña. Su aplicación puede solicitar a los usuarios que introduzcan su nombre de usuario, dirección de correo electrónico o número de teléfono. A continuación, Amazon Cognito genera una contraseña de un solo uso (OTP), un código que deben confirmar. Un código correcto completa la autenticación.

Los flujos de autenticación sin contraseña no son compatibles con la autenticación multifactor (MFA) requerida en el grupo de usuarios. Si la MFA es opcional en su grupo de usuarios, los usuarios que hayan activado la MFA no podrán iniciar sesión con un primer factor sin contraseña. Los usuarios que no tengan una preferencia de MFA en un grupo de usuarios con MFA opcional pueden iniciar sesión con factores sin contraseña. Para obtener más información, consulte Cosas que debe saber acerca de la MFA de grupos de usuarios.

Cuando un usuario introduce correctamente un código que ha recibido en un mensaje SMS o de correo electrónico como parte de la autenticación sin contraseña, además de autenticar al usuario, el grupo de usuarios marca como verificado el atributo de dirección de correo electrónico o número de teléfono del usuario no verificado. El estado del usuario también cambió de UNCONFIRMED a CONFIRMED, independientemente de si configuró su grupo de usuarios para verificar automáticamente las direcciones de correo electrónico o los números de teléfono.

Nuevas opciones con inicio de sesión sin contraseña

Al activar la autenticación sin contraseña en el grupo de usuarios, se cambia el funcionamiento de algunos flujos de usuarios.

  1. Los usuarios pueden registrarse sin contraseña y elegir un factor sin contraseña al iniciar sesión. También puede crear usuarios sin contraseñas como administrador.

  2. Los usuarios que importe con un archivo CSV pueden iniciar sesión inmediatamente sin necesidad de contraseñas. No es necesario que establezcan una contraseña antes de iniciar sesión.

  3. Los usuarios que no tengan una contraseña pueden enviar solicitudes de la API ChangePassword sin el parámetro PreviousPassword.

Inicio de sesión automático con OTP

Los usuarios que se registren y confirmen sus cuentas de usuario mediante OTP con correo electrónico o mensaje SMS pueden iniciar sesión automáticamente con un factor sin contraseña que coincida con su mensaje de confirmación. En la interfaz de usuario con inicio de sesión administrado, los usuarios que confirmen sus cuentas y puedan iniciar sesión con OTP mediante el código de confirmación procederán automáticamente a iniciar sesión por primera vez después de proporcionar el código de confirmación. En su aplicación personalizada con un AWS SDK, pase los siguientes parámetros a una operación InitiateAuth o AdminInitiateAuth.

  • El parámetro Session de la respuesta de la API ConfirmSignUp como parámetro de solicitud Session.

  • Un AuthFlow de USER_AUTH.

Puede pasar un PREFERRED_CHALLENGE de EMAIL_OTP o SMS_OTP, pero no es obligatorio. El parámetro Session proporciona una prueba de autenticación y Amazon Cognito ignora los AuthParameters cuando se pasa un código de sesión válido.

La operación de inicio de sesión devuelve la respuesta que indica que la autenticación se ha realizado correctamente, AuthenticationResult, sin desafíos adicionales si se cumplen las siguientes condiciones.

  • El código Session es válido y no ha caducado.

  • El usuario es apto para el método de autenticación OTP.

Activate passwordless sign-in
Consola

Para activar el inicio de sesión sin contraseña, configure su grupo de usuarios para permitir el inicio de sesión principal con uno o más tipos sin contraseña; luego, configure el cliente de aplicación para permitir el flujo USER_AUTH. En la consola de Amazon Cognito, vaya al menú Inicio de sesión en Autenticación, en la configuración de su grupo de usuarios. Edite las Opciones para el inicio de sesión basado en opciones y elija Contraseña de un solo uso por mensaje de correo electrónico o Contraseña de un solo uso por mensaje SMS. Puede activar ambas opciones. Guarde los cambios.

Vaya al menú Clientes de aplicación y elija un cliente de aplicación o cree uno nuevo. Seleccione Editar y elija Seleccionar un tipo de autenticación en el inicio de sesión: ALLOW_USER_AUTH.

API/SDK

En la API de grupos de usuarios, configure SignInPolicy con las opciones sin contraseña adecuadas en una solicitud CreateUserPool o UpdateUserPool.

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

Configure su cliente de aplicación ExplicitAuthFlows con la opción requerida en una solicitud CreateUserPoolClient o UpdateUserPoolClient.

"ExplicitAuthFlows": [ "ALLOW_USER_AUTH" ]
Sign in with passwordless

El inicio de sesión sin contraseña no tiene un AuthFlow basado en el cliente que pueda especificar en InitiateAuth y AdminInitiateAuth. La autenticación OTP solo está disponible en un AuthFlow basado en opciones de USER_AUTH, donde puede solicitar una opción de inicio de sesión preferida o elegir la opción sin contraseña en los AvailableChallenges de un usuario. Para que un usuario inicie sesión en una aplicación, configure el cuerpo de su solicitud InitiateAuth o AdminInitiateAuth de la siguiente manera. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

En este ejemplo, no sabemos de qué forma quiere iniciar sesión el usuario. Si añadimos un parámetro PREFERRED_CHALLENGE y el desafío preferido está disponible para el usuario, Amazon Cognito responde con ese desafío.

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

En lugar de eso, puede añadir "PREFERRED_CHALLENGE": "EMAIL_OTP" o "PREFERRED_CHALLENGE": "SMS_OTP" en AuthParameters en este ejemplo. Si el usuario cumple los requisitos para utilizar ese método preferido, el grupo de usuarios envía inmediatamente un código a la dirección de correo electrónico o al número de teléfono del usuario y devuelve "ChallengeName": "EMAIL_OTP" o "ChallengeName": "SMS_OTP".

Si no especifica un desafío preferido, Amazon Cognito responde con un parámetro AvailableChallenges.

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

Este usuario puede iniciar sesión sin contraseña con la OTP con mensaje de correo electrónico, la OTP con mensaje SMS y la combinación de nombre de usuario y contraseña. La aplicación puede pedirle al usuario su elección o realizar una elección en función de la lógica interna. Luego, continúa con una solicitud RespondToAuthChallenge o AdminRespondToAuthChallenge que selecciona el desafío. Supongamos que el usuario desea completar la autenticación sin contraseña con una OTP con mensaje de correo electrónico.

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

Amazon Cognito responde con un desafío EMAIL_OTP y envía un código a la dirección de correo electrónico verificada del usuario. A continuación, su aplicación debe volver a responder a este desafío.

Esta también sería la siguiente respuesta al desafío si ha solicitado EMAIL_OTP como PREFERRED_CHALLENGE.

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

Inicio de sesión sin contraseña con las claves de acceso de WebAuthn

Las claves de acceso son seguras e imponen un nivel de esfuerzo relativamente bajo a los usuarios. El inicio de sesión con clave de acceso usa autenticadores, dispositivos externos que los usuarios pueden usar para la autenticación. Las contraseñas habituales exponen a los usuarios a vulnerabilidades, como la suplantación de identidad, la adivinación de contraseñas y el robo de credenciales. Con las claves de acceso, su aplicación puede beneficiarse de medidas de seguridad avanzadas en los teléfonos móviles y otros dispositivos conectados a los sistemas de información o integrados en ellos. Un flujo de trabajo de inicio de sesión con clave de acceso común comienza con una llamada al dispositivo que invoca al administrador de contraseñas o credenciales, por ejemplo, el llavero de iOS o el administrador de contraseñas de Google Chrome. El administrador de credenciales del dispositivo les pide que seleccionen una clave de acceso y la autoricen con una credencial existente o un mecanismo de desbloqueo del dispositivo. Los teléfonos modernos cuentan con escáneres faciales, escáneres de huellas digitales, patrones de desbloqueo y otros mecanismos, algunos de los cuales cumplen al mismo tiempo con los principios de autenticación reforzada del tipo algo que sabes y algo que tienes. En el caso de la autenticación mediante claves de acceso biométricas, las claves de acceso son un método del tipo algo que eres.

Quizá quiera sustituir las contraseñas por la autenticación mediante huella digital, la identificación facial o la clave de seguridad. Esto es la autenticación con clave de acceso o WebAuthn. Es habitual que los desarrolladores de aplicaciones permitan a los usuarios inscribir un dispositivo biométrico después de iniciar sesión por primera vez con una contraseña. Con los grupos de usuarios de Amazon Cognito, su aplicación puede configurar esta opción de inicio de sesión para los usuarios. La autenticación con clave de acceso no cumple los requisitos para la autenticación multifactor (MFA).

Los flujos de autenticación sin contraseña no son compatibles con la autenticación multifactor (MFA) requerida en el grupo de usuarios. Si la MFA es opcional en su grupo de usuarios, los usuarios que hayan activado la MFA no podrán iniciar sesión con un primer factor sin contraseña. Los usuarios que no tengan una preferencia de MFA en un grupo de usuarios con MFA opcional pueden iniciar sesión con factores sin contraseña. Para obtener más información, consulte Cosas que debe saber acerca de la MFA de grupos de usuarios.

¿Qué son las claves de acceso?

Las claves de acceso simplifican la experiencia del usuario, ya que eliminan la necesidad de recordar contraseñas complejas o introducir contraseñas de un solo uso (OTP). Las claves de acceso se basan en los estándares WebAuthn y CTAP2 creados por el World Wide Web Consortium (W3C) y la FIDO (Fast Identity Online) Alliance. Los navegadores y las plataformas implementan estos estándares, proporcionan API para que las aplicaciones web o móviles inicien un proceso de registro o autenticación de claves de acceso y aportan una interfaz de usuario para que el usuario seleccione un autenticador de clave de acceso e interactúe con él.

Cuando un usuario registra un autenticador en un sitio web o una aplicación, el autenticador crea un par de claves público-privado. Los navegadores y las plataformas WebAuthn envían la clave pública al backend de aplicación del sitio web o la aplicación. El autenticador guarda la clave privada, los ID de las claves y los metadatos sobre el usuario y la aplicación. Cuando el usuario quiere autenticarse en la aplicación registrada con su autenticador registrado, la aplicación genera un desafío aleatorio. La respuesta a este desafío es la firma digital del desafío generada con la clave privada del autenticador para esa aplicación y usuario, así como los metadatos relevantes. El navegador o la plataforma de la aplicación reciben la firma digital y la pasan al backend de la aplicación. A continuación, la aplicación valida la firma con la clave pública almacenada.

nota

La aplicación no recibe ningún secreto de autenticación que los usuarios proporcionen a su autenticador, ni recibe información sobre la clave privada.

A continuación, se muestran algunos ejemplos y capacidades de los autenticadores actualmente en el mercado. Un autenticador puede cumplir con alguna de estas categorías o con todas ellas.

  • Algunos autenticadores verifican al usuario con factores como un PIN, una entrada biométrica con un rostro o huella digital o un código de acceso antes de conceder dicho acceso, lo que garantiza que solo el usuario legítimo pueda autorizar las acciones. Otros autenticadores no tienen ninguna función de verificación de usuario y algunos pueden omitir la verificación de usuario cuando una aplicación no la requiere.

  • Algunos autenticadores, como los tokens de hardware YubiKey, son portátiles. Se comunican con los dispositivos a través de conexiones USB, Bluetooth o NFC. Algunos autenticadores son locales y están vinculados a una plataforma, como Windows Hello en un ordenador o Face ID en un iPhone. El usuario puede transportar un autenticador vinculado a un dispositivo si es lo suficientemente pequeño, como un dispositivo móvil. A veces, los usuarios pueden conectar su autenticador de hardware a muchas plataformas diferentes mediante comunicación inalámbrica. Por ejemplo, los usuarios de los navegadores de escritorio pueden usar su teléfono inteligente como autenticador de clave de acceso cuando escanean un código QR.

  • Algunas claves de acceso vinculadas a la plataforma se sincronizan con la nube para poder utilizarlas desde varios lugares. Por ejemplo, las claves de acceso de Face ID de los iPhones sincronizan los metadatos de las claves con las cuentas de Apple de los usuarios en su llavero de iCloud. Estas claves de acceso permiten una autenticación fluida en todos los dispositivos Apple, en lugar de requerir que los usuarios registren cada dispositivo de forma independiente. Las aplicaciones autenticadoras basadas en software, como 1Password, Dashlane y Bitwarden, sincronizan las claves de acceso en todas las plataformas en las que el usuario ha instalado la aplicación.

En la terminología de WebAuthn, los sitios web y las aplicaciones son actores de confianza. Cada clave de acceso está asociada a un identificador de usuario específico, un identificador unificado que representa los sitios web o las aplicaciones que aceptan la autenticación con clave de acceso. Los desarrolladores deben seleccionar cuidadosamente su ID de actor de confianza para tener el alcance de autenticación adecuado. Un identificador de actor de confianza es el nombre de dominio raíz de un servidor web. Una clave de acceso con esta especificación de ID de actor de confianza puede autenticar ese dominio y sus subdominios. Los navegadores y las plataformas deniegan la autenticación con clave de acceso cuando la URL del sitio web al que el usuario quiere acceder no coincide con el ID del actor de confianza. Del mismo modo, en el caso de las aplicaciones móviles, solo se puede usar una clave de acceso si la ruta de la aplicación está presente en los archivos de asociación .well-known que la aplicación pone a disposición en la ruta indicada por el ID del actor de confianza.

Las claves de acceso son reconocibles. Un navegador o una plataforma pueden reconocerlas y utilizarlas automáticamente sin necesidad de que el usuario introduzca un nombre de usuario. Cuando un usuario visita un sitio web o una aplicación que admite la autenticación con clave de acceso, puede seleccionarlas de una lista de claves que el navegador o la plataforma ya conocen, o puede escanear un código QR.

¿Cómo implementa Amazon Cognito la autenticación con clave de acceso?

Las claves de acceso son una característica opcional que está disponible en todos los planes de características, con la excepción de Lite. Solo está disponible en el flujo de autenticación basado en opciones. Con el inicio de sesión administrado, Amazon Cognito gestiona la lógica de la autenticación con clave de acceso. También puede usar la API de grupos de usuarios de Amazon Cognito en los AWS SDK para realizar la autenticación con clave de acceso en el backend de la aplicación.

Amazon Cognito reconoce las claves de acceso creadas con uno de los dos algoritmos criptográficos asimétricos, ES256(-7) y RS256(-257). La mayoría de los autenticadores admiten ambos algoritmos. De forma predeterminada, los usuarios pueden configurar cualquier tipo de autenticador, por ejemplo, tokens de hardware, teléfonos móviles inteligentes y aplicaciones de autenticación de software. Amazon Cognito no admite actualmente la aplicación de atestaciones.

En su grupo de usuarios, puede configurar la verificación de usuario como preferida u obligatoria. Esta configuración se establece de forma predeterminada en las solicitudes de API que no proporcionan un valor, y se selecciona de forma predeterminada en la consola de Amazon Cognito. Al configurar la verificación de usuarios como preferida, los usuarios pueden configurar autenticadores que no tienen la capacidad de verificación de usuarios, y las operaciones de registro y autenticación se pueden realizar correctamente sin la verificación del usuario. Para exigir la verificación de los usuarios en el registro y la autenticación con clave de acceso, cambie esta configuración a obligatoria.

El identificador del actor de confianza (RP) que establezca en la configuración de la clave de acceso es una decisión importante. Si no especifica lo contrario y la versión de marca del dominio es el inicio de sesión administrado, su grupo de usuarios esperará de forma predeterminada que el nombre de su dominio personalizado sea el ID del RP. Si no tiene un dominio personalizado y no especifica lo contrario, su grupo de usuarios utilizará de forma predeterminada un ID de RP de su dominio de prefijo. También puede configurar su ID de RP para que sea cualquier nombre de dominio que no figure en la lista de sufijos públicos (PSL). La entrada de su ID de RP se aplica al registro y la autenticación con clave de acceso en el inicio de sesión administrado y en la autenticación del SDK. La clave de acceso solo funciona en aplicaciones móviles, ya que Amazon Cognito puede localizar un archivo de asociación .well-known con su ID de RP como dominio. Como práctica recomendada, determine y establezca el valor del ID del actor de confianza antes de que su sitio web o aplicación estén disponibles públicamente. Si cambia su ID de RP, los usuarios deberán volver a registrarse con el nuevo ID de RP.

Cada usuario puede registrar hasta 20 claves de acceso. Solo pueden registrar una clave de acceso después de haber iniciado sesión en su grupo de usuarios al menos una vez. El inicio de sesión administrado supone un esfuerzo considerable para el registro de la clave de acceso. Al habilitar la autenticación con clave de acceso para un grupo de usuarios y un cliente de aplicación, el grupo de usuarios con un dominio de inicio de sesión administrado recuerda a los usuarios finales que deben registrar una clave de acceso después de crear una nueva cuenta de usuario. También puede invocar los navegadores de los usuarios en cualquier momento para dirigirlos a una página de inicio de sesión administrado para el registro de la clave de acceso. Los usuarios deben proporcionar un nombre de usuario antes de que Amazon Cognito pueda iniciar la autenticación con clave de acceso. El inicio de sesión administrado lo gestiona automáticamente. La página de inicio de sesión solicita un nombre de usuario, valida que el usuario tenga registrada al menos una clave de acceso y, a continuación, solicita el inicio de sesión con la clave de acceso. Del mismo modo, las aplicaciones basadas en el SDK deben solicitar un nombre de usuario y proporcionarlo en la solicitud de autenticación.

Cuando configura la autenticación de grupos de usuarios con claves de acceso y tiene un dominio personalizado y un dominio de prefijo, el ID del RP toma como valor predeterminado el nombre de dominio completo (FQDN) de su dominio personalizado. Para configurar un dominio de prefijo como ID de RP en la consola de Amazon Cognito, elimine su dominio personalizado o introduzca el FQDN del dominio de prefijo como dominio de terceros.

Activate passkey sign-in
Consola

Para activar el inicio de sesión con clave de acceso, configure su grupo de usuarios para permitir el inicio de sesión principal con uno o más tipos sin contraseña; luego, configure el cliente de aplicación para permitir el flujo USER_AUTH. En la consola de Amazon Cognito, vaya al menú Inicio de sesión en Autenticación, en la configuración de su grupo de usuarios. Edite las Opciones para el inicio de sesión basado en opciones y añada Clave de acceso a la lista de opciones disponibles.

Vaya al menú Métodos de autenticación y edite la clave de acceso.

  • La verificación de usuario es la configuración que determina si su grupo de usuarios requiere dispositivos con clave de acceso que comprueben además si el usuario actual está autorizado a utilizar una clave de acceso. Para animar a los usuarios a configurar un dispositivo con la verificación de usuario, pero sin exigirla, seleccione Preferente. Para admitir únicamente dispositivos con verificación de usuario, seleccione Obligatorio. Para obtener más información, consulte la sección User verification en w3.org.

  • El dominio para el ID de parte de confianza es el identificador que la aplicación pasará en las solicitudes de registro de clave de acceso de los usuarios. Define el destino de la relación de confianza con el emisor de las claves de acceso de los usuarios. El identificador del actor de confianza puede ser el dominio de su grupo de usuarios si

    dominio de Cognito

    El dominio de prefijo de Amazon Cognito de su grupo de usuarios.

    Dominio personalizado

    El dominio personalizado de su grupo de usuarios.

    Dominio de terceros

    El dominio de las aplicaciones que no utilizan las páginas de inicio de sesión administrado para grupos de usuarios. Esta configuración suele estar asociada a grupos de usuarios que no tienen un dominio y que se autentican con un AWS SDK y la API de grupos de usuarios en el backend.

Vaya al menú Clientes de aplicación y elija un cliente de aplicación o cree uno nuevo. Seleccione Editar y, en Flujos de autenticación, elija Seleccionar un tipo de autenticación en el inicio de sesión: ALLOW_USER_AUTH.

API/SDK

En la API de grupos de usuarios, configure SignInPolicy con las opciones de clave de acceso adecuadas en una solicitud CreateUserPool o UpdateUserPool. La opción WEB_AUTHN para la autenticación con clave de acceso debe ir acompañada de al menos otra opción. El registro de la clave de acceso requiere una sesión de autenticación existente.

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

Configure su preferencia de verificación de usuario y su ID de RP en el parámetro WebAuthnConfiguration de una solicitud SetUserPoolMfaConfig. El RelyingPartyId, el objetivo previsto de los resultados de la autenticación con clave de acceso, puede ser el prefijo de su grupo de usuarios, un dominio personalizado o un dominio que usted elija.

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

Configure su cliente de aplicación ExplicitAuthFlows con la opción requerida en una solicitud CreateUserPoolClient o UpdateUserPoolClient.

"ExplicitAuthFlows": [ "ALLOW_USER_AUTH" ]
Register a passkey (managed login)

El inicio de sesión administrado gestiona el registro de las claves de acceso por parte de los usuarios. Cuando la autenticación con clave de acceso está activa en su grupo de usuarios, Amazon Cognito les pide a los usuarios que configuren una clave de acceso al registrar una nueva cuenta de usuario.

Amazon Cognito no solicita a los usuarios que configuren una clave de acceso si ya se han registrado y no han configurado una o si usted creó su cuenta como administrador. Los usuarios de este estado deben iniciar sesión con otro factor, como una contraseña o una OTP sin contraseña, antes de poder registrar una clave de acceso.

Cómo registrar una clave de acceso
  1. Dirija al usuario a su página de inicio de sesión.

    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. Procese el resultado de la autenticación del usuario. En este ejemplo, Amazon Cognito los redirige a www.example.com con un código de autorización que la aplicación intercambia por tokens.

  3. Dirija al usuario a su página de registro y clave de acceso. El usuario dispondrá de una cookie del navegador que mantendrá su sesión de inicio de sesión. La URL de la clave de acceso toma los parámetros client_id y redirect_uri. Amazon Cognito solo permite el acceso a esta página a los usuarios autenticados. Inicie sesión en su usuario con una contraseña, una OTP con correo electrónico o una OTP con SMS; luego, invoque una URL que coincida con el siguiente patrón.

    También puede añadir otros parámetros Autorizar punto de conexión a esta solicitud, como response_type y scope.

    https://auth.example.com/passkeys/add?client_id=1example23456789&redirect_uri=https%3A%2F%2Fwww.example.com
Register a passkey (SDK)

Las credenciales de la clave de acceso se registran con metadatos en un objeto PublicKeyCreationOptions. Puede generar este objeto con las credenciales de un usuario que haya iniciado sesión y presentarlas en una solicitud de API al emisor de la clave de acceso. El emisor devolverá un objeto RegistrationResponseJSON que confirma el registro de la clave de acceso.

Para iniciar el proceso de registro de la clave de acceso, inicie sesión con un usuario que tenga una opción de inicio de sesión existente. Autorice la solicitud de API StartWebAuthnRegistration autorizada por token con el token de acceso del usuario actual. A continuación, se muestra el cuerpo de una solicitud GetWebAuthnRegistrationOptions de ejemplo.

{ "AccessToken": "eyJra456defEXAMPLE" }

La respuesta de su grupo de usuarios contiene el objeto PublicKeyCreationOptions. Presente este objeto en una solicitud de API al emisor del usuario. Proporciona información como la clave pública y el identificador del actor de confianza. El emisor responderá con un objeto RegistrationResponseJSON.

Presente la respuesta de registro en una solicitud de API CompleteWebAuthnRegistration, nuevamente autorizada con el token de acceso del usuario. Cuando el grupo de usuarios responde con una respuesta HTTP 200 con el cuerpo vacío, se registra la clave de acceso del usuario.

Sign in with a passkey

El inicio de sesión sin contraseña no tiene un AuthFlow que pueda especificar en InitiateAuth y AdminInitiateAuth. En su lugar, debe declarar un AuthFlow de USER_AUTH y solicitar una opción de inicio de sesión o elegir la opción sin contraseña en la respuesta de su grupo de usuarios. Para que un usuario inicie sesión en una aplicación, configure el cuerpo de su solicitud InitiateAuth o AdminInitiateAuth de la siguiente manera. Este conjunto de parámetros es el mínimo necesario para iniciar sesión. Hay parámetros adicionales disponibles.

En este ejemplo, sabemos que el usuario quiere iniciar sesión con una clave de acceso y añadimos un parámetro PREFERRED_CHALLENGE.

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

Amazon Cognito responde con un desafío WEB_AUTHN. Su aplicación debe responder a este desafío. Inicie una solicitud de inicio de sesión con el proveedor de la clave de acceso del usuario. Devolverá un objeto AuthenticationResponseJSON.

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

MFA después del inicio de sesión

Puede configurar los usuarios que completen el inicio de sesión con un flujo de nombre de usuario y contraseña para que se les solicite una verificación adicional con una contraseña de un solo uso desde un mensaje de correo electrónico, un mensaje SMS o una aplicación generadora de códigos. La MFA es diferente del inicio de sesión sin contraseña, el primer factor de autenticación con contraseñas de un solo uso o las claves de acceso WebAuthn que no incluyen MFA. La MFA en los grupos de usuarios es un modelo de desafío-respuesta en el que el usuario primero demuestra que conoce la contraseña y, a continuación, demuestra que tiene acceso a su dispositivo de segundo factor registrado.

Recursos de implementación

Tokens de actualización

Si quiere mantener a los usuarios conectados sin tener que volver a introducir sus credenciales, los tokens de actualización son la herramienta de la que dispone su aplicación para conservar la sesión de un usuario. Las aplicaciones pueden presentar tokens de actualización a su grupo de usuarios e intercambiarlos por nuevos tokens de ID y acceso. Con la actualización de los tokens, puede asegurarse de que un usuario que haya iniciado sesión siga activo, obtener información de atributos actualizada y actualizar los derechos de control de acceso sin la intervención del usuario.

Recursos de implementación

Autenticación personalizada

Es posible que desee configurar un método de autenticación para sus usuarios que no aparezca en esta lista. Puede hacerlo con una autenticación personalizada con activadores Lambda. En una secuencia de funciones de Lambda, Amazon Cognito genera un desafío, formula una pregunta que los usuarios deben responder, comprueba la precisión de la respuesta y, a continuación, determina si debe emitirse otro desafío. Las preguntas y respuestas pueden incluir preguntas de seguridad, solicitudes a un servicio de CAPTCHA, solicitudes a una API de servicio de MFA externa o todas ellas en secuencia.

Flujo de autenticación personalizado

Los grupos de usuarios de Amazon Cognito también permiten usar flujos de autenticación personalizados, que pueden servir de ayuda para crear un modelo de autenticación basado en desafío/respuesta mediante desencadenadores de AWS Lambda.

El flujo de autenticación personalizado hace posible los ciclos de desafíos y respuestas personalizados para satisfacer diferentes requisitos. El flujo comienza con una llamada a la operación de la API InitiateAuth, que indica el tipo de autenticación que debe utilizarse y proporciona todos los parámetros de autenticación iniciales. Amazon Cognito responde a la llamada InitiateAuth con uno de los siguientes tipos de información:

  • Un desafío para el usuario junto con una sesión y parámetros.

  • Un error si el usuario no se autentica correctamente.

  • Tokens de ID, acceso y actualización, si los parámetros proporcionados en la llamada InitiateAuth son suficientes para que el usuario inicie sesión. (Por lo general, el usuario o la aplicación deben responder primero a un desafío, pero el código personalizado debe determinarlo).

Si Amazon Cognito responde a la llamada InitiateAuth con un desafío, la aplicación reunirá más información y llamará a la operación RespondToAuthChallenge, lo que proporciona las respuestas al desafío y vuelve a pasar la sesión. Amazon Cognito responde a la llamada RespondToAuthChallenge de forma similar a la llamada InitiateAuth. Si el usuario ha iniciado sesión, Amazon Cognito proporciona tokens o si el usuario no ha iniciado sesión, Amazon Cognito proporciona otro desafío o un error. Si devuelve otro desafío, la secuencia se repite y la aplicación llama a RespondToAuthChallenge hasta que el usuario inicie sesión correctamente o se devuelva un error. Para obtener más información sobre las operaciones de la API InitiateAuth and RespondToAuthChallenge, consulte la documentación de la API.

Flujo de autenticación personalizado y desafíos

Una aplicación puede iniciar un flujo de autenticación personalizado llamando a InitiateAuth con CUSTOM_AUTH como Authflow. En el caso de un flujo de autenticación personalizado, tres desencadenadores de Lambda controlan los desafíos y la verificación de las respuestas.

  • El desencadenador de Lambda DefineAuthChallenge toma como entrada una matriz de sesiones de desafíos y respuestas anteriores. Luego genera los siguientes nombres de desafíos y valores booleanos que indican si el usuario está autenticado y se le deben otorgar tokens. Este desencadenador de Lambda es una máquina de estado que controla la ruta que sigue el usuario a través de los desafíos.

  • El desencadenador de Lambda CreateAuthChallenge toma el nombre de un desafío como entrada y genera el desafío y los parámetros para evaluar la respuesta. Cuando DefineAuthChallenge devuelve CUSTOM_CHALLENGE como el siguiente desafío, el flujo de autenticación llama a CreateAuthChallenge. El desencadenador de Lambda CreateAuthChallenge supera el siguiente tipo de desafío del parámetro de metadatos del desafío.

  • La función de Lambda VerifyAuthChallengeResponse evalúa la respuesta y devuelve un valor booleano para indicar si la respuesta ha sido válida.

Un flujo de autenticación personalizado también puede utilizar una combinación de desafíos integrados, como la verificación de contraseñas SRP y MFA mediante SMS. Puede usar desafíos personalizados como CAPTCHA o preguntas secretas.

Usar la verificación de contraseña de SRP en el flujo de autenticación personalizado

Si desea incluir SRP en un flujo de autenticación personalizado, debe comenzar con SRP.

  • Para iniciar la verificación por contraseña de SRP en un flujo personalizado, la aplicación llama a InitiateAuth con CUSTOM_AUTH como Authflow. En la asignación de AuthParameters, la solicitud de la aplicación incluye SRP_A: (el valor de SRP A) y CHALLENGE_NAME: SRP_A.

  • El flujo CUSTOM_AUTH invoca el desencadenador de Lambda DefineAuthChallenge con una sesión inicial de challengeName: SRP_A y challengeResult: true. La función de Lambda responder con challengeName: PASSWORD_VERIFIER, issueTokens: false y failAuthentication: false.

  • A continuación, la aplicación debe llamar a RespondToAuthChallenge con challengeName: PASSWORD_VERIFIER y los demás parámetros necesarios para SRP en el mapa challengeResponses.

  • Si Amazon Cognito verifica la contraseña, RespondToAuthChallenge llama al desencadenador de Lambda DefineAuthChallenge con una segunda sesión de challengeName: PASSWORD_VERIFIER y challengeResult: true. En ese momento, el desencadenador de Lambda DefineAuthChallenge responde con challengeName: CUSTOM_CHALLENGE para iniciar el desafío personalizado.

  • Si MFA está habilitado para un usuario, una vez que Amazon Cognito verifique la contraseña, se le pide al usuario que configure o inicie sesión con MFA.

nota

La página web de inicio de sesión alojada de Amazon Cognito no puede activar Desencadenadores de Lambda de desafío de autenticación personalizado.

Para obtener más información sobre los desencadenadores de Lambda, incluido el código de muestra, consulte Personalización de flujos de trabajo de grupos de usuarios con desencadenadores de Lambda.

Flujo de autenticación de migración de usuarios

Un desencadenador de Lambda para la migración de usuarios ayuda a migrar usuarios desde un sistema de administración de usuarios heredado a un grupo de usuarios. Si elige el flujo de autenticación USER_PASSWORD_AUTH, no es necesario que los usuarios restablezcan sus contraseñas durante la migración de usuarios. Durante la autenticación, este flujo envía las contraseñas de los usuarios al servicio a través de una conexión SSL cifrada.

Cuando haya migrado todos los usuarios, cambie los flujos al flujo SRP más seguro. El flujo SRP no envía ninguna contraseña a través de la red.

Para obtener más información sobre los desencadenadores de Lambda, consulte Personalización de flujos de trabajo de grupos de usuarios con desencadenadores de Lambda.

Para obtener más información acerca de la migración de usuarios con un desencadenador de Lambda, consulte Importación de usuarios con un desencadenador de Lambda para la migración de usuarios.