View a markdown version of this page

Flusso di autenticazione - Amazon Cognito
Third-party accesso IdPAccesso tramite passwordAccesso tramite password con SRPOne-time accesso tramite passwordWebAuthn accesso con passwordMFA dopo l'accessoAggiorna i tokenAutenticazione personalizzataFlusso di autenticazione per la migrazione degli utenti

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Flusso di autenticazione

Il processo di autenticazione con i pool di utenti di Amazon Cognito può essere meglio descritto come un flusso in cui gli utenti effettuano una scelta iniziale, inviano le credenziali e rispondono a sfide aggiuntive. Quando implementi l'autenticazione di accesso gestita nella tua applicazione, Amazon Cognito gestisce il flusso di questi prompt e sfide. Quando implementi i flussi con un AWS SDK nel back-end dell'applicazione, devi creare la logica delle richieste, richiedere input agli utenti e rispondere alle sfide.

In qualità di amministratore dell'applicazione, le caratteristiche utente, i requisiti di sicurezza e il modello di autorizzazione aiutano a determinare in che modo consentire agli utenti di accedere. Ponetevi le seguenti domande.

Quando avrai le risposte a queste domande, potrai scoprire come attivare le funzionalità pertinenti e implementarle nelle richieste di autenticazione effettuate dall'applicazione.

Dopo aver impostato i flussi di accesso per un utente, puoi verificarne lo stato attuale per quanto riguarda l'MFA e i fattori di Choice-based authentication autenticazione basati sulla scelta con le richieste al funzionamento dell'API. GetUserAuthFactors Questa operazione richiede l'autorizzazione con il token di accesso di un utente che ha effettuato l'accesso. Restituisce i fattori di autenticazione dell'utente e le impostazioni MFA.

Sign-in con terze parti IdPs

I pool di utenti di Amazon Cognito fungono da intermediario di sessioni di autenticazione tra servizi IdPs come Sign in with Apple, Login with Amazon e OpenID Connect (OIDC). Questo processo è anche chiamato accesso federato o autenticazione federata. L'autenticazione federata non utilizza nessuno dei flussi di autenticazione che è possibile integrare nel client dell'app. Invece, assegni un pool di utenti configurato IdPs al tuo client dell'app. L'accesso federato avviene quando gli utenti selezionano il proprio IdP nell'accesso gestito o l'applicazione richiama una sessione con un reindirizzamento alla propria pagina di accesso IdP.

Con l'accesso federato, deleghi i fattori di autenticazione primari e MFA all'IdP dell'utente. Amazon Cognito non aggiunge gli altri flussi avanzati di questa sezione a un utente federato a meno che non li colleghi a un utente locale. Gli utenti federati non collegati hanno nomi utente, ma sono un archivio di dati di attributi mappati che in genere non vengono utilizzati per l'accesso indipendentemente dal flusso basato sul browser.

Risorse per l'implementazione

Sign-in con password permanenti

Nei pool di utenti di Amazon Cognito, ogni utente ha un nome utente. Potrebbe essere un numero di telefono, un indirizzo email o un identificatore scelto o fornito dall'amministratore. Gli utenti di questo tipo possono accedere con il proprio nome utente e la propria password e, facoltativamente, fornire l'MFA. I pool di utenti possono eseguire l'accesso con nome utente e password con operazioni pubbliche o IAM-authorized API e metodi SDK. L'applicazione può inviare direttamente la password al pool di utenti per l'autenticazione. Il pool di utenti risponde con ulteriori sfide o con i token web JSON (JWT) che sono il risultato di un'autenticazione riuscita.

Activate password sign-in

Per attivare l'autenticazione basata sul client con nome utente e password, configura il client dell'app in modo che lo consenta. Nella console Amazon Cognito, accedi al menu App Clients in Applicazioni nella configurazione del tuo pool di utenti. Per consentire l'accesso con password semplice per un'app mobile o nativa sul lato client, modifica un client dell'app e scegli Accedi con nome utente e password: ALLOW_USER_PASSWORD_AUTH in Flussi di autenticazione. Per consentire l'accesso con password semplice per un'app lato server, modifica un client dell'app e scegli Accedi con credenziali amministrative sul lato server: ALLOW_ADMIN_USER_PASSWORD_AUTH.

Per attivare l'autenticazione basata sulla scelta con nome utente e password, configura il client dell'app in modo che lo consenta. Modifica il client dell'app e scegli l'Choice-based accesso: ALLOW_USER_AUTH.

Uno screenshot della console Amazon Cognito che illustra la scelta di semplici flussi di autenticazione con password per un client di app. Le opzioni ALLOW_USER_PASSWORD_AUTH, ALLOW_ADMIN_USER_PASSWORD_AUTH e ALLOW_USER_AUTH sono state selezionate.

Per verificare che l'autenticazione tramite password sia disponibile nei flussi di autenticazione basati sulle scelte, accedi al menu e consulta la sezione in Opzioni per l'accesso basato sulla scelta. Sign-in Puoi accedere con l'autenticazione tramite password semplice se la password è visibile in Scelte disponibili. L'opzione Password include le varianti di autenticazione semplice e SRP con nome utente-password.

Una schermata della console Amazon Cognito che illustra la scelta dell'autenticazione tramite password nella configurazione di accesso basata sulla scelta USER_AUTH per un pool di utenti. L'opzione Password viene visualizzata come attiva.

Configura ExplicitAuthFlows con le tue opzioni di autenticazione preferite con nome utente e password in una richiesta or. CreateUserPoolClient UpdateUserPoolClient 

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

In una UpdateUserPool richiesta CreateUserPool or, configura Policies con i flussi di autenticazione basati sulle scelte che desideri supportare. Il PASSWORD valore in AllowedFirstAuthFactors include sia le opzioni di flusso di autenticazione con password semplice che quelle del flusso di autenticazione SRP.

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

