Alur otentikasi - Amazon Cognito
Masuk dengan pihak ketiga IdPsMasuk dengan kata sandi persistenMasuk dengan kata sandi persisten dan muatan amanMasuk tanpa kata sandi dengan kata sandi satu kaliMasuk kunci sandiMFA setelah masukSegarkan tokenOtentikasi kustomAlur autentikasi migrasi pengguna

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Alur otentikasi

Proses otentikasi dengan kumpulan pengguna Amazon Cognito dapat digambarkan sebagai alur di mana pengguna membuat pilihan awal, mengirimkan kredensional, dan menanggapi tantangan tambahan. Saat Anda menerapkan otentikasi login terkelola dalam aplikasi Anda, Amazon Cognito mengelola alur permintaan dan tantangan ini. Saat mengimplementasikan flow dengan AWS SDK di back end aplikasi, Anda harus membuat logika permintaan, meminta pengguna untuk masukan, dan menanggapi tantangan.

Sebagai administrator aplikasi, karakteristik pengguna, persyaratan keamanan, dan model otorisasi membantu menentukan bagaimana Anda ingin mengizinkan pengguna untuk masuk. Tanyakan pada diri Anda pertanyaan-pertanyaan berikut.

Ketika Anda memiliki jawaban atas pertanyaan-pertanyaan ini, Anda dapat mempelajari cara mengaktifkan fitur yang relevan dan menerapkannya dalam permintaan otentikasi yang dibuat aplikasi Anda.

Setelah menyiapkan alur login untuk pengguna, Anda dapat memeriksa status mereka saat ini untuk MFA dan faktor autentikasi berbasis pilihan dengan permintaan ke operasi API. GetUserAuthFactors Operasi ini memerlukan otorisasi dengan token akses pengguna yang masuk. Ini mengembalikan faktor otentikasi pengguna dan pengaturan MFA.

Masuk dengan pihak ketiga IdPs

Kumpulan pengguna Amazon Cognito berfungsi sebagai broker perantara sesi otentikasi antara IdPs seperti Masuk dengan Apple, Login with Amazon, dan layanan OpenID Connect (OIDC). Proses ini juga disebut federated sign-in atau federated authentication. Otentikasi federasi tidak menggunakan alur autentikasi apa pun yang dapat Anda buat ke klien aplikasi Anda. Sebagai gantinya, Anda menetapkan kumpulan pengguna yang dikonfigurasi IdPs ke klien aplikasi Anda. Masuk federasi terjadi ketika pengguna memilih IDP mereka di login terkelola atau aplikasi Anda memanggil sesi dengan pengalihan ke halaman masuk iDP mereka.

Dengan login federasi, Anda mendelegasikan faktor autentikasi primer dan MFA ke IDP pengguna. Amazon Cognito tidak menambahkan alur lanjutan lainnya di bagian ini ke pengguna federasi kecuali Anda menautkannya ke pengguna lokal. Pengguna federasi yang tidak terhubung memiliki nama pengguna, tetapi mereka adalah penyimpanan data atribut yang dipetakan yang biasanya tidak digunakan untuk login terlepas dari alur berbasis browser.

Sumber daya implementasi

Masuk dengan kata sandi persisten

Di kumpulan pengguna Amazon Cognito, setiap pengguna memiliki nama pengguna. Ini mungkin nomor telepon, alamat email, atau pengenal yang dipilih atau disediakan administrator. Pengguna jenis ini dapat masuk dengan nama pengguna dan kata sandi mereka, dan secara opsional memberikan MFA. Kumpulan pengguna dapat melakukan login nama pengguna-kata sandi dengan operasi API publik atau yang diautentikasi IAM dan metode SDK. Aplikasi Anda dapat langsung mengirim kata sandi ke kumpulan pengguna Anda untuk otentikasi. Kumpulan pengguna Anda merespons dengan tantangan tambahan atau token web JSON (JWTs) yang merupakan hasil dari otentikasi yang berhasil.

Activate password sign-in

Untuk mengaktifkan login dengan nama pengguna dan kata sandi, konfigurasikan klien aplikasi Anda untuk mengizinkannya. Di konsol Amazon Cognito, navigasikan ke menu Klien aplikasi di bawah Aplikasi dalam konfigurasi kumpulan pengguna Anda. Untuk mengizinkan login nama pengguna kata sandi untuk aplikasi seluler atau native sisi klien, pilih atau buat klien aplikasi dan pilih Masuk dengan nama pengguna dan kata sandi: ALLOW_USER_PASSWORD_AUTH. Untuk mengizinkan login nama pengguna-kata sandi untuk sisi server atau aplikasi web, pilih Masuk dengan kredenal administratif sisi server: ALLOW_ADMIN_USER_PASSWORD_AUTH.

Di API kumpulan pengguna, konfigurasikan ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClientpermintaan CreateUserPoolClientatau.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_PASSWORD_AUTH",
   "ALLOW_ADMIN_USER_PASSWORD_AUTH"
]
Choice-based sign-in with a password

Untuk memasukkan pengguna ke aplikasi sisi klien dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. InitiateAuth Amazon Cognito merespons dengan a ChallengeName PASSWORD jika pengguna saat ini memenuhi syarat untuk autentikasi nama pengguna-kata sandi. Jika tidak, ia merespons dengan daftar tantangan yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Untuk memasukkan pengguna ke aplikasi sisi server dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. AdminInitiateAuth Aplikasi Anda harus menandatangani permintaan ini dengan AWS kredensi. Amazon Cognito merespons dengan a ChallengeName PASSWORD jika pengguna saat ini memenuhi syarat untuk autentikasi nama pengguna-kata sandi. Jika tidak, ia merespons dengan daftar tantangan yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD"
   },
   "ClientId": "1example23456789"
}
Client-based sign-in with a password

