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

Aliran otentikasi

Proses otentikasi dengan kumpulan pengguna Amazon Cognito paling baik digambarkan sebagai aliran di mana pengguna membuat pilihan awal, mengirimkan kredenSIAL, dan menanggapi tantangan tambahan. Saat Anda menerapkan otentikasi login terkelola di aplikasi Anda, Amazon Cognito mengelola alur petunjuk dan tantangan ini. Saat Anda mengimplementasikan alur dengan AWS SDK di back-end aplikasi Anda, Anda harus membangun 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 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 mengatur alur masuk untuk pengguna, Anda dapat memeriksa status pengguna saat ini untuk MFA dan faktor otentikasi 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.

Sign-in dengan pihak ketiga IdPs

Kumpulan pengguna Amazon Cognito berfungsi sebagai broker perantara sesi otentikasi antara IdPs layanan seperti Masuk dengan Apple, Login dengan Amazon, dan OpenID Connect (OIDC). Proses ini juga disebut login federasi atau otentikasi federasi. Otentikasi federasi tidak menggunakan alur otentikasi 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 otentikasi utama dan MFA ke IdP pengguna. Amazon Cognito tidak menambahkan alur lanjutan lainnya di bagian ini ke pengguna federasi kecuali Anda men autkannya ke pengguna lokal. Pengguna federasi yang tidak tertaut memiliki nama pengguna, tetapi mereka adalah penyimpanan data atribut yang dipetakan yang biasanya tidak digunakan untuk masuk secara independen dari alur berbasis browser.

Sign-in 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 dan kata sandi dengan operasi publik atau IAM-authorized API 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 (JWT) yang merupakan hasil dari otentikasi yang berhasil.

Activate password sign-in

Untuk mengaktifkan otentikasi berbasis klien dengan nama pengguna dan kata sandi, konfigurasikan klien aplikasi Anda untuk mengizinkannya. Di konsol Amazon Cognito, navigasikan ke menu Kli en aplikasi di bawah Aplikasi dalam konfigurasi kumpulan pengguna Anda. Untuk mengizinkan login dengan kata sandi biasa untuk aplikasi seluler atau asli sisi klien, edit klien aplikasi dan pilih Masuk dengan nama pengguna dan kata sandi: ALLOW_USER_PASSW ORD_AUTH di bawah Alur otentikasi. Untuk mengizinkan login dengan kata sandi biasa untuk aplikasi sisi server, edit klien aplikasi dan pilih Masuk dengan kredenSIAL administratif sisi server: ALLOW_ADMIN_USER_PAS SWORD_AUTH.

Untuk mengaktifkan otentikasi berbasis pilihan dengan nama pengguna dan kata sandi, konfigurasikan klien aplikasi Anda untuk mengizinkannya. Edit klien aplikasi Anda dan pilih Choice-based masuk: ALLOW_USER_AUTH.

Untuk memverifikasi bahwa otentikasi kata sandi tersedia dalam alur otentikasi berbasis pilihan, navigasikan ke Sign-in menu dan tinjau bagian di bawah Opsi untuk masuk berbasis pilihan. Anda dapat masuk dengan otentikasi kata sandi biasa jika Kata Sandi terlihat di bawah Pilihan yang tersedia. Opsi Kata Sandi menyertakan varian otentikasi nama pengguna-kata sandi biasa dan SRP.

Konfigurasikan ExplicitAuthFlows dengan opsi otentikasi nama pengguna dan kata sandi pilihan Anda dalam permintaan atau. CreateUserPoolClient UpdateUserPoolClient

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

Dalam UpdateUserPool permintaan CreateUserPool atau, konfigurasikan Policies dengan alur otentikasi berbasis pilihan yang ingin Anda dukung. PASSWORDNilai dalam AllowedFirstAuthFactors mencakup opsi aliran otentikasi kata sandi biasa dan SRP.

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

Choice-based sign-in with a password