Per far accedere un utente a un'applicazione con l'autenticazione nome utente e password, configura il corpo della tua richiesta nel modo seguente. AdminInitiateAuth InitiateAuth Questa richiesta di accesso ha esito positivo o prosegue fino alla sfida successiva se l'utente corrente è idoneo per l'autenticazione con nome utente e password. Altrimenti, risponde con un elenco di sfide di autenticazione a fattore primario disponibili. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Puoi anche omettere il PREFERRED_CHALLENGE valore e ricevere una risposta che contiene un elenco di fattori di accesso idonei per l'utente.

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

Se non hai inviato una sfida preferita o l'utente inviato non è idoneo per la sfida preferita, Amazon Cognito restituisce un elenco di opzioni in. AvailableChallenges Se AvailableChallenges include una ChallengeName risposta PASSWORD negativa, puoi continuare l'autenticazione con una risposta alla AdminRespondToAuthChallenge sfida RespondToAuthChallenge o nel formato seguente. È necessario passare un Session parametro che associ la risposta alla sfida con la risposta API alla richiesta di accesso iniziale. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Amazon Cognito risponde alle richieste di sfida preferenziale idonee e corrette e alle risposte alle sfide con token o con una PASSWORD sfida aggiuntiva obbligatoria come l'autenticazione a più fattori (MFA).

Client-based sign-in with a password

Per far accedere un utente a un'app lato client con l'autenticazione nome utente e password, configura il corpo della richiesta come segue. InitiateAuth Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Per far accedere un utente a un'app lato server con autenticazione nome utente e password, configura il corpo della richiesta come segue. AdminInitiateAuth L'applicazione deve firmare questa richiesta con le credenziali. AWS Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Amazon Cognito risponde alle richieste riuscite con token o con una sfida aggiuntiva richiesta come l'autenticazione a più fattori (MFA).

Sign-in con password permanenti e payload sicuro

Un'altra forma di metodo di accesso con nome utente e password nei pool di utenti è il protocollo Secure Remote Password (SRP). Questa opzione invia una prova della conoscenza di una password, un hash e un salt, che il pool di utenti può verificare. Senza informazioni segrete leggibili nella richiesta ad Amazon Cognito, la tua applicazione è l'unica entità che elabora le password inserite dagli utenti. L'autenticazione SRP prevede calcoli matematici che è meglio eseguire con un componente esistente che puoi importare nel tuo SDK. L'SRP è in genere implementato in applicazioni lato client come le app mobili. Per ulteriori informazioni sul protocollo, consulta la home page di The Stanford SRP. Wikipedia contiene anche risorse ed esempi. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#ImplementationsSono disponibili diverse biblioteche pubbliche per eseguire i calcoli SRP per i flussi di autenticazione.

La sequenza initiate-challenge-response dell'autenticazione Amazon Cognito convalida gli utenti e le relative password con SRP. Devi configurare il pool di utenti e il client dell'app per supportare l'autenticazione SRP, quindi implementare la logica delle richieste di accesso e delle risposte alle sfide nell'applicazione. Le tue librerie SRP possono generare numeri casuali e valori calcolati che dimostrano al tuo pool di utenti che sei in possesso della password di un utente. L'applicazione inserisce questi valori calcolati nei ChallengeParameters campi JSON-formatted AuthParameters e nei pool di utenti di Amazon Cognito, nelle operazioni API e nei metodi SDK per l'autenticazione.

Activate SRP sign-in

Per attivare l'autenticazione basata sul client con nome utente e SRP, configura il client dell'app in modo che lo consenta. Nella console Amazon Cognito, accedi al menu App Clients in Applicazioni nella configurazione del tuo pool di utenti. Per consentire l'accesso SRP per un'app mobile o nativa sul lato client, modifica un client dell'app e seleziona Accedi con password remota sicura (SRP): ALLOW_USER_SRP_AUTH in Flussi di autenticazione.

Per attivare l'autenticazione basata sulla scelta con nome utente e SRP, modifica il client dell'app e scegli l'accesso: ALLOW_USER_AUTH. Choice-based

Uno screenshot della console Amazon Cognito che illustra la scelta dei flussi di autenticazione remota sicura con password per un client di app. Le opzioni ALLOW_USER_SRP_AUTH e ALLOW_USER_AUTH sono state selezionate.

Per verificare che l'autenticazione SRP sia disponibile nei flussi di autenticazione basati sulle scelte, accedi al menu e consulta la sezione in Opzioni per l'accesso basato sulla scelta. Sign-in Puoi accedere con l'autenticazione SRP se la password è visibile in Scelte disponibili. L'opzione Password include le varianti di autenticazione in testo normale e nome utente-password SRP.

Una schermata della console Amazon Cognito che illustra la scelta dell'autenticazione tramite password nella configurazione di accesso basata sulla scelta USER_AUTH per un pool di utenti. L'opzione Password viene visualizzata come attiva.

Configura ExplicitAuthFlows con le tue opzioni di autenticazione preferite con nome utente e password in una richiesta or. CreateUserPoolClient UpdateUserPoolClient 

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

In una UpdateUserPool richiesta CreateUserPool or, configura Policies con i flussi di autenticazione basati sulle scelte che desideri supportare. Il PASSWORD valore in AllowedFirstAuthFactors include sia le opzioni di flusso di autenticazione SRP che la password in chiaro.

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

Per accedere un utente a un'applicazione con autenticazione nome utente-password con SRP, configura il corpo della richiesta o come segue. AdminInitiateAuth InitiateAuth Questa richiesta di accesso ha esito positivo o prosegue fino alla sfida successiva se l'utente corrente è idoneo per l'autenticazione con nome utente e password. Altrimenti, risponde con un elenco di sfide di autenticazione a fattore primario disponibili. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Puoi anche omettere il PREFERRED_CHALLENGE valore e ricevere una risposta che contiene un elenco di fattori di accesso idonei per l'utente.

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