Untuk memasukkan pengguna ke aplikasi sisi klien dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. InitiateAuth Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

{
   "AuthFlow": "USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "Example1234!"
   },
   "ClientId": "1example23456789"
}

Untuk memasukkan pengguna ke aplikasi sisi server dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. AdminInitiateAuth Aplikasi Anda harus menandatangani permintaan ini dengan AWS kredensi. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

{
   "AuthFlow": "ADMIN_USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "Example1234!"
   },
   "ClientId": "1example23456789"
}

Masuk dengan kata sandi persisten dan muatan aman

Bentuk lain dari metode masuk nama pengguna kata sandi di kumpulan pengguna adalah dengan protokol Secure Remote Password (SRP). Opsi ini mengirimkan bukti pengetahuan tentang kata sandi—hash kata sandi dan garam—yang dapat diverifikasi oleh kumpulan pengguna Anda. Tanpa informasi rahasia yang dapat dibaca dalam permintaan ke Amazon Cognito, aplikasi Anda adalah satu-satunya entitas yang memproses kata sandi yang dimasukkan pengguna. Autentikasi SRP melibatkan perhitungan matematis yang paling baik dilakukan oleh komponen yang ada yang dapat Anda impor di SDK Anda. SRP biasanya diimplementasikan dalam aplikasi sisi klien seperti aplikasi seluler. Untuk informasi lebih lanjut tentang protokol, lihat Beranda Stanford SRP. Wikipedia juga memiliki sumber dan contoh.

Activate SRP sign-in

Untuk mengaktifkan login dengan nama pengguna dan kata sandi, konfigurasikan klien aplikasi Anda untuk mengizinkannya. Di konsol Amazon Cognito, navigasikan ke menu Klien aplikasi di bawah Aplikasi dalam konfigurasi kumpulan pengguna Anda. Untuk mengizinkan login nama pengguna kata sandi untuk aplikasi seluler atau native sisi klien, pilih atau buat klien aplikasi dan pilih Masuk dengan nama pengguna dan kata sandi: ALLOW_USER_PASSWORD_AUTH. Untuk mengizinkan login nama pengguna-kata sandi untuk sisi server atau aplikasi web, pilih Masuk dengan kredenal administratif sisi server: ALLOW_ADMIN_USER_PASSWORD_AUTH.

Di API kumpulan pengguna, konfigurasikan ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClientpermintaan CreateUserPoolClientatau.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_SRP_AUTH"
]
Choice-based sign-in with SRP

Untuk memasukkan pengguna ke aplikasi sisi klien dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. InitiateAuth Amazon Cognito merespons dengan a ChallengeName PASSWORD_SRP jika pengguna saat ini memenuhi syarat untuk autentikasi nama pengguna-kata sandi. Jika tidak, ia merespons dengan daftar tantangan yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Untuk memasukkan pengguna ke aplikasi sisi server dengan autentikasi nama pengguna-kata sandi, konfigurasikan isi permintaan Anda sebagai berikut. AdminInitiateAuth Aplikasi Anda harus menandatangani permintaan ini dengan AWS kredensi. Amazon Cognito merespons dengan a ChallengeName PASSWORD_SRP jika pengguna saat ini memenuhi syarat untuk autentikasi nama pengguna-kata sandi. Jika tidak, ia merespons dengan daftar tantangan yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD_SRP"
   },
   "ClientId": "1example23456789"
}
Client-based sign-in with SRP

Otentikasi SRP lebih umum untuk otentikasi sisi klien daripada ke sisi server. Namun, Anda dapat menggunakan otentikasi SRP dengan InitiateAuthdan. AdminInitiateAuth Untuk menandatangani pengguna ke aplikasi, konfigurasikan isi InitiateAuth atau AdminInitiateAuth permintaan Anda sebagai berikut. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

Klien menghasilkan SRP_A dari modulo generator N g dinaikkan ke kekuatan bilangan bulat acak rahasia a.

{
   "AuthFlow": "USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "SRP_A" : "g^a"
   },
   "ClientId": "1example23456789"
}

Amazon Cognito merespons dengan sebuah tantangan. PASSWORD_VERIFIER Klien Anda harus menyelesaikan perhitungan SRP dan menanggapi tantangan dalam AdminRespondToAuthChallengepermintaan RespondToAuthChallengeatau permintaan.

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

Alur otentikasi bawaan dan tantangan

Amazon Cognito berisi built-in AuthFlow dan ChallengeName nilai sehingga alur otentikasi standar dapat memvalidasi nama pengguna dan kata sandi melalui protokol Secure Remote Password (SRP). AWS SDKs Memiliki dukungan bawaan untuk aliran ini dengan Amazon Cognito.

Aliran dimulai dengan mengirim USER_SRP_AUTH sebagai AuthFlow keInitiateAuth. Anda juga mengirim USERNAME dan SRP_A nilai masukAuthParameters. Jika InitiateAuth panggilan berhasil, respons telah dimasukkan PASSWORD_VERIFIER sebagai ChallengeName dan SRP_B dalam parameter tantangan. Aplikasi kemudian memanggil RespondToAuthChallenge dengan PASSWORD_VERIFIER ChallengeName dan parameter yang diperlukan dalam ChallengeResponses. Jika panggilan ke RespondToAuthChallenge berhasil dan pengguna masuk, Amazon Cognito mengeluarkan token. Jika Anda mengaktifkan otentikasi multi-faktor (MFA) untuk pengguna, Amazon Cognito mengembalikan dari. ChallengeName SMS_MFA Aplikasi ini dapat memberikan kode yang diperlukan melalui panggilan lain keRespondToAuthChallenge.