Untuk menandatangani pengguna ke aplikasi dengan otentikasi nama pengguna-kata sandi, konfigurasikan isi AdminInitiateAuth atau InitiateAuth permintaan Anda sebagai berikut. Permintaan masuk ini berhasil atau berlanjut ke tantangan berikutnya jika pengguna saat ini memenuhi syarat untuk otentikasi nama pengguna dan kata sandi. Jika tidak, ia merespons dengan daftar tantangan otentikasi faktor primer yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Anda juga dapat menghilangkan PREFERRED_CHALLENGE nilai dan menerima respons yang berisi daftar faktor masuk yang memenuhi syarat untuk pengguna.

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

Jika Anda tidak mengirimkan tantangan pilihan atau pengguna yang dikirimkan tidak memenuhi syarat untuk tantangan pilihan mereka, Amazon Cognito mengembalikan daftar opsi diAvailableChallenges. Bila AvailableChallenges menyertakan ChallengeName a ofPASSWORD, Anda dapat melanjutkan otentikasi dengan respon RespondToAuthChallenge atau AdminRespondToAuthChallenge tantangan dalam format berikut. Anda harus meneruskan Session parameter yang mengaitkan respons tantangan dengan respons API untuk permintaan masuk awal Anda. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Amazon Cognito menanggapi permintaan tantangan pilihan yang memenuhi syarat dan berhasil serta tanggapan PASSWORD tantangan dengan token atau tantangan tambahan yang diperlukan seperti otentikasi multi-faktor (MFA).

Client-based sign-in with a password

Untuk menandatangani pengguna ke aplikasi sisi klien dengan otentikasi 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" : "[User's password]"
   },
   "ClientId": "1example23456789"
}

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

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

Amazon Cognito menanggapi permintaan yang berhasil dengan token atau tantangan tambahan yang diperlukan seperti otentikasi multi-faktor (MFA).

Sign-in dengan kata sandi yang persisten dan payload aman

Bentuk lain dari metode login 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. Otentikasi 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 The Stanford SRP Homepage. Wikipedia juga memiliki sumber dan contoh. Berbagai perpustakaan umum tersedia untuk melakukan perhitungan SRP untuk alur otentikasi Anda.

Urutan inisiasi-tantangan-respon dari otentikasi Amazon Cognito memvalidasi pengguna dan kata sandi mereka dengan SRP. Anda harus mengonfigurasi kumpulan pengguna dan klien aplikasi untuk mendukung otentikasi SRP, lalu menerapkan logika permintaan masuk dan tanggapan tantangan di aplikasi Anda. Pustaka SRP Anda dapat menghasilkan angka acak dan nilai terhitung yang menunjukkan kepada kumpulan pengguna Anda bahwa Anda memiliki kata sandi pengguna. Aplikasi Anda mengisi nilai yang dihitung ini ke ChallengeParameters bidang JSON-formatted AuthParameters dan di operasi API kumpulan pengguna Amazon Cognito dan metode SDK untuk otentikasi.

Activate SRP sign-in

Untuk mengaktifkan otentikasi berbasis klien dengan nama pengguna dan SRP, konfigurasikan klien aplikasi Anda untuk mengizinkannya. Di konsol Amazon Cognito, navigasikan ke menu Kli en aplikasi di bawah Aplikasi dalam konfigurasi kumpulan pengguna Anda. Untuk mengizinkan masuk SRP untuk aplikasi seluler atau asli sisi klien, edit klien aplikasi dan pilih Masuk dengan kata sandi jarak jauh aman (SRP): ALLOW _USER_SRP_AUTH di bawah Alur otentikasi.

Untuk mengaktifkan otentikasi berbasis pilihan dengan nama pengguna dan SRP, edit klien aplikasi Anda dan pilih masuk: ALLOW_USER_AUTH Choice-based .

Untuk memverifikasi bahwa otentikasi SRP tersedia dalam alur otentikasi berbasis pilihan Anda, navigasikan ke Sign-in menu dan tinjau bagian di bawah Opsi untuk masuk berbasis pilihan. Anda dapat masuk dengan otentikasi SRP jika Kata Sandi terlihat di bawah Pilihan yang tersedia. Opsi Kata Sandi menyertakan varian otentikasi plaintext dan nama pengguna SRP.