Se non hai inviato una sfida preferita o l'utente inviato non è idoneo per la sfida preferita, Amazon Cognito restituisce un elenco di opzioni in. AvailableChallenges Se AvailableChallenges include una ChallengeName risposta PASSWORD_SRP negativa, puoi continuare l'autenticazione con una risposta alla AdminRespondToAuthChallenge sfida RespondToAuthChallenge o nel formato seguente. È necessario passare un Session parametro che associ la risposta alla sfida con la risposta API alla richiesta di accesso iniziale. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

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

Amazon Cognito risponde alle richieste di sfida preferenziali idonee e alle risposte alle sfide con PASSWORD_SRP una sfida. PASSWORD_VERIFIER Il cliente deve completare i calcoli SRP e rispondere alla sfida con una richiesta or. RespondToAuthChallenge 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]"
}

In caso di risposta positiva alla PASSWORD_VERIFIER sfida, Amazon Cognito emette token o un'altra sfida obbligatoria come l'autenticazione a più fattori (MFA).

Client-based sign-in with SRP

L'autenticazione SRP è più comune nell'autenticazione lato client che in quella lato server. Tuttavia, è possibile utilizzare l'autenticazione SRP con e. InitiateAuth AdminInitiateAuth Per far accedere un utente a un'applicazione, configura il corpo della tua AdminInitiateAuth richiesta InitiateAuth OR come segue. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

Il client genera SRP_A da un generatore modulo N g elevato alla potenza di un intero casuale segreto a.

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

Amazon Cognito risponde con una richiesta PASSWORD_VERIFIER. Il cliente deve completare i calcoli SRP e rispondere alla sfida in una richiesta RespondToAuthChallenge or 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]"
}

In caso di risposta positiva alla PASSWORD_VERIFIER sfida, Amazon Cognito emette token o un'altra sfida obbligatoria come l'autenticazione a più fattori (MFA).

Accesso senza password con codici monouso

Le password possono essere smarrite o rubate. Potresti voler verificare solo che i tuoi utenti abbiano accesso a un indirizzo email, numero di telefono o app di autenticazione verificati. La soluzione a questo problema è l'accesso senza password. L'applicazione può richiedere agli utenti di inserire il proprio nome utente, indirizzo email o numero di telefono. Amazon Cognito genera quindi una password monouso (OTP), un codice che devono confermare. Un codice corretto completa l'autenticazione.

One-time i flussi di autenticazione tramite password (OTP) non sono compatibili con l'autenticazione a più fattori (MFA) richiesta nel pool di utenti. L'autenticazione con chiave di accesso con verifica dell'utente può soddisfare i requisiti MFA se impostata su. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION Se l'MFA è opzionale nel tuo pool di utenti, gli utenti che hanno attivato l'MFA non possono accedere con un primo fattore OTP. Gli utenti che non hanno una preferenza MFA in un pool di MFA-optional utenti possono accedere con fattori senza password. Per ulteriori informazioni, consulta Cose da sapere sull'MFA del pool di utenti.

Quando un utente inserisce correttamente un codice ricevuto in un SMS o in un messaggio e-mail come parte dell'autenticazione senza password, oltre ad autenticare l'utente, il pool di utenti contrassegna l'indirizzo email o il numero di telefono non verificato dell'utente come verificato. Anche lo stato dell'utente è passato da UNCONFIRMED aCONFIRMED, indipendentemente dal fatto che tu abbia configurato il pool di utenti per la verifica automatica degli indirizzi e-mail o dei numeri di telefono.

Nuove opzioni con accesso senza password

Quando attivi l'autenticazione senza password nel tuo pool di utenti, cambia il funzionamento di alcuni flussi di utenti.

  1. Gli utenti possono registrarsi senza password e scegliere un fattore senza password al momento dell'accesso. Puoi anche creare utenti senza password come amministratore.

  2. Gli utenti importati con un file CSV possono accedere immediatamente con un fattore senza password. Non sono tenuti a impostare una password prima dell'accesso.

  3. Gli utenti che non dispongono di una password possono inviare richieste ChangePassword API senza il PreviousPassword parametro.

Accesso automatico con OTP

Gli utenti che si iscrivono e confermano i propri account utente tramite OTP tramite e-mail o SMS possono accedere automaticamente con il fattore senza password corrispondente al messaggio di conferma. Nell'interfaccia utente di accesso gestito, gli utenti che confermano i propri account e sono idonei all'accesso OTP con il metodo di invio del codice di conferma procedono automaticamente al primo accesso dopo aver fornito il codice di conferma. Nella tua applicazione personalizzata con un AWS SDK, passa i seguenti parametri a un'operazione or. InitiateAuth AdminInitiateAuth

Puoi superare un valore PREFERRED_CHALLENGE pari a EMAIL_OTP oSMS_OTP, ma non è obbligatorio. Il Session parametro fornisce una prova di autenticazione e Amazon Cognito ignora la data in AuthParameters cui si passa un codice di sessione valido.

L'operazione di accesso restituisce la risposta che indica l'avvenuta autenticazione AuthenticationResult, senza ulteriori problemi se le seguenti condizioni sono vere.

  • Il Session codice è valido e non è scaduto.

  • L'utente è idoneo per il metodo di autenticazione OTP.

Activate passwordless sign-in
Console

Per attivare l'accesso senza password, configura il tuo pool di utenti in modo che consenta l'accesso principale con uno o più tipi senza password, quindi configura il client dell'app per consentire il flusso. USER_AUTH Nella console Amazon Cognito, vai al Sign-in menu alla voce Autenticazione nella configurazione del tuo pool di utenti. Modifica le opzioni per l'accesso basato sulla scelta e scegli Password monouso per messaggio e-mail o Password monouso per messaggi SMS. Puoi attivare entrambe le opzioni. Salvare le modifiche.

