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:
-
¿Quiero permitir que los usuarios inicien sesión con credenciales de otros proveedores de identidad (IdP)?
-
¿Un nombre de usuario y una contraseña son suficiente como prueba de identidad?
-
¿Podrían interceptarse mis solicitudes de autenticación de nombre de usuario y contraseña? ¿Deseo que mi aplicación transmita contraseñas o que negocie la autenticación mediante hashes y sales?
-
¿Deseo permitir que los usuarios se salten la introducción de contraseñas y reciban una contraseña de un solo uso que les permita iniciar sesión?
-
¿Quiero permitir que los usuarios inicien sesión con una huella digital, el rostro o una clave de seguridad de hardware?
-
¿Cuándo quiero pedir la autenticación multifactor (MFA) si es que querré hacerlo?
-
¿Deseo que las sesiones de usuario se mantengan sin tener que volver a solicitar las credenciales?
-
¿Deseo ampliar mi modelo de autorización más allá de las funciones integradas de Amazon Cognito?
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.
Temas
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.
Recursos de implementación
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.
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
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.
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.
-
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.
-
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.
-
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
Sessionde la respuesta de la API ConfirmSignUp como parámetro de solicitudSession. -
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
Sessiones válido y no ha caducado. -
El usuario es apto para el método de autenticación OTP.
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
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.
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.
Recursos de implementación
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
InitiateAuthson 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
DefineAuthChallengetoma 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
CreateAuthChallengetoma el nombre de un desafío como entrada y genera el desafío y los parámetros para evaluar la respuesta. CuandoDefineAuthChallengedevuelveCUSTOM_CHALLENGEcomo el siguiente desafío, el flujo de autenticación llama aCreateAuthChallenge. El desencadenador de LambdaCreateAuthChallengesupera el siguiente tipo de desafío del parámetro de metadatos del desafío. -
La función de Lambda
VerifyAuthChallengeResponseevalú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
InitiateAuthconCUSTOM_AUTHcomoAuthflow. En la asignación deAuthParameters, la solicitud de la aplicación incluyeSRP_A:(el valor de SRP A) yCHALLENGE_NAME: SRP_A. -
El flujo
CUSTOM_AUTHinvoca el desencadenador de LambdaDefineAuthChallengecon una sesión inicial dechallengeName: SRP_AychallengeResult: true. La función de Lambda responder conchallengeName: PASSWORD_VERIFIER,issueTokens: falseyfailAuthentication: false. -
A continuación, la aplicación debe llamar a
RespondToAuthChallengeconchallengeName: PASSWORD_VERIFIERy los demás parámetros necesarios para SRP en el mapachallengeResponses. -
Si Amazon Cognito verifica la contraseña,
RespondToAuthChallengellama al desencadenador de LambdaDefineAuthChallengecon una segunda sesión dechallengeName: PASSWORD_VERIFIERychallengeResult: true. En ese momento, el desencadenador de LambdaDefineAuthChallengeresponde conchallengeName: CUSTOM_CHALLENGEpara 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.