Masuk tanpa kata sandi dengan kata sandi satu kali

Password bisa hilang atau dicuri. Anda mungkin ingin memverifikasi hanya bahwa pengguna Anda memiliki akses ke alamat email, nomor telepon, atau aplikasi autentikator terverifikasi. Solusi untuk ini adalah masuk tanpa kata sandi. Aplikasi Anda dapat meminta pengguna untuk memasukkan nama pengguna, alamat email, atau nomor telepon mereka. Amazon Cognito kemudian menghasilkan kata sandi satu kali (OTP), kode yang harus mereka konfirmasi. Kode yang berhasil menyelesaikan otentikasi. Alur otentikasi ini tidak memenuhi syarat untuk otentikasi multi-faktor (MFA).

Ketika pengguna memasukkan kode yang mereka terima dengan benar dalam pesan SMS atau email sebagai bagian dari otentikasi tanpa kata sandi, selain mengautentikasi pengguna, kumpulan pengguna Anda menandai alamat email atau atribut nomor telepon pengguna yang belum diverifikasi sebagai terverifikasi. Status pengguna juga berubah dari UNCONFIRMED keCONFIRMED, terlepas dari apakah Anda mengonfigurasi kumpulan pengguna untuk memverifikasi alamat email atau nomor telepon secara otomatis.

Opsi baru dengan login tanpa kata sandi

Saat Anda mengaktifkan autentikasi tanpa kata sandi di kumpulan pengguna, ini mengubah cara kerja beberapa alur pengguna.

  1. Pengguna dapat mendaftar tanpa kata sandi dan memilih faktor tanpa kata sandi saat mereka masuk. Anda juga dapat membuat pengguna tanpa kata sandi sebagai administrator.

  2. Pengguna yang Anda impor dengan file CSV dapat langsung masuk dengan faktor tanpa kata sandi. Mereka tidak diharuskan untuk menyetel kata sandi sebelum masuk.

  3. Pengguna yang tidak memiliki kata sandi dapat mengirimkan permintaan ChangePasswordAPI tanpa PreviousPassword parameter.

Masuk otomatis dengan OTPs

Pengguna yang mendaftar dan mengonfirmasi akun pengguna mereka dengan email atau pesan SMS OTPs dapat secara otomatis masuk dengan faktor tanpa kata sandi yang cocok dengan pesan konfirmasi mereka. Di UI login terkelola, pengguna yang mengonfirmasi akun mereka dan memenuhi syarat untuk masuk OTP dengan metode pengiriman kode konfirmasi secara otomatis melanjutkan proses masuk pertama mereka setelah mereka memberikan kode konfirmasi. Dalam aplikasi yang dibuat khusus dengan AWS SDK, teruskan parameter berikut ke operasi atau InitiateAuth. AdminInitiateAuth

  • SessionParameter dari respons ConfirmSignUpAPI sebagai parameter Session permintaan.

  • Sebuah AuthFlowdariUSER_AUTH.

Anda dapat melewati PREFERRED_CHALLENGE dari EMAIL_OTP atauSMS_OTP, tetapi itu tidak diperlukan. SessionParameter memberikan bukti otentikasi dan Amazon Cognito mengabaikan saat Anda meneruskan AuthParameters kode sesi yang valid.

Operasi masuk mengembalikan respons yang menunjukkan otentikasi yang berhasil AuthenticationResult, tanpa tantangan tambahan jika kondisi berikut benar.

  • SessionKode ini valid dan tidak kedaluwarsa.

  • Pengguna memenuhi syarat untuk metode PREFERRED_CHALLENGE otentikasi yang diminta.

Activate passwordless sign-in
Konsol

Untuk mengaktifkan login tanpa kata sandi, konfigurasikan kumpulan pengguna Anda untuk mengizinkan login utama dengan satu atau beberapa jenis tanpa kata sandi, lalu konfigurasikan klien aplikasi Anda untuk mengizinkan alur. USER_AUTH Di konsol Amazon Cognito, navigasikan ke menu Masuk di bawah Autentikasi dalam konfigurasi kumpulan pengguna Anda. Edit Opsi untuk masuk berbasis pilihan dan pilih Kata sandi satu kali pesan email atau kata sandi satu kali pesan SMS. Anda dapat mengaktifkan kedua opsi. Simpan perubahan Anda.

Arahkan ke menu Klien aplikasidan pilih klien aplikasi atau buat yang baru. Pilih Edit dan pilih Pilih jenis otentikasi saat masuk: ALLOW_USER_AUTH.

API/SDK

Di API kumpulan pengguna, konfigurasikan SignInPolicy dengan opsi tanpa kata sandi yang sesuai dalam permintaan CreateUserPoolatau UpdateUserPool.

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

Konfigurasikan klien aplikasi Anda ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClientpermintaan CreateUserPoolClientatau permintaan.

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

Masuk tanpa kata sandi tidak memiliki AuthFlow yang dapat Anda tentukan dan. InitiateAuthAdminInitiateAuth Sebagai gantinya, Anda harus mendeklarasikan opsi AuthFlow dari USER_AUTH dan meminta masuk atau memilih opsi tanpa kata sandi dari respons dari kumpulan pengguna Anda. Untuk menandatangani pengguna ke aplikasi, konfigurasikan isi InitiateAuth atau AdminInitiateAuth permintaan Anda sebagai berikut. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

Dalam contoh ini, kita tidak tahu ke arah mana pengguna ingin masuk. Jika kami menambahkan PREFERRED_CHALLENGE parameter dan tantangan yang disukai tersedia untuk pengguna, Amazon Cognito merespons dengan tantangan itu.

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

Amazon Cognito merespons menyertakan parameter. AvailableChallenges