Accedi al menu App client e scegli un app client o creane uno nuovo. Seleziona Modifica e scegli Seleziona un tipo di autenticazione all'accesso: ALLOW_USER_AUTH.

API/SDK

Nell'API dei pool di utenti, configura SignInPolicy con le opzioni senza password appropriate in una richiesta or. CreateUserPool UpdateUserPool 

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

Configura il client dell'app ExplicitAuthFlows con l'opzione richiesta in una richiesta CreateUserPoolClient or UpdateUserPoolClient.

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

L'accesso senza password non prevede un client AuthFlow che puoi specificare in e. InitiateAuth AdminInitiateAuth L'autenticazione OTP è disponibile solo in modalità basata sulla scelta AuthFlow diUSER_AUTH, dove puoi richiedere un'opzione di accesso preferita o scegliere l'opzione senza password tra quella di un utente. AvailableChallenges Per far accedere un utente a un'applicazione, configura il corpo della tua richiesta nel modo seguente. InitiateAuth AdminInitiateAuth Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

In questo esempio, non sappiamo in che modo l'utente desidera accedere. Se aggiungiamo un PREFERRED_CHALLENGE parametro e la sfida preferita è disponibile per l'utente, Amazon Cognito risponde con quella sfida.

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

Puoi invece aggiungere "PREFERRED_CHALLENGE": "EMAIL_OTP" o "PREFERRED_CHALLENGE": "SMS_OTP" a AuthParameters in questo esempio. Se l'utente è idoneo per quel metodo preferito, il pool di utenti invia immediatamente un codice all'indirizzo email o al numero di telefono dell'utente e restituisce "ChallengeName": "EMAIL_OTP" o"ChallengeName": "SMS_OTP".

Se non specifichi una sfida preferita, Amazon Cognito risponde con un AvailableChallenges parametro.

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

Questo utente è idoneo all'accesso senza password con messaggio e-mail OTP, SMS OTP e nome utente-password. L'applicazione può richiedere all'utente la selezione o effettuare una selezione in base alla logica interna. Quindi procede con una AdminRespondToAuthChallenge richiesta RespondToAuthChallenge o che seleziona la sfida. Supponiamo che l'utente desideri completare l'autenticazione senza password con un messaggio di posta elettronica OTP.

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

Amazon Cognito risponde con una EMAIL_OTP sfida e invia un codice all'indirizzo email verificato dell'utente. La tua applicazione deve quindi rispondere nuovamente a questa sfida.

Questa sarebbe anche la prossima risposta alla sfida se la richiedessi EMAIL_OTP comePREFERRED_CHALLENGE.

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

Accesso senza password con password WebAuthn

Le password sono sicure e richiedono un livello di impegno relativamente basso per gli utenti. L'accesso con password utilizza autenticatori, dispositivi esterni con cui gli utenti possono autenticarsi. Le password regolari espongono gli utenti a vulnerabilità come il phishing, l'individuazione delle password e il furto delle credenziali. Con le password, l'applicazione può beneficiare di misure di sicurezza avanzate su telefoni cellulari e altri dispositivi collegati o integrati nei sistemi informativi. Un flusso di lavoro comune per l'accesso con password inizia con una chiamata al dispositivo che richiama il gestore delle password o delle credenziali, ad esempio il portachiavi iOS o il gestore di password di Google Chrome. Il gestore delle credenziali sul dispositivo richiede loro di selezionare una passkey e autorizzarla con una credenziale esistente o un meccanismo di sblocco del dispositivo. I telefoni moderni sono dotati di scanner facciali, scanner di impronte digitali, schemi di sblocco e altri meccanismi, alcuni dei quali soddisfano contemporaneamente i principi di autenticazione avanzata e ciò che si conosce. Nel caso dell'autenticazione con chiave di accesso biometrica, le chiavi di accesso rappresentano qualcosa che sei.

Potresti voler sostituire le password con l'autenticazione tramite impronta digitale, facciale o chiave di sicurezza. Si tratta di una chiave di accesso o autenticazione. WebAuthn È normale che gli sviluppatori di applicazioni consentano agli utenti di registrare un dispositivo biometrico dopo il primo accesso con una password. Con i pool di utenti di Amazon Cognito, l'applicazione può configurare questa opzione di accesso per gli utenti. L'autenticazione con password può soddisfare i requisiti di autenticazione a più fattori (MFA) quando il pool di utenti è impostato su. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION In questa configurazione, l'autenticazione con chiave di accesso con verifica dell'utente viene considerata autenticazione a più fattori.

One-time i flussi di autenticazione tramite password (OTP) non sono compatibili con l'autenticazione a più fattori (MFA) richiesta nel pool di utenti. L'autenticazione con chiave di accesso con verifica dell'utente può soddisfare i requisiti MFA se impostata su. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION Se l'MFA è opzionale nel tuo pool di utenti, gli utenti che hanno attivato l'MFA non possono accedere con un primo fattore OTP. Gli utenti che non hanno una preferenza MFA in un pool di MFA-optional utenti possono accedere con fattori senza password. Per ulteriori informazioni, consulta Cose da sapere sull'MFA del pool di utenti.

Cosa sono le password?

Le password semplificano l'esperienza utente eliminando la necessità di ricordare password complesse o inserire OTP. Le password si basano sugli standard CTAP2 WebAuthn e sono stati redatti dal World Wide Web Consortium (W3C) e dalla FIDO (Fast Identity Online) Alliance. I browser e le piattaforme implementano questi standard, forniscono API per applicazioni web o mobili per avviare un processo di registrazione o autenticazione con password e anche un'interfaccia utente per consentire all'utente di selezionare e interagire con un autenticatore di password.