Konfigurasikan ExplicitAuthFlows dengan opsi otentikasi nama pengguna dan kata sandi pilihan Anda dalam permintaan atau. CreateUserPoolClient UpdateUserPoolClient

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

Dalam UpdateUserPool permintaan CreateUserPool atau, konfigurasikan Policies dengan alur otentikasi berbasis pilihan yang ingin Anda dukung. PASSWORDNilai di AllowedFirstAuthFactors mencakup opsi aliran otentikasi plaintext-password dan SRP.

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

Choice-based sign-in with SRP

Untuk menandatangani pengguna ke aplikasi dengan otentikasi nama pengguna-kata sandi dengan SRP, konfigurasikan isi AdminInitiateAuth atau InitiateAuth permintaan Anda sebagai berikut. Permintaan masuk ini berhasil atau berlanjut ke tantangan berikutnya jika pengguna saat ini memenuhi syarat untuk otentikasi nama pengguna dan kata sandi. Jika tidak, ia merespons dengan daftar tantangan otentikasi faktor primer yang tersedia. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Anda juga dapat menghilangkan PREFERRED_CHALLENGE nilai dan menerima respons yang berisi daftar faktor masuk yang memenuhi syarat untuk pengguna.

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

Jika Anda tidak mengirimkan tantangan pilihan atau pengguna yang dikirimkan tidak memenuhi syarat untuk tantangan pilihan mereka, Amazon Cognito mengembalikan daftar opsi diAvailableChallenges. Bila AvailableChallenges menyertakan ChallengeName a ofPASSWORD_SRP, Anda dapat melanjutkan otentikasi dengan respon RespondToAuthChallenge atau AdminRespondToAuthChallenge tantangan dalam format berikut. Anda harus meneruskan Session parameter yang mengaitkan respons tantangan dengan respons API untuk permintaan masuk awal Anda. Kumpulan parameter ini adalah minimum yang diperlukan untuk masuk. Parameter tambahan tersedia.

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

Amazon Cognito menanggapi permintaan tantangan pilihan yang memenuhi syarat dan tanggapan PASSWORD_SRP tantangan dengan tantangan. PASSWORD_VERIFIER Klien Anda harus menyelesaikan perhitungan SRP dan menanggapi tantangan dalam AdminRespondToAuthChallenge permintaan RespondToAuthChallenge atau.

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

Pada respons PASSWORD_VERIFIER tantangan yang berhasil, Amazon Cognito mengeluarkan token atau tantangan lain yang diperlukan seperti otentikasi multi-faktor (MFA).

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 InitiateAuth dan 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 generator modulo N g din aikkan ke kekuatan bilangan bulat acak rahasia a.

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

Amazon Cognito merespons dengan PASSWORD_VERIFIER tantangan. Klien Anda harus menyelesaikan perhitungan SRP dan menanggapi tantangan dalam AdminRespondToAuthChallenge permintaan RespondToAuthChallenge atau.

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

Pada respons PASSWORD_VERIFIER tantangan yang berhasil, Amazon Cognito mengeluarkan token atau tantangan lain yang diperlukan seperti otentikasi multi-faktor (MFA).

Masuk tanpa kata sandi dengan kata sandi sekali pakai

Kata sandi bisa hilang atau dicuri. Anda mungkin ingin memverifikasi hanya bahwa pengguna Anda memiliki akses ke alamat email, nomor telepon, atau aplikasi otentikator yang diverifikasi. 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.

One-time Alur otentikasi kata sandi (OTP) tidak kompatibel dengan otentikasi multi-faktor (MFA) yang diperlukan di kumpulan pengguna Anda. Otentikasi kunci sandi dengan verifikasi pengguna dapat memenuhi persyaratan MFA saat Anda menyetel. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION Jika MFA bersifat opsional di kumpulan pengguna Anda, pengguna yang telah mengaktifkan MFA tidak dapat masuk dengan faktor pertama OTP. Pengguna yang tidak memiliki preferensi MFA di kumpulan MFA-optional pengguna dapat masuk dengan faktor tanpa kata sandi. Untuk informasi selengkapnya, lihat Hal yang perlu diketahui tentang kumpulan pengguna MFA.