{
   "AvailableChallenges": [ 
      "EMAIL_OTP", 
      "SMS_OTP",
      "PASSWORD"
    ],
   "Session": "[Session ID from the previous response]"
}

Pengguna ini memenuhi syarat untuk login tanpa kata sandi dengan pesan email OTP, pesan SMS OTP, dan username-password. Aplikasi Anda dapat meminta pengguna untuk memilih mereka, atau membuat pilihan berdasarkan logika internal. Kemudian dilanjutkan dengan AdminRespondToAuthChallengepermintaan RespondToAuthChallengeatau yang memilih tantangan. Misalkan pengguna ingin menyelesaikan otentikasi tanpa kata sandi dengan OTP pesan email.

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

Amazon Cognito merespons dengan EMAIL_OTP tantangan dan mengirimkan kode ke alamat email terverifikasi pengguna Anda. Aplikasi Anda kemudian harus menanggapi lagi tantangan ini.

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

Masuk kunci sandi

Passkey aman dan memberlakukan tingkat upaya yang relatif rendah pada pengguna. Masuk kunci sandi menggunakan autentikator, perangkat eksternal yang dapat diautentikasi oleh pengguna. Kata sandi reguler mengekspos pengguna ke kerentanan seperti phishing, menebak kata sandi, dan pencurian kredenal. Dengan kunci sandi, aplikasi Anda dapat memperoleh manfaat dari langkah-langkah keamanan lanjutan pada ponsel dan perangkat lain yang terpasang atau dibangun ke sistem informasi. Alur kerja masuk kunci sandi umum dimulai dengan panggilan ke perangkat Anda yang memanggil pengelola kata sandi atau kredensi Anda, misalnya gantungan kunci iOS atau pengelola kata sandi Google Chrome. Manajer kredensial di perangkat meminta mereka untuk memilih kunci sandi dan mengotorisasinya dengan mekanisme kredensi atau buka kunci perangkat yang ada. Ponsel modern memiliki pemindai wajah, pemindai sidik jari, pola buka kunci dan mekanisme lainnya, beberapa yang secara bersamaan memuaskan sesuatu yang Anda ketahui dan sesuatu yang Anda miliki prinsip otentikasi yang kuat. Dalam kasus otentikasi kunci sandi dengan biometrik, kunci sandi mewakili sesuatu yang Anda miliki.

Anda mungkin ingin mengganti kata sandi dengan sidik jari, wajah, atau autentikasi kunci keamanan. Ini adalah passkey atau WebAuthnotentikasi. Adalah umum bagi pengembang aplikasi untuk mengizinkan pengguna mendaftarkan perangkat biometrik setelah mereka pertama kali masuk dengan kata sandi. Dengan kumpulan pengguna Amazon Cognito, aplikasi Anda dapat mengonfigurasi opsi masuk ini untuk pengguna. Otentikasi kunci sandi tidak memenuhi syarat untuk otentikasi multi-faktor (MFA).

Apa itu passkey?

Passkey menyederhanakan pengalaman pengguna dengan menghilangkan kebutuhan untuk mengingat kata sandi yang rumit atau masuk. OTPs Passkey didasarkan pada WebAuthn dan CTAP2 standar yang dirancang oleh World Wide Web Consortium (W3C) dan FIDO (Fast Identity Online) Alliance. Browser dan platform menerapkan standar ini, menyediakan APIs aplikasi web atau seluler untuk memulai proses pendaftaran atau otentikasi kunci sandi, dan juga UI bagi pengguna untuk memilih dan berinteraksi dengan autentikator kunci sandi.

Saat pengguna mendaftarkan autentikator dengan situs web atau aplikasi, autentikator akan membuat key pair publik-pribadi. WebAuthn browser dan platform mengirimkan kunci publik ke bagian belakang aplikasi situs web atau aplikasi. Authenticator menyimpan kunci pribadi, kunci IDs, dan metadata tentang pengguna dan aplikasi. Ketika pengguna ingin mengautentikasi dalam aplikasi terdaftar dengan autentikator terdaftar mereka, aplikasi menghasilkan tantangan acak. Tanggapan terhadap tantangan ini adalah tanda tangan digital dari tantangan yang dihasilkan dengan kunci pribadi autentikator untuk aplikasi dan pengguna itu, dan metadata yang relevan. Browser atau platform aplikasi menerima tanda tangan digital dan meneruskannya ke bagian belakang aplikasi. Aplikasi kemudian memvalidasi tanda tangan dengan kunci publik yang disimpan.

catatan

Aplikasi Anda tidak menerima rahasia otentikasi apa pun yang diberikan pengguna kepada autentikator mereka, juga tidak menerima informasi tentang kunci pribadi.

Berikut ini adalah beberapa contoh dan kemampuan autentikator yang saat ini ada di pasaran. Authenticator mungkin memenuhi salah satu atau semua kategori ini.

  • Beberapa autentikator melakukan verifikasi pengguna dengan faktor-faktor seperti PIN, input biometrik dengan wajah atau sidik jari, atau kode sandi sebelum memberikan akses, memastikan bahwa hanya pengguna yang sah yang dapat mengotorisasi tindakan. Authenticator lain tidak memiliki kemampuan verifikasi pengguna, dan beberapa dapat melewati verifikasi pengguna ketika aplikasi tidak memerlukannya.

  • Beberapa otentikator, misalnya token YubiKey perangkat keras, bersifat portabel. Mereka berkomunikasi dengan perangkat melalui koneksi USB, Bluetooth atau NFC. Beberapa autentikator bersifat lokal dan terikat ke platform, misalnya Windows Hello di PC atau ID Wajah di iPhone. Authenticator yang terikat perangkat dapat dibawa oleh pengguna jika cukup kecil, seperti perangkat seluler. Terkadang pengguna dapat menghubungkan otentikator perangkat keras mereka dengan banyak platform berbeda dengan komunikasi nirkabel. Misalnya, pengguna di browser desktop dapat menggunakan ponsel pintar mereka sebagai autentikator kunci sandi ketika mereka memindai kode QR.

  • Beberapa passkey yang terikat platform disinkronkan ke cloud sehingga dapat digunakan dari beberapa lokasi. Misalnya, kunci sandi ID Wajah di iPhone menyinkronkan metadata kunci sandi dengan akun Apple pengguna di Rantai Kunci iCloud mereka. Kunci sandi ini memberikan otentikasi tanpa batas di seluruh perangkat Apple, alih-alih mengharuskan pengguna mendaftarkan setiap perangkat secara independen. Aplikasi autentikator berbasis perangkat lunak seperti 1Password, Dashlane, dan Bitwarden menyinkronkan kunci sandi di semua platform tempat pengguna menginstal aplikasi.