Quando un utente registra un autenticatore con un sito Web o un'app, l'autenticatore crea una coppia di chiavi pubblica-privata. WebAuthn i browser e le piattaforme inviano la chiave pubblica al back-end dell'applicazione del sito Web o dell'app. L'autenticatore conserva la chiave privata, gli ID delle chiavi e i metadati relativi all'utente e all'applicazione. Quando l'utente desidera autenticarsi nell'applicazione registrata con il proprio autenticatore registrato, l'applicazione genera una richiesta casuale. La risposta a questa sfida è la firma digitale della sfida generata con la chiave privata dell'autenticatore per l'applicazione e l'utente e i metadati pertinenti. Il browser o la piattaforma applicativa riceve la firma digitale e la trasmette al back-end dell'applicazione. L'applicazione convalida quindi la firma con la chiave pubblica memorizzata.

Nota

L'applicazione non riceve alcun segreto di autenticazione che gli utenti forniscono al proprio autenticatore, né riceve informazioni sulla chiave privata.

Di seguito sono riportati alcuni esempi e funzionalità degli autenticatori attualmente sul mercato. Un autenticatore può soddisfare una o tutte queste categorie.

  • Alcuni autenticatori eseguono la verifica dell'utente con fattori come un PIN, un input biometrico con volto o impronta digitale o un codice di accesso prima di concedere l'accesso, assicurando che solo l'utente legittimo possa autorizzare le azioni. Altri autenticatori non dispongono di funzionalità di verifica dell'utente e alcuni possono ignorare la verifica dell'utente quando un'applicazione non la richiede.

  • Alcuni autenticatori, ad esempio i token YubiKey hardware, sono portatili. Comunicano con i dispositivi tramite connessioni USB, Bluetooth o NFC. Alcuni autenticatori sono locali e associati a una piattaforma, ad esempio Windows Hello su PC o Face ID su iPhone. Un autenticatore associato al dispositivo può essere utilizzato dall'utente se sufficientemente piccolo, come un dispositivo mobile. A volte gli utenti possono connettere il proprio autenticatore hardware a molte piattaforme diverse tramite comunicazione wireless. Ad esempio, gli utenti dei browser desktop possono utilizzare il proprio smartphone come autenticatore di password quando scansionano un codice QR.

  • Alcune password associate alla piattaforma si sincronizzano con il cloud in modo da poter essere utilizzate da più postazioni. Ad esempio, le password Face ID sugli iPhone sincronizzano i metadati delle passkey con gli account Apple degli utenti nel portachiavi iCloud. Queste passkey garantiscono un'autenticazione perfetta su tutti i dispositivi Apple, invece di richiedere che gli utenti registrino ogni dispositivo in modo indipendente. Software-based Le app di autenticazione come 1Password, Dashlane e Bitwarden sincronizzano le passkey su tutte le piattaforme su cui l'utente ha installato l'app.

Nella WebAuthn terminologia, i siti Web e le app sono interlocutori. Ogni passkey è associata a uno specifico relying party ID, un identificatore unificato che rappresenta i siti Web o le app che accettano l'autenticazione tramite passkey. Gli sviluppatori devono selezionare attentamente l'ID del proprio relying party per avere il giusto ambito di autenticazione. Un tipico ID del relying party è il nome di dominio principale di un server web. Una chiave di accesso con questa specifica dell'ID del relying party può autenticare quel dominio e i sottodomini. I browser e le piattaforme negano l'autenticazione con password quando l'URL del sito Web a cui l'utente desidera accedere non corrisponde all'ID del relying party. Analogamente, per le app mobili, una passkey può essere utilizzata solo se il percorso dell'app è presente nei file di .well-known associazione che l'applicazione rende disponibili nel percorso indicato dall'ID del relying party.

Le chiavi di accesso sono rilevabili. Possono essere riconosciute e utilizzate automaticamente da un browser o da una piattaforma senza richiedere all'utente di inserire un nome utente. Quando un utente visita un sito Web o un'app che supporta l'autenticazione con password, può selezionare da un elenco di password che il browser o la piattaforma già conoscono oppure può scansionare un codice QR.

In che modo Amazon Cognito implementa l'autenticazione con password?

Le password sono una funzionalità di attivazione disponibile in tutti i piani di funzionalità ad eccezione di Lite. È disponibile solo nel flusso di autenticazione basato sulla scelta. Con l'accesso gestito, Amazon Cognito gestisce la logica dell'autenticazione con password. Puoi anche utilizzare l'API dei pool di utenti di Amazon Cognito negli AWS SDK per eseguire l'autenticazione con password nel back-end dell'applicazione.

Amazon Cognito riconosce le chiavi di accesso create utilizzando uno dei due algoritmi crittografici asimmetrici, ES256 (-7) e RS256 (-257). La maggior parte degli autenticatori supporta entrambi gli algoritmi. Per impostazione predefinita, gli utenti possono configurare qualsiasi tipo di autenticatore, ad esempio token hardware, smartphone mobili e app di autenticazione software. Amazon Cognito attualmente non supporta l'applicazione degli attestati. https://csrc.nist.gov/glossary/term/attestation

Nel tuo pool di utenti, puoi configurare la verifica degli utenti in modo che sia preferita o obbligatoria. Questa impostazione è predefinita come preferita nelle richieste API che non forniscono un valore e preferenziale è selezionata per impostazione predefinita nella console di Amazon Cognito. Quando si imposta la verifica utente su Preferenziale, gli utenti possono configurare autenticatori che non dispongono della funzionalità di verifica utente e le operazioni di registrazione e autenticazione possono avere successo senza la verifica dell'utente. Per imporre la verifica degli utenti nella registrazione e nell'autenticazione con password, modifica questa impostazione su Obbligatoria.