Ketika pengguna memasukkan kode yang mereka terima dengan benar dalam SMS atau pesan email sebagai bagian dari otentikasi tanpa kata sandi, selain mengotentikasi pengguna, kumpulan pengguna Anda menandai alamat email atau atribut nomor telepon pengguna yang belum diverifikasi sebagai terverifikasi. Status pengguna juga berubah dari UNCONFIRMED menjadiCONFIRMED, 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 otentikasi tanpa kata sandi di kumpulan pengguna, ini mengubah cara kerja beberapa alur pengguna.

Masuk otomatis dengan OTP

Pengguna yang mendaftar dan mengonfirmasi akun pengguna mereka dengan OTP email atau SMS 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 ke login pertama mereka setelah mereka memberikan kode konfirmasi. Dalam aplikasi yang dibuat khusus dengan AWS SDK, berikan parameter berikut ke AdminInitiateAuth operasi InitiateAuth atau.

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

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

Activate passwordless sign-in

Konsol

Untuk mengaktifkan login tanpa kata sandi, konfigurasikan kumpulan pengguna Anda untuk mengizinkan masuk utama dengan satu atau beberapa jenis tanpa kata sandi, lalu konfigurasikan klien aplikasi Anda untuk mengizinkan alur tersebut. USER_AUTH Di konsol Amazon Cognito, navigasikan ke Sign-in menu di bawah Oten tikasi 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 aplikasi dan 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 CreateUserPool atau UpdateUserPool.

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

Konfigurasikan klien aplikasi Anda ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClient permintaan CreateUserPoolClient atau.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]

Sign in with passwordless

Masuk tanpa kata sandi tidak memiliki berbasis klien yang dapat Anda tent AuthFlow ukan di dan. InitiateAuth AdminInitiateAuth Otentikasi OTP hanya tersedia di berbasis pilihanUSER_AUTH, di mana Anda dapat meminta opsi masuk yang disukai atau memilih opsi tanpa kata sandi AuthFlow dari pengguna. AvailableChallenges 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"
}

Sebagai gantinya, Anda dapat menambahkan "PREFERRED_CHALLENGE": "EMAIL_OTP" atau "PREFERRED_CHALLENGE": "SMS_OTP" ke AuthParameters dalam contoh ini. Jika pengguna memenuhi syarat untuk metode pilihan itu, kumpulan pengguna Anda segera mengirimkan kode ke alamat email atau nomor telepon pengguna dan mengembalikan "ChallengeName": "EMAIL_OTP" atau"ChallengeName": "SMS_OTP".

Jika Anda tidak menentukan tantangan yang disukai, Amazon Cognito merespons dengan AvailableChallenges parameter.

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

Pengguna ini memenuhi syarat untuk masuk tanpa kata sandi dengan pesan email OTP, pesan SMS OTP, dan nama pengguna kata sandi. Aplikasi Anda dapat meminta pengguna untuk pemilihan mereka, atau membuat pilihan berdasarkan logika internal. Kemudian dilanjutkan dengan AdminRespondToAuthChallenge permintaan RespondToAuthChallenge atau 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.

Ini juga akan menjadi tanggapan tantangan berikutnya jika Anda meminta EMAIL_OTP sebagaiPREFERRED_CHALLENGE.

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

Masuk tanpa kata sandi dengan kunci sandi WebAuthn