Dalam WebAuthn terminologi, situs web dan aplikasi mengandalkan pihak. Setiap kunci sandi dikaitkan dengan ID pihak yang bergantung tertentu, pengenal terpadu yang mewakili situs web atau aplikasi yang menerima otentikasi kunci sandi.. Pengembang harus hati-hati memilih ID pihak yang bergantung untuk memiliki cakupan otentikasi yang tepat. ID partai yang mengandalkan khas adalah nama domain root dari server web. Kunci sandi dengan spesifikasi ID pihak yang bergantung ini dapat mengautentikasi domain dan subdomain tersebut. Browser dan platform menolak otentikasi kunci sandi ketika URL situs web yang ingin diakses pengguna tidak cocok dengan ID pihak yang bergantung. Demikian pula, untuk aplikasi seluler, kunci sandi hanya dapat digunakan jika jalur aplikasi ada dalam file .well-known asosiasi yang disediakan aplikasi di jalur yang ditunjukkan oleh ID pihak yang bergantung.

Passkey dapat ditemukan. Mereka dapat secara otomatis dikenali dan digunakan oleh browser atau platform tanpa mengharuskan pengguna untuk memasukkan nama pengguna. Saat pengguna mengunjungi situs web atau aplikasi yang mendukung otentikasi kunci sandi, mereka dapat memilih dari daftar kunci sandi yang sudah diketahui browser atau platform, atau mereka dapat memindai kode QR.

Bagaimana Amazon Cognito menerapkan otentikasi kunci sandi?

Passkeys adalah fitur opt-in yang tersedia di semua paket fitur selain Lite. Ini hanya tersedia dalam alur otentikasi berbasis pilihan. Dengan login terkelola, Amazon Cognito menangani logika otentikasi kunci sandi. Anda juga dapat menggunakan API kumpulan pengguna Amazon Cognito AWS SDKs untuk melakukan otentikasi kunci sandi di bagian belakang aplikasi Anda.

Amazon Cognito mengenali kunci sandi yang dibuat menggunakan salah satu dari dua algoritma kriptografi asimetris, (-7) dan ES256 (-257). RS256 Sebagian besar autentikator mendukung kedua algoritma. Secara default, pengguna dapat mengatur semua jenis otentikator, misalnya token perangkat keras, ponsel pintar, dan aplikasi otentikator perangkat lunak. Amazon Cognito saat ini tidak mendukung penegakan pengesahan.

Di kumpulan pengguna, Anda dapat mengonfigurasi verifikasi pengguna agar lebih disukai atau diperlukan. Setelan ini secara default menjadi preferen dalam permintaan API yang tidak memberikan nilai, dan pilihan dipilih secara default di konsol Amazon Cognito. Saat Anda mengatur verifikasi pengguna ke pilihan, pengguna dapat menyiapkan autentikator yang tidak memiliki kemampuan verifikasi pengguna, dan operasi registrasi dan otentikasi dapat berhasil tanpa verifikasi pengguna. Untuk mengamanatkan verifikasi pengguna dalam pendaftaran dan otentikasi kunci sandi, ubah pengaturan ini menjadi wajib.

ID pihak yang mengandalkan (RP) yang Anda tetapkan dalam konfigurasi kunci sandi Anda adalah keputusan penting. Jika Anda tidak menentukan sebaliknya dan versi branding domain Anda adalah login terkelola, kumpulan pengguna Anda secara default mengharapkan nama domain kustom Anda sebagai ID RP. Jika Anda tidak memiliki domain kustom dan tidak menentukan sebaliknya, kumpulan pengguna Anda default ke ID RP domain awalan Anda. Anda juga dapat mengonfigurasi ID RP Anda menjadi nama domain apa pun yang tidak ada dalam daftar akhiran publik (PSL). Entri ID RP Anda berlaku untuk pendaftaran dan otentikasi kunci sandi di login terkelola dan dalam otentikasi SDK. Passkey hanya berfungsi dalam aplikasi seluler dengan Amazon Cognito dapat menemukan file asosiasi .well-known dengan ID RP Anda sebagai domain. Sebagai praktik terbaik, tentukan dan tetapkan nilai ID pihak yang mengandalkan Anda sebelum situs web atau aplikasi Anda tersedia untuk umum. Jika Anda mengubah ID RP Anda, pengguna Anda harus mendaftar kembali dengan ID RP yang baru.