L'ID relying party (RP) impostato nella configurazione della passkey è una decisione importante. Se non specifichi diversamente e la versione del branding del dominio è l'accesso gestito, per impostazione predefinita il pool di utenti prevede il nome del dominio personalizzato come ID RP. Utilizzo del proprio dominio per l'accesso gestito Se non disponi di un dominio personalizzato e non specifichi diversamente, il pool di utenti utilizza per impostazione predefinita un ID RP del tuo dominio di prefisso. Utilizzo del dominio con prefisso Amazon Cognito per l'accesso gestito Puoi anche configurare il tuo ID RP in modo che sia qualsiasi nome di dominio non presente nell'elenco pubblico dei suffissi (PSL). L'ID RP inserito si applica alla registrazione e all'autenticazione con password nell'accesso gestito e nell'autenticazione SDK. Passkey funziona solo nelle applicazioni mobili. Amazon Cognito è in grado di individuare un file di .well-known associazione con il tuo ID RP come dominio. Come best practice, determina e imposta il valore del tuo relying party ID prima che il tuo sito web o la tua app siano disponibili al pubblico. Se modifichi il tuo ID RP, gli utenti devono registrarsi nuovamente con il nuovo ID RP.

Ogni utente può registrare fino a 20 passkey. Possono registrare una passkey solo dopo aver effettuato l'accesso al pool di utenti almeno una volta. L'accesso gestito semplifica notevolmente la registrazione della passkey. Quando abiliti l'autenticazione con password per un pool di utenti e un client di app, il pool di utenti con un dominio di accesso gestito ricorda agli utenti finali di registrare una passkey dopo aver registrato un nuovo account utente. Puoi anche richiamare i browser degli utenti in qualsiasi momento per indirizzarli a una pagina di accesso gestita per la registrazione della passkey. Gli utenti devono fornire un nome utente prima che Amazon Cognito possa avviare l'autenticazione con password. L'accesso gestito lo gestisce automaticamente. La pagina di accesso richiede un nome utente, convalida che l'utente abbia almeno una passkey registrata e quindi richiede l'accesso con password. Analogamente, SDK-based le applicazioni devono richiedere un nome utente e fornirlo nella richiesta di autenticazione.

Quando si configura l'autenticazione del pool di utenti con le chiavi di accesso e si dispone di un dominio personalizzato e di un dominio con prefisso, l'ID RP per impostazione predefinita è il nome di dominio completo (FQDN) del dominio personalizzato. Per impostare un dominio con prefisso come ID RP nella console Amazon Cognito, elimina il dominio personalizzato o inserisci il nome completo del dominio con prefisso come dominio. Third-party

Activate passkey sign-in
Console

Per attivare l'accesso con password, configura il tuo pool di utenti in modo da consentire l'accesso principale con uno o più tipi senza password, quindi configura il client dell'app per consentire il flusso. USER_AUTH Nella console Amazon Cognito, vai al Sign-in menu alla voce Autenticazione nella configurazione del tuo pool di utenti. Modifica le opzioni per l'accesso basato sulle scelte e aggiungi Passkey all'elenco delle scelte disponibili.

Vai al menu Metodi di autenticazione e modifica Passkey.

  • La verifica utente è l'impostazione per stabilire se il pool di utenti richiede dispositivi con chiave di accesso che eseguano controlli aggiuntivi per verificare che l'utente corrente sia autorizzato per una password. Per incoraggiare gli utenti a configurare un dispositivo con la verifica utente, ma non a richiederla, seleziona Preferito. Per supportare solo i dispositivi con la verifica dell'utente, seleziona Richiesto. Per ulteriori informazioni, consulta Verifica utente su w3.org.

  • Il Domain for relying party ID è l'identificatore che l'applicazione trasmetterà nelle richieste di registrazione della password degli utenti. Stabilisce l'obiettivo del rapporto di fiducia con l'emittente delle password degli utenti. Il tuo ID relying party può essere: il dominio del tuo pool di utenti se

    Dominio Cognito

    Il dominio con prefisso Amazon Cognito del tuo pool di utenti.

    Dominio personalizzato

    Il dominio personalizzato del tuo pool di utenti.

    Third-party dominio

    Il dominio per le applicazioni che non utilizzano le pagine di accesso gestite dai pool di utenti. Questa impostazione è in genere associata a pool di utenti che non dispongono di un dominio ed eseguono l'autenticazione con un AWS SDK e l'API dei pool di utenti nel backend.

Accedi al menu App client e scegli un app client o creane uno nuovo. Seleziona Modifica e in Flussi di autenticazione, scegli Seleziona un tipo di autenticazione all'accesso: ALLOW_USER_AUTH.

API/SDK

Nell'API dei pool di utenti, configura SignInPolicy con le opzioni di password appropriate in una richiesta or. CreateUserPool UpdateUserPool L'WEB_AUTHNopzione per l'autenticazione con password deve essere accompagnata da almeno un'altra opzione. La registrazione con chiave di accesso richiede una sessione di autenticazione esistente.

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

Configura la preferenza di verifica dell'utente e l'ID RP nel WebAuthnConfiguration parametro di una richiesta. SetUserPoolMfaConfig L'RelyingPartyIdobiettivo previsto dei risultati dell'autenticazione con password può essere il prefisso del pool di utenti o il dominio personalizzato o un dominio di tua scelta.

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

Configura il client dell'app ExplicitAuthFlows con l'opzione richiesta in una CreateUserPoolClient richiesta or. UpdateUserPoolClient 

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

L'accesso gestito gestisce la registrazione delle password da parte dell'utente. Quando l'autenticazione con password è attiva nel tuo pool di utenti, Amazon Cognito richiede agli utenti di impostare una passkey al momento della registrazione di un nuovo account utente.