Kunci sandi aman dan memaksakan tingkat upaya yang relatif rendah pada pengguna. Masuk dengan kunci sandi menggunakan otentik ator, perangkat eksternal yang dapat diautentikasi pengguna. Kata sandi biasa mengekspos pengguna pada kerentanan seperti phishing, menebak kata sandi, dan pencurian kredensia. Dengan kunci sandi, aplikasi Anda dapat memperoleh manfaat dari langkah-langkah keamanan lanjutan pada ponsel dan perangkat lain yang terpasang atau bawaan ke sistem informasi. Alur kerja masuk kunci sandi umum dimulai dengan panggilan ke perangkat Anda yang memanggil pengelola kata sandi atau kredenSIAL Anda, misalnya gant ungan kunci iOS atau pengelola kata sandi Google Chrome. Manajer kredenSIAL pada perangkat meminta mereka untuk memilih kunci sandi dan mengizinkannya dengan mekanisme kredenSIAL atau membuka kunci perangkat yang ada. Ponsel modern memiliki pemindai wajah, pemindai sidik jari, pola buka kunci dan mekanisme lainnya, beberapa yang secara bersamaan memenuhi 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 otentikasi kunci keamanan. Ini adalah kunci sandi atau WebAuthn otentikasi. Adalah umum bagi pengembang aplikasi untuk mengizinkan pengguna untuk 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 dapat memenuhi persyaratan otentikasi multi-faktor (MFA) ketika kumpulan pengguna Anda telah disetel ke. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION Dalam konfigurasi ini, otentikasi kunci sandi dengan verifikasi pengguna dihitung sebagai otentikasi multi-faktor.

One-time Alur otentikasi kata sandi (OTP) tidak kompatibel dengan otentikasi multi-faktor (MFA) yang diperlukan di kumpulan pengguna Anda. Otentikasi kunci sandi dengan verifikasi pengguna dapat memenuhi persyaratan MFA saat Anda menyetel. FactorConfiguration MULTI_FACTOR_WITH_USER_VERIFICATION Jika MFA bersifat opsional di kumpulan pengguna Anda, pengguna yang telah mengaktifkan MFA tidak dapat masuk dengan faktor pertama OTP. Pengguna yang tidak memiliki preferensi MFA di kumpulan MFA-optional pengguna dapat masuk dengan faktor tanpa kata sandi. Untuk informasi selengkapnya, lihat Hal yang perlu diketahui tentang kumpulan pengguna MFA.

Apa itu kunci sandi?

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

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

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

Dalam WebAuthn terminologi, situs web dan aplikasi adalah pihak yang bergantung. Setiap kunci sandi dikaitkan dengan ID pihak yang bergantung tertentu, pengidentifikasi terpadu yang mewakili situs web atau aplikasi yang menerima otentikasi kunci sandi.. Pengembang harus hati-hati memilih ID pihak yang mengandalkan mereka untuk memiliki cakupan otentikasi yang tepat. ID pihak reliying yang khas adalah nama domain root dari server web. Kunci sandi dengan spesifikasi ID pihak yang bergantung ini dapat mengotentikasi untuk 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 mengandalkan. Demikian pula, untuk aplikasi seluler, kunci sandi hanya dapat digunakan jika jalur aplikasi ada di file asosi .well-known asi yang disediakan aplikasi di jalur yang ditunjukkan oleh ID pihak yang mengandalkan.

Kunci sandi dapat ditemukan. Mereka dapat secara otomatis dikenali dan digunakan oleh browser atau platform tanpa mengharuskan pengguna untuk memasukkan nama pengguna. Ketika 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?

Kunci sandi adalah fitur opt-in yang tersedia di semua paket Paket fitur kumpulan pengguna fitur kecuali untuk Lite. Ini hanya tersedia dalam aliran otentik asi berbasis pilihan. Dengan login terkelola, Amazon Cognito menangani logika otentikasi kunci sandi. Anda juga dapat menggunakan API kumpulan pengguna Amazon Cognito di AWS SDK 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, ES256 (-7) dan RS256 (-257). Sebagian besar autentikator mendukung kedua algoritma tersebut. 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 peng esahan.

Di kumpulan pengguna, Anda dapat mengonfigurasi verifikasi pengguna agar lebih disukai atau diperlukan. Setelan ini secara default menjadi lebih disukai dalam permintaan API yang tidak memberikan nilai, dan preferensi dipilih secara default di konsol Amazon Cognito. Bila Anda menyetel verifikasi pengguna ke preferensi, pengguna dapat mengatur otentikator yang tidak memiliki kemampuan verifikasi pengguna, dan operasi pendaftaran dan otentikasi dapat berhasil tanpa verifikasi pengguna. Untuk mengamanatkan verifikasi pengguna dalam pendaftaran kunci sandi dan otentikasi, ubah setelan ini menjadi wajib.