Setiap pengguna dapat mendaftarkan hingga 20 kunci sandi. Mereka hanya dapat mendaftarkan kunci sandi setelah mereka masuk ke kumpulan pengguna Anda setidaknya sekali. Login terkelola menghapus upaya signifikan dari pendaftaran kunci sandi. Saat Anda mengaktifkan otentikasi kunci sandi untuk kumpulan pengguna dan klien aplikasi, kumpulan pengguna Anda dengan domain login terkelola mengingatkan pengguna akhir untuk mendaftarkan kunci sandi setelah mereka mendaftar ke akun pengguna baru. Anda juga dapat memanggil browser pengguna kapan saja untuk mengarahkan mereka ke halaman login terkelola untuk pendaftaran kunci sandi. Pengguna harus memberikan nama pengguna sebelum Amazon Cognito dapat memulai otentikasi kunci sandi. Login terkelola menangani ini secara otomatis. Halaman login meminta nama pengguna, memvalidasi bahwa pengguna memiliki setidaknya satu kunci sandi yang terdaftar, dan kemudian meminta masuk kunci sandi. Demikian pula, aplikasi berbasis SDK harus meminta nama pengguna dan menyediakannya dalam permintaan otentikasi.

Ketika Anda mengatur otentikasi kumpulan pengguna dengan kunci sandi dan Anda memiliki domain kustom dan domain awalan, ID RP default ke nama domain yang sepenuhnya memenuhi syarat (FQDN) dari domain kustom Anda. Untuk menetapkan domain awalan sebagai ID RP di konsol Amazon Cognito, hapus domain kustom Anda atau masukkan FQDN domain awalan sebagai domain Pihak Ketiga.

Activate passkey sign-in
Konsol

Untuk mengaktifkan login dengan kunci sandi, konfigurasikan kumpulan pengguna Anda untuk mengizinkan login utama dengan satu atau beberapa jenis tanpa kata sandi, lalu konfigurasikan klien aplikasi Anda untuk mengizinkan alur. USER_AUTH Di konsol Amazon Cognito, navigasikan ke menu Masuk di bawah Autentikasi dalam konfigurasi kumpulan pengguna Anda. Edit Opsi untuk masuk berbasis pilihan dan tambahkan Kunci Sandi ke daftar pilihan yang Tersedia.

Arahkan ke menu Metode otentikasi dan edit Kunci Sandi.

  • Verifikasi pengguna adalah pengaturan apakah kumpulan pengguna Anda memerlukan perangkat kunci sandi yang melakukan pemeriksaan tambahan bahwa pengguna saat ini diberi otorisasi untuk kunci sandi. Untuk mendorong pengguna mengonfigurasi perangkat dengan verifikasi pengguna, tetapi tidak memerlukannya, pilih Pilihan. Untuk hanya mendukung perangkat dengan verifikasi pengguna, pilih Diperlukan. Untuk informasi selengkapnya, lihat Verifikasi pengguna di w3.org.

  • Domain untuk ID pihak yang mengandalkan adalah pengenal bahwa aplikasi Anda akan meneruskan permintaan pendaftaran passkey pengguna. Ini menetapkan target hubungan kepercayaan dengan penerbit kunci sandi pengguna. ID pihak yang Anda andalkan dapat berupa: domain kumpulan pengguna Anda jika

    Domain Cognito

    Domain awalan Amazon Cognito dari kumpulan pengguna Anda.

    Domain kustom

    Domain kustom dari kumpulan pengguna Anda.

    Domain pihak ketiga

    Domain untuk aplikasi yang tidak menggunakan halaman login terkelola kumpulan pengguna. Pengaturan ini biasanya dikaitkan dengan kumpulan pengguna yang tidak memiliki domain dan melakukan autentikasi dengan AWS SDK dan API kumpulan pengguna di backend.

Arahkan ke menu Klien aplikasi dan pilih klien aplikasi atau buat yang baru. Pilih Edit dan di bawah Alur otentikasi, pilih Pilih jenis otentikasi saat masuk: ALLOW_USER_AUTH.

API/SDK

Di API kumpulan pengguna, konfigurasikan SignInPolicy dengan opsi kunci sandi yang sesuai dalam UpdateUserPoolpermintaan CreateUserPoolatau. WEB_AUTHNOpsi untuk otentikasi passkey harus disertai dengan setidaknya satu opsi lain. Pendaftaran kunci sandi memerlukan sesi otentikasi yang ada.

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

Konfigurasikan preferensi verifikasi pengguna dan ID RP Anda dalam WebAuthnConfiguration parameter permintaan. SetUserPoolMfaConfig Target hasil otentikasi passkey yang dituju, dapat berupa awalan kumpulan pengguna atau domain kustom Anda, atau domain pilihan Anda sendiri. RelyingPartyId

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

Konfigurasikan klien aplikasi Anda ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClientpermintaan CreateUserPoolClientatau permintaan.

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

Login terkelola menangani pendaftaran kunci sandi pengguna. Saat autentikasi kunci sandi aktif di kumpulan pengguna Anda, Amazon Cognito meminta pengguna untuk menyiapkan kunci sandi saat mendaftar untuk akun pengguna baru.

Amazon Cognito tidak meminta pengguna untuk menyiapkan kunci sandi ketika mereka telah mendaftar dan tidak menyiapkan kunci sandi, atau jika Anda membuat akun mereka sebagai administrator. Pengguna di negara bagian ini harus masuk dengan faktor lain seperti kata sandi atau OTP tanpa kata sandi sebelum mereka dapat mendaftarkan kunci sandi.

Untuk mendaftarkan kunci sandi

  1. Arahkan pengguna ke halaman login Anda.

    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. Memproses hasil otentikasi dari pengguna. Dalam contoh ini, Amazon Cognito mengalihkannya www.example.com dengan kode otorisasi yang ditukar aplikasi Anda dengan token.

  3. Arahkan pengguna ke halaman register-passkey Anda. Pengguna akan memiliki cookie browser yang mempertahankan sesi masuk mereka. URL passkey mengambil client_id dan redirect_uri parameter. Amazon Cognito hanya mengizinkan pengguna yang diautentikasi untuk mengakses halaman ini. Masuk ke pengguna Anda dengan kata sandi, OTP email, atau SMS OTP dan kemudian panggil URL yang cocok dengan pola berikut.

    Anda juga dapat menambahkan Otorisasi titik akhir parameter lain ke permintaan ini, seperti response_type danscope.

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