Amazon Cognito non richiede agli utenti di impostare una password quando si sono già registrati e non ne hanno configurata una, o se hai creato il loro account come amministratore. Gli utenti in questo stato devono accedere con un altro fattore, ad esempio una password o un codice OTP senza password, prima di poter registrare una password.

Per registrare una passkey

  1. Indirizza l'utente alla tua pagina di accesso. 

    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. Elabora il risultato dell'autenticazione dell'utente. In questo esempio, Amazon Cognito li reindirizza www.example.com con un codice di autorizzazione che l'applicazione scambia con token.

  3. Indirizza l'utente alla tua pagina register-passkey. L'utente disporrà di un cookie del browser che mantiene la sessione di accesso. L'URL della chiave di accesso richiede e parametri. client_id redirect_uri Amazon Cognito consente solo agli utenti autenticati di accedere a questa pagina. Accedi all'utente con una password, un indirizzo e-mail OTP o un SMS OTP, quindi richiama un URL che corrisponda allo schema seguente.

    Puoi anche aggiungere altri Endpoint Authorize parametri a questa richiesta, come e. response_type scope

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

Le credenziali della password vengono registrate con i metadati in un oggetto. PublicKeyCreationOptions È possibile generare questo oggetto con le credenziali di un utente che ha effettuato l'accesso e presentarle in una richiesta API all'emittente della password. L'emittente restituirà un oggetto JSON che conferma la registrazione della passkey RegistrationResponse.

Per avviare il processo di registrazione della password, accedi a un utente con un'opzione di accesso esistente. Autorizza la richiesta StartWebAuthnRegistration API autorizzata dal token con il token di accesso dell'utente corrente. Di seguito è riportato il corpo di una richiesta di esempio. GetWebAuthnRegistrationOptions

{
   "AccessToken": "eyJra456defEXAMPLE"
}

La risposta del pool di utenti contiene l'PublicKeyCreationOptionsoggetto. Presenta questo oggetto in una richiesta API all'emittente dell'utente. Fornisce informazioni come la chiave pubblica e l'ID del relying party. L'emittente risponderà con un RegistrationResponseJSON oggetto.

Presenta la risposta di registrazione in una richiesta CompleteWebAuthnRegistration API, nuovamente autorizzata con il token di accesso dell'utente. Quando il pool di utenti risponde con una risposta HTTP 200 con un corpo vuoto, la passkey dell'utente viene registrata.

Sign in with a passkey

L'accesso senza password non dispone di una password AuthFlow che puoi specificare in e. InitiateAuth AdminInitiateAuth Devi invece dichiarare di no USER_AUTH e richiedere un'opzione AuthFlow di accesso oppure scegliere l'opzione senza password dalla risposta del tuo pool di utenti. Per far accedere un utente a un'applicazione, configura il corpo della tua richiesta InitiateAuth OR AdminInitiateAuth come segue. Questo set di parametri è il minimo richiesto per l'accesso. Sono disponibili parametri aggiuntivi.

In questo esempio, sappiamo che l'utente desidera accedere con una passkey e aggiungiamo un PREFERRED_CHALLENGE parametro.

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

Amazon Cognito risponde con una richiesta WEB_AUTHN. La tua applicazione deve rispondere a questa sfida. Avvia una richiesta di accesso con il fornitore della password dell'utente. Restituirà un AuthenticationResponse oggetto JSON. 

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

MFA dopo l'accesso

È possibile configurare gli utenti che completano l'accesso con un flusso di nome utente e password in modo che venga richiesta un'ulteriore verifica con una password monouso da un messaggio e-mail, un messaggio SMS o un'applicazione per la generazione di codice. L'MFA è distinto dall'accesso senza password con password monouso. Tuttavia, le password con verifica utente possono soddisfare i requisiti MFA come primo fattore quando si configura come parte del pool di utenti. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION WebAuthnConfiguration Le chiavi di accesso non possono essere utilizzate come secondo fattore per l'accesso tramite password. Per i flussi basati su password, l'MFA nei pool di utenti è un modello di sfida e risposta in cui un utente dimostra innanzitutto di conoscere la password, quindi dimostra di avere accesso al dispositivo di secondo fattore registrato.

Risorse per l'implementazione

Aggiorna i token

Quando desideri mantenere gli utenti connessi senza reinserire le proprie credenziali, i token di aggiornamento sono lo strumento di cui dispone l'applicazione per rendere persistente la sessione di un utente. Le applicazioni possono presentare token di aggiornamento al pool di utenti e scambiarli con nuovi ID e token di accesso. Con l'aggiornamento dei token, puoi assicurarti che un utente che ha effettuato l'accesso sia ancora attivo, ottenere informazioni aggiornate sugli attributi e aggiornare i diritti di controllo degli accessi senza l'intervento dell'utente.

Risorse per l'implementazione

Autenticazione personalizzata

Potresti voler configurare un metodo di autenticazione per i tuoi utenti che non è elencato qui. Puoi farlo con l'autenticazione personalizzata con trigger Lambda. In una sequenza di funzioni Lambda, Amazon Cognito emette una sfida, pone una domanda a cui gli utenti devono rispondere, verifica la precisione della risposta, quindi determina se deve essere emessa un'altra sfida. Le domande e le risposte possono includere domande di sicurezza, richieste a un servizio CAPTCHA, richieste a un'API di servizio MFA esterna o tutte in sequenza.

Risorse per l'implementazione

Flusso di autenticazione personalizzato

I pool di utenti di Amazon Cognito consentono inoltre di utilizzare flussi di autenticazione personalizzati, che possono aiutarti a creare un modello di autenticazione challenge/response basato sui AWS Lambda trigger.