ID pihak yang bergantung (RP) yang Anda tetapkan dalam konfigurasi kunci sandi adalah keputusan penting. Jika Anda tidak menentukan sebaliknya dan versi merek domain Anda adalah login terkelola, kumpulan pengguna Anda secara default mengharapkan nama domain kustom Anda sebagai ID RP. Jika Anda tidak memiliki domain khusus dan tidak menentukan sebaliknya, kumpulan pengguna Anda secara default akan menjadi ID RP dari domain Menggunakan domain awalan Amazon Cognito untuk login terkelola awalan Anda. Anda juga dapat mengonfigurasi ID RP Anda menjadi nama domain apa pun yang tidak ada dalam daftar akhiran publik (PSL). Entri RP ID Anda berlaku untuk pendaftaran kunci sandi dan otentikasi dalam login terkelola dan dalam otentikasi SDK. Passkey hanya berfungsi di aplikasi seluler dengan Amazon Cognito dapat menemukan file asosi .well-known asi 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 lagi dengan ID RP 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 menghilangkan upaya signifikan dari pendaftaran kunci sandi. Saat Anda mengaktifkan otentikasi kunci sandi untuk kumpulan pengguna dan klien aplikasi, kumpulan pengguna dengan domain login terkelola mengingatkan pengguna akhir untuk mendaftarkan kunci sandi setelah mereka mendaftar untuk 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 masuk meminta nama pengguna, memvalidasi bahwa pengguna memiliki setidaknya satu kunci sandi terdaftar, dan kemudian meminta masuk dengan kunci sandi. Demikian pula, SDK-based aplikasi harus meminta nama pengguna dan menyediakannya dalam permintaan otentikasi.