Anda mendaftarkan kredensi passkey dengan metadata dalam objek. PublicKeyCreationOptions Anda dapat membuat objek ini dengan kredensi pengguna yang masuk dan menyajikannya dalam permintaan API ke penerbit kunci sandi mereka. Penerbit akan mengembalikan objek RegistrationResponseJSON yang mengonfirmasi pendaftaran kunci sandi.

Untuk memulai proses pendaftaran kunci sandi, masuk pengguna dengan opsi masuk yang ada. Otorisasi permintaan StartWebAuthnRegistrationAPI yang diotorisasi token dengan token akses pengguna saat ini. Berikut ini adalah isi dari GetWebAuthnRegistrationOptions permintaan contoh.

{
   "AccessToken": "eyJra456defEXAMPLE"
}

Respons dari kumpulan pengguna Anda berisi PublicKeyCreationOptions objek. Sajikan objek ini dalam permintaan API ke penerbit pengguna. Ini memberikan informasi seperti kunci publik dan ID pihak yang mengandalkan. Penerbit akan merespons dengan RegistrationResponseJSON objek.

Sajikan respons pendaftaran dalam permintaan CompleteWebAuthnRegistrationAPI, sekali lagi diotorisasi dengan token akses pengguna. Saat kumpulan pengguna Anda merespons dengan respons HTTP 200 dengan badan kosong, kunci sandi pengguna Anda terdaftar.

Sign in with a passkey

Masuk tanpa kata sandi tidak memiliki AuthFlow yang dapat Anda tentukan dan. InitiateAuthAdminInitiateAuth Sebagai gantinya, Anda harus mendeklarasikan opsi AuthFlow dari USER_AUTH dan meminta masuk atau memilih opsi tanpa kata sandi dari respons dari kumpulan pengguna Anda. Untuk menandatangani pengguna ke aplikasi, konfigurasikan isi InitiateAuth atau AdminInitiateAuth permintaan Anda sebagai berikut. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

Dalam contoh ini, kita tahu bahwa pengguna ingin masuk dengan passkey, dan kita menambahkan PREFERRED_CHALLENGE parameter.

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

Amazon Cognito merespons dengan sebuah tantangan. WEB_AUTHN Aplikasi Anda harus menanggapi tantangan ini. Memulai permintaan masuk dengan penyedia kunci sandi pengguna. Ini akan mengembalikan objek AuthenticationResponseJSON.

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

MFA setelah masuk

Anda dapat mengatur pengguna yang menyelesaikan proses masuk dengan alur nama pengguna kata sandi untuk diminta verifikasi tambahan dengan kata sandi satu kali dari pesan email, pesan SMS, atau aplikasi pembuat kode. MFA berbeda dari login tanpa kata sandi, faktor otentikasi pertama dengan kata sandi satu kali atau kunci sandi WebAuthn yang tidak menyertakan MFA. MFA di kumpulan pengguna adalah model tantangan-respons, di mana pengguna pertama kali menunjukkan bahwa mereka mengetahui kata sandi, kemudian mereka menunjukkan bahwa mereka memiliki akses ke perangkat faktor kedua terdaftar mereka.

Sumber daya implementasi

Segarkan token

Ketika Anda ingin mengizinkan pengguna untuk memilih kotak centang Remember me, refresh token adalah alat yang aplikasi Anda miliki untuk mempertahankan sesi pengguna. Aplikasi dapat menyajikan token penyegaran ke kumpulan pengguna Anda dan menukarnya dengan ID baru dan token akses. Dengan penyegaran token, Anda dapat memastikan bahwa pengguna yang masuk masih aktif, mendapatkan informasi atribut yang diperbarui, dan memperbarui hak kontrol akses tanpa campur tangan pengguna.

Sumber daya implementasi

Otentikasi kustom

Anda mungkin ingin mengonfigurasi metode otentikasi untuk pengguna Anda yang tidak tercantum di sini. Anda dapat melakukannya dengan otentikasi khusus dengan pemicu Lambda. Dalam urutan fungsi Lambda, Amazon Cognito mengeluarkan tantangan, mengajukan pertanyaan yang harus dijawab pengguna, memeriksa jawaban untuk akurasi, kemudian menentukan apakah tantangan lain harus dikeluarkan. Pertanyaan dan jawaban dapat mencakup pertanyaan keamanan, permintaan ke layanan CAPTCHA, permintaan ke API layanan MFA eksternal, atau semua ini secara berurutan.

Sumber daya implementasi

Alur otentikasi kustom

Kumpulan pengguna Amazon Cognito juga memungkinkan untuk menggunakan alur otentikasi khusus, yang dapat membantu Anda membuat model otentikasi berbasis tantangan/respons menggunakan pemicu. AWS Lambda

Alur otentikasi khusus memungkinkan siklus tantangan dan respons yang disesuaikan untuk memenuhi persyaratan yang berbeda. Alur dimulai dengan panggilan ke operasi InitiateAuth API yang menunjukkan jenis otentikasi yang akan digunakan dan menyediakan parameter otentikasi awal apa pun. Amazon Cognito menanggapi InitiateAuth panggilan dengan salah satu jenis informasi berikut:

  • Tantangan bagi pengguna, bersama dengan sesi dan parameter.

  • Kesalahan jika pengguna gagal untuk mengautentikasi.

  • ID, akses, dan refresh token jika parameter yang disediakan dalam InitiateAuth panggilan cukup untuk menandatangani pengguna. (Biasanya pengguna atau aplikasi harus terlebih dahulu menjawab tantangan, tetapi kode kustom Anda harus menentukan ini.)