Il flusso di autenticazione personalizzato permette cicli personalizzati di richieste e risposte per soddisfare diversi requisiti. Il flusso comincia con una chiamata all'operazione API InitiateAuth che indica il tipo di autenticazione da utilizzare e fornisce qualsiasi parametro di autenticazione iniziale. Amazon Cognito risponde alla chiamata InitiateAuth con uno dei seguenti tipi di informazione:

  • Una sfida all'utente, insieme a una sessione e parametri.

  • Un errore se l'utente non si autentica correttamente.

  • Token ID, di accesso e di aggiornamento, se i parametri forniti nella chiamata InitiateAuth sono sufficienti per l'accesso dell'utente. (In genere l'utente o l'app devono prima rispondere a una sfida, ma è il tuo codice personalizzato a decidere se è il caso.)

Se Amazon Cognito risponde alla chiamata InitiateAuth con una sfida, l'app raccoglierà più input e chiamerà l'operazione RespondToAuthChallenge. Questa chiamata fornisce le risposte alla sfida e restituisce la sessione. Amazon Cognito risponde alla chiamata RespondToAuthChallenge in modo simile alla chiamata InitiateAuth. Se l'utente ha effettuato l'accesso, Amazon Cognito fornisce i token, se non ha effettuato l'accesso, Amazon Cognito restituisce un'altra sfida o un errore. Se Amazon Cognito restituisce un'altra sfida, la sequenza si ripete: l'app chiama RespondToAuthChallenge fino a quando l'utente non riesce a effettuare l'accesso o non viene restituito un errore. Per ulteriori dettagli sulle operazioni InitiateAuth e API RespondToAuthChallenge, consulta la documentazione API.

Flusso di autenticazione personalizzato e sfide

Un'app è in grado di avviare un flusso di autenticazione chiamando InitiateAuth con CUSTOM_AUTH come Authflow. Nel caso di un flusso di autenticazione personalizzato, tre trigger Lambda controllano le sfide e la verifica delle risposte.

  • Il trigger Lambda DefineAuthChallenge usa come input una matrice di sessioni di sfide e risposte precedenti. Quindi genera il nome della sfida successiva e i booleani che indicano se l'utente è autenticato e deve ricevere i token o meno. Questo trigger Lambda è una macchina a stati che controlla il percorso dell'utente attraverso le richieste.

  • Il trigger Lambda CreateAuthChallenge utilizza il nome di una sfida come input e genera la sfida e i parametri per valutare la risposta. Quando DefineAuthChallenge restituisce CUSTOM_CHALLENGE come sfida sucessiva, il flusso di autenticazione chiama CreateAuthChallenge. Il trigger Lambda CreateAuthChallenge passa il tipo di sfida successiva nel parametro di metadati della richiesta.

  • La funzione Lambda VerifyAuthChallengeResponse valuta la risposta e restituisce un valore booleano per indicare se la risposta era valida.

Un flusso di autenticazione personalizzato può anche utilizzare una combinazione di sfide incorporate, come la verifica della password SRP e MFA tramite SMS. Può utilizzare sfide personalizzate come CAPTCHA o domande segrete.

Utilizzare la verifica della password SRP nel flusso di autenticazione personalizzato

Se intendi includere la verifica SRP in un flusso di autenticazione personalizzato, è necessario partire da essa.

  • Per avviare la verifica della password SRP in un flusso personalizzato, l'app chiama InitiateAuth con CUSTOM_AUTH come Authflow. Nella mappa AuthParameters, la richiesta dalla tua app include SRP_A: (il valore SRP A) e CHALLENGE_NAME: SRP_A.

  • Il flusso CUSTOM_AUTH richiama il trigger Lambda DefineAuthChallenge con una sessione iniziale di challengeName: SRP_A e challengeResult: true. La tua funzione Lambda risponde con challengeName: PASSWORD_VERIFIER, issueTokens: false e failAuthentication: false.

  • L'app deve quindi chiamare RespondToAuthChallenge con challengeName: PASSWORD_VERIFIER e gli altri parametri necessari per SRP nella mappa challengeResponses.

  • Se Amazon Cognito verifica la password, RespondToAuthChallenge richiama il trigger Lambda DefineAuthChallenge con una seconda sessione di challengeName: PASSWORD_VERIFIER e challengeResult: true. A quel punto, il trigger DefineAuthChallenge Lambda risponde con challengeName: CUSTOM_CHALLENGE per avviare la richiesta personalizzata.

  • Se MFA è abilitato per un utente, dopo che Amazon Cognito verifica la password, all'utente viene richiesto di configurare o accedere con MFA.

Nota

La pagina Web di accesso ospitata di Amazon Cognito non può attivare i Trigger Lambda di richieste di autenticazione personalizzate.

Per ulteriori informazioni sui trigger lambda, compreso il codice di esempio, consulta Personalizzazione di flussi di lavoro di bacini d'utenza con trigger Lambda.

Flusso di autenticazione per la migrazione degli utenti

Il trigger Lambda per la migrazione degli utenti aiuta a migrare gli utenti da un sistema legacy di gestione degli utenti al bacino d'utenza. Se scegli il flusso di autenticazione USER_PASSWORD_AUTH, gli utenti non dovranno reimpostare le password durante la migrazione. Questo flusso invia le password degli utenti al servizio tramite una connessione SSL crittografata durante l'autenticazione.

Una volta completata la migrazione di tutti gli utenti, passa i flussi al flusso SRP più sicuro. Il flusso SRP non invia le password sulla rete.

Per ulteriori informazioni sui trigger Lambda, consulta Personalizzazione di flussi di lavoro di bacini d'utenza con trigger Lambda.

Per ulteriori informazioni sulla migrazione degli utenti con un trigger Lambda, consulta Importazione di utenti con un trigger Lambda per la migrazione di utenti.