Saat Anda mengatur otentikasi kumpulan pengguna dengan kunci sandi dan Anda memiliki domain khusus dan domain awalan, RP ID default adalah nama domain yang memenuhi syarat penuh (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. Third-party

Activate passkey sign-in

Konsol

Untuk mengaktifkan login dengan kunci sandi, konfigurasikan kumpulan pengguna Anda untuk mengizinkan masuk utama dengan satu atau beberapa jenis tanpa kata sandi, lalu konfigurasikan klien aplikasi Anda untuk mengizinkan alur tersebut. USER_AUTH Di konsol Amazon Cognito, navigasikan ke Sign-in menu di bawah Oten tikasi 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 diotorisasi untuk kunci sandi. Untuk mendorong pengguna mengonfigurasi perangkat dengan verifikasi pengguna, tetapi tidak mengharuskannya, pilih Preferred. Untuk hanya mendukung perangkat dengan verifikasi pengguna, pilih Waj ib. Untuk informasi selengkapnya, lihat Veri fikasi pengguna di w3.org.

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

  Domain Cognito

  Domain awalan Amazon Cognito dari kumpulan pengguna Anda.

  Domain kustom

  Domain kustom kumpulan pengguna Anda.

  Third-party domain

  Domain untuk aplikasi yang tidak menggunakan halaman login yang dikelola kumpulan pengguna. Pengaturan ini biasanya dikaitkan dengan kumpulan pengguna yang tidak memiliki domain dan melakukan otentikasi 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, konfigur SignInPolicy asikan dengan opsi kunci sandi yang sesuai dalam permintaan CreateUserPool atau UpdateUserPool. WEB_AUTHNOpsi untuk otentikasi kunci sandi 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 SetUserPoolMfaConfig permintaan. Target hasil otentikasi kunci sandi yang dimaksudkan dapat berupa awalan kumpulan pengguna atau domain khusus, atau domain pilihan Anda sendiri. RelyingPartyId

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

Konfigurasikan klien aplikasi Anda ExplicitAuthFlows dengan opsi yang diperlukan dalam UpdateUserPoolClient permintaan CreateUserPoolClient atau.

"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]

Register a passkey (managed login)

Login yang dikelola 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 belum menyiapkan kunci sandi, atau jika Anda membuat akun mereka sebagai administrator. Pengguna dalam status 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 Titik akhir pengalihan dan otorisasi masuk 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 mengalihkan mereka www.example.com dengan kode otorisasi yang ditukar aplikasi Anda dengan token.

3. Arahkan pengguna ke halaman registr-passkey Anda. Pengguna akan memiliki cookie browser yang mempertahankan sesi login mereka. URL kunci sandi mengambil client_id dan redirect_uri parameter. Amazon Cognito hanya mengizinkan pengguna yang diautentikasi untuk mengakses halaman ini. Masuk pengguna Anda dengan kata sandi, email OTP, 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 kredentif kunci sandi dengan metadata dalam objek. PublicKeyCreationOptions Anda dapat membuat objek ini dengan kredenSIAL pengguna yang masuk dan menyajikannya dalam permintaan API kepada penerbit kunci sandi mereka. Penerbit akan mengembalikan objek RegistrationResponse JSON yang mengonfirmasi pendaftaran kunci sandi.

Untuk memulai proses pendaftaran kunci sandi, masuk pengguna dengan opsi masuk yang ada. Otorisasi permintaan StartWebAuthnRegistration API otorisasi 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. Menyajikan 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.

Menampilkan respons pendaftaran dalam permintaan CompleteWebAuthnRegistration API, sekali lagi diotorisasi dengan token akses pengguna. Ketika kumpulan pengguna Anda merespons dengan respons HTTP 200 dengan isi kosong, kunci sandi pengguna Anda terdaftar.

Sign in with a passkey

Masuk tanpa kata sandi tidak memiliki tanda AuthFlow yang dapat Anda tentukan di dan. InitiateAuth AdminInitiateAuth Sebagai gantinya, Anda harus mendeklarasikan opsi AuthFlow of USER_AUTH dan meminta opsi 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 kunci sandi, dan kita menambahkan parameter. PREFERRED_CHALLENGE

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

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

{
   "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 dengan kata sandi satu kali. Namun, kunci sandi dengan verifikasi pengguna dapat memenuhi persyaratan MFA sebagai faktor pertama saat Anda mengonfigurasi FactorConfiguration seperti MULTI_FACTOR_WITH_USER_VERIFICATION di kumpulan pengguna Anda. WebAuthnConfiguration Kunci sandi tidak dapat digunakan sebagai faktor kedua untuk masuk kata sandi. Untuk alur berbasis kata sandi, MFA di kumpulan pengguna adalah model tanggapan tantangan di mana pengguna pertama kali menunjukkan bahwa mereka mengetahui kata sandi, kemudian menunjukkan bahwa mereka memiliki akses ke perangkat faktor kedua yang terdaftar.

Segarkan token

Bila Anda ingin agar pengguna tetap masuk tanpa memasukkan kembali kredensialnya, token penyegaran adalah alat yang dimiliki aplikasi Anda 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.

Autentikasi 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.

Alur otentikasi kustom

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

Alur otentikasi khusus memungkinkan tantangan dan siklus 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. Amazon Cognito menanggapi InitiateAuth panggilan dengan salah satu jenis informasi berikut:

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 merespons RespondToAuthChallenge panggilan serupa dengan InitiateAuth panggilan. Jika pengguna telah masuk, Amazon Cognito menyediakan token, atau jika pengguna tidak masuk, Amazon Cognito memberikan tantangan lain, atau kesalahan. Jika Amazon Cognito mengembalikan tantangan lain, urutan akan berulang dan aplikasi memanggil RespondToAuthChallenge sampai pengguna berhasil masuk atau kesalahan dikembalikan. Untuk detail selengkapnya tentang operasi InitiateAuth dan RespondToAuthChallenge API, lihat dokumentasi API.

Alur dan tantangan otentikasi khusus

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

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 kustom, Anda harus mulai dengan SRP.

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 memigrasi 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.

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

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

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