Jika Amazon Cognito menanggapi InitiateAuth panggilan dengan tantangan, aplikasi mengumpulkan lebih banyak input dan memanggil operasi. RespondToAuthChallenge Panggilan ini memberikan tanggapan tantangan dan meneruskannya kembali sesi. Amazon Cognito menanggapi panggilan yang mirip dengan RespondToAuthChallenge panggilan tersebut. InitiateAuth Jika pengguna telah masuk, Amazon Cognito menyediakan token, atau jika pengguna tidak masuk, Amazon Cognito memberikan tantangan lain, atau kesalahan. Jika Amazon Cognito menampilkan tantangan lain, urutan akan berulang dan aplikasi akan memanggil RespondToAuthChallenge hingga pengguna berhasil masuk atau kesalahan dikembalikan. Untuk detail selengkapnya tentang operasi InitiateAuth dan RespondToAuthChallenge API, lihat dokumentasi API.

Alur otentikasi kustom dan tantangan

Aplikasi dapat memulai alur autentikasi kustom dengan memanggil InitiateAuth dengan CUSTOM_AUTH sebagai Authflow. Dengan alur otentikasi khusus, tiga Lambda memicu tantangan kontrol dan verifikasi tanggapan.

  • Pemicu DefineAuthChallenge Lambda menggunakan array sesi tantangan dan respons sebelumnya sebagai masukan. Kemudian menghasilkan nama tantangan berikutnya dan Booleans yang menunjukkan apakah pengguna diautentikasi dan dapat diberikan token. Pemicu Lambda ini adalah mesin status yang mengontrol jalur pengguna melalui tantangan.

  • Pemicu CreateAuthChallenge Lambda mengambil nama tantangan sebagai input dan menghasilkan tantangan dan parameter untuk mengevaluasi respons. Ketika DefineAuthChallenge kembali CUSTOM_CHALLENGE sebagai tantangan berikutnya, alur otentikasi memanggilCreateAuthChallenge. Pemicu CreateAuthChallenge Lambda melewati jenis tantangan berikutnya dalam parameter metadata tantangan.

  • Fungsi Lambda VerifyAuthChallengeResponse mengevaluasi respons dan mengembalikan Boolean untuk menunjukkan apakah respons itu valid.

Alur otentikasi khusus juga dapat menggunakan kombinasi tantangan bawaan, seperti verifikasi kata sandi SRP dan MFA melalui SMS. Hal ini dapat menggunakan tantangan kustom seperti CAPTCHA atau pertanyaan rahasia.

Gunakan verifikasi kata sandi SRP dalam alur otentikasi khusus

Jika Anda ingin menyertakan SRP dalam alur otentikasi khusus, Anda harus mulai dengan SRP.

  • Untuk memulai verifikasi kata sandi SRP dalam aliran kustom, aplikasi akan memanggil InitiateAuth dengan CUSTOM_AUTH sebagai Authflow. Di AuthParameters peta, permintaan dari aplikasi Anda menyertakan SRP_A: (nilai SRP A) danCHALLENGE_NAME: SRP_A.

  • CUSTOM_AUTHAliran memanggil pemicu DefineAuthChallenge Lambda dengan sesi challengeName: SRP_A awal dan. challengeResult: true Fungsi Lambda Anda merespons denganchallengeName: PASSWORD_VERIFIER,, issueTokens: false dan. failAuthentication: false

  • Aplikasi selanjutnya harus memanggil RespondToAuthChallenge dengan challengeName: PASSWORD_VERIFIER dan parameter lain yang diperlukan untuk SRP di challengeResponses peta.

  • Jika Amazon Cognito memverifikasi kata sandi, RespondToAuthChallenge panggil pemicu DefineAuthChallenge Lambda dengan sesi kedua dan. challengeName: PASSWORD_VERIFIER challengeResult: true Pada saat itu, pemicu DefineAuthChallenge Lambda merespons dengan challengeName: CUSTOM_CHALLENGE untuk memulai tantangan khusus.

  • Jika MFA diaktifkan untuk pengguna, setelah Amazon Cognito memverifikasi kata sandi, pengguna Anda kemudian ditantang untuk mengatur atau masuk dengan MFA.

catatan

Halaman web masuk yang dihosting Amazon Cognito tidak dapat diaktifkan. Tantangan otentikasi kustom pemicu Lambda

Untuk informasi lebih lanjut tentang pemicu Lambda, termasuk kode sampel, lihat Menyesuaikan alur kerja kumpulan pengguna dengan pemicu Lambda.

Alur autentikasi migrasi pengguna

Pemicu Lambda migrasi pengguna membantu memigrasikan pengguna dari sistem manajemen pengguna lama ke kumpulan pengguna Anda. Jika Anda memilih alur USER_PASSWORD_AUTH otentikasi, pengguna tidak perlu mengatur ulang kata sandi mereka selama migrasi pengguna. Alur ini mengirimkan kata sandi pengguna Anda ke layanan melalui koneksi SSL terenkripsi selama autentikasi.

Jika Anda telah memigrasikan semua pengguna, alihkan aliran ke aliran SRP yang lebih aman. Aliran SRP tidak mengirim kata sandi apa pun melalui jaringan.

Untuk mempelajari lebih lanjut tentang pemicu Lambda, lihat. Menyesuaikan alur kerja kumpulan pengguna dengan pemicu Lambda

Untuk informasi selengkapnya tentang memigrasi pengguna dengan pemicu Lambda, lihat. Mengimpor pengguna dengan pemicu Lambda migrasi pengguna