Cara kerja otentikasi dengan kumpulan pengguna Amazon Cognito dan kumpulan identitas - Amazon Cognito

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

Cara kerja otentikasi dengan kumpulan pengguna Amazon Cognito dan kumpulan identitas

Saat pelanggan Anda masuk ke kumpulan pengguna Amazon Cognito, aplikasi Anda menerima token web JSON (JWT).

Saat pelanggan Anda masuk ke kumpulan identitas, baik dengan token kumpulan pengguna atau penyedia lain, aplikasi Anda menerima AWS kredensi sementara.

Dengan login kumpulan pengguna, Anda dapat menerapkan autentikasi dan otorisasi sepenuhnya dengan SDK. AWS Jika Anda tidak ingin membangun komponen antarmuka pengguna (UI) Anda sendiri, Anda dapat memanggil UI web bawaan (UI yang dihosting) atau halaman masuk untuk penyedia identitas pihak ketiga (iDP) Anda.

Topik ini adalah ikhtisar dari beberapa cara aplikasi Anda dapat berinteraksi dengan Amazon Cognito untuk mengautentikasi dengan token ID, mengotorisasi dengan token akses, dan mengakses Layanan AWS dengan kredenal kumpulan identitas.

Autentikasi dan otorisasi API kumpulan pengguna dengan SDK AWS

AWS telah mengembangkan komponen untuk kumpulan pengguna Amazon Cognito, atau penyedia identitas Amazon Cognito, dalam berbagai kerangka kerja pengembang. Metode yang dibangun ke dalam SDK ini memanggil API kumpulan pengguna Amazon Cognito. Namespace API pool pengguna yang sama memiliki operasi untuk konfigurasi kumpulan pengguna dan untuk otentikasi pengguna. Untuk ikhtisar yang lebih menyeluruh, lihatMenggunakan API kumpulan pengguna Amazon Cognito dan titik akhir kumpulan pengguna.

Autentikasi API sesuai dengan model di mana aplikasi Anda memiliki komponen UI yang ada dan terutama bergantung pada kumpulan pengguna sebagai direktori pengguna. Desain ini menambahkan Amazon Cognito sebagai komponen dalam aplikasi yang lebih besar. Ini membutuhkan logika terprogram untuk menangani rantai tantangan dan respons yang kompleks.

Aplikasi ini tidak perlu mengimplementasikan implementasi pihak yang mengandalkan OpenID Connect (OIDC) penuh. Sebaliknya, ia memiliki kemampuan untuk memecahkan kode dan menggunakan JWT. Bila Anda menginginkan akses ke set lengkap fitur kumpulan pengguna untuk pengguna lokal, buat autentikasi Anda dengan Amazon Cognito SDK di lingkungan pengembangan Anda.

Otentikasi API dengan cakupan OAuth khusus kurang berorientasi pada otorisasi API eksternal. Untuk menambahkan cakupan khusus ke token akses dari otentikasi API, ubah token saat runtime dengan file. Pemicu Lambda generasi pra token

Diagram berikut mengilustrasikan sesi masuk khas untuk otentikasi API.

Diagram alur yang menampilkan aplikasi yang meminta pengguna untuk memasukkan dan menandatanganinya dengan SDK. AWS
Alur otentikasi API
  1. Seorang pengguna mengakses aplikasi Anda.

  2. Mereka memilih tautan “Masuk”.

  3. Mereka memasukkan nama pengguna dan kata sandi mereka.

  4. Aplikasi memanggil metode yang membuat permintaan InitiateAuthAPI. Permintaan meneruskan kredensi pengguna ke kumpulan pengguna.

  5. Kumpulan pengguna memvalidasi kredensi pengguna dan menentukan bahwa pengguna telah mengaktifkan otentikasi multi-faktor (MFA).

  6. Kumpulan pengguna merespons dengan tantangan yang meminta kode MFA.

  7. Aplikasi menghasilkan prompt yang mengumpulkan kode MFA dari pengguna.

  8. Aplikasi memanggil metode yang membuat permintaan RespondToAuthChallengeAPI. Permintaan melewati kode MFA pengguna.

  9. Kumpulan pengguna memvalidasi kode MFA pengguna.

  10. Kumpulan pengguna merespons dengan JWT pengguna.

  11. Aplikasi menerjemahkan, memvalidasi, dan menyimpan atau menyimpan JWT pengguna.

  12. Aplikasi menampilkan komponen yang dikontrol akses yang diminta.

  13. Pengguna melihat konten mereka.

  14. Kemudian, token akses pengguna telah kedaluwarsa, dan mereka meminta untuk melihat komponen yang dikendalikan akses.

  15. Aplikasi menentukan bahwa sesi pengguna harus bertahan. Ini memanggil InitiateAuthmetode lagi dengan token penyegaran dan mengambil token baru.

Varian dan kustomisasi

Anda dapat menambah alur ini dengan tantangan tambahan—misalnya, tantangan autentikasi kustom Anda sendiri. Anda dapat secara otomatis membatasi akses untuk pengguna yang kata sandinya telah disusupi, atau yang karakteristik login yang tidak terduga mungkin menunjukkan upaya masuk yang berbahaya. Alur ini terlihat hampir sama untuk operasi untuk mendaftar, memperbarui atribut pengguna, dan mengatur ulang kata sandi. Sebagian besar alur ini memiliki operasi API publik duplikat (sisi klien) dan rahasia (sisi server).

Autentikasi kumpulan pengguna dengan UI yang dihosting

UI yang dihosting adalah situs web yang ditautkan ke kumpulan pengguna dan klien aplikasi Anda. Ini dapat melakukan operasi masuk, mendaftar, dan mengatur ulang kata sandi untuk pengguna Anda. Aplikasi dengan komponen UI yang di-host untuk otentikasi dapat memerlukan lebih sedikit upaya pengembang untuk mengimplementasikannya. Aplikasi dapat melewati komponen UI untuk otentikasi dan memanggil UI yang dihosting di browser pengguna.

Aplikasi mengumpulkan JWT pengguna dengan lokasi pengalihan web atau aplikasi. Aplikasi yang mengimplementasikan UI yang dihosting dapat terhubung ke kumpulan pengguna untuk otentikasi seolah-olah mereka adalah iDP OpenID Connect (OIDC).

Otentikasi UI yang dihosting sesuai dengan model di mana aplikasi memerlukan server otorisasi, tetapi tidak memerlukan fitur seperti otentikasi khusus, integrasi kumpulan identitas, atau layanan mandiri atribut pengguna. Bila Anda ingin menggunakan beberapa opsi lanjutan ini, Anda dapat menerapkannya dengan komponen kumpulan pengguna untuk SDK.

UI yang dihosting dan model otentikasi IDP pihak ketiga, dengan ketergantungan utama pada implementasi OIDC, adalah yang terbaik untuk model otorisasi lanjutan dengan cakupan OAuth 2.0.

Diagram berikut mengilustrasikan sesi masuk khas untuk otentikasi UI yang dihosting.

Diagram alur yang menampilkan aplikasi yang meminta pengguna untuk memasukkan dan menandatanganinya dengan UI yang dihosting.
Alur otentikasi UI yang dihosting
  1. Seorang pengguna mengakses aplikasi Anda.

  2. Mereka memilih tautan “Masuk”.

  3. Aplikasi mengarahkan pengguna ke prompt masuk UI yang dihosting.

  4. Mereka memasukkan nama pengguna dan kata sandi mereka.

  5. Kumpulan pengguna memvalidasi kredensi pengguna dan menentukan bahwa pengguna telah mengaktifkan otentikasi multi-faktor (MFA).

  6. UI yang dihosting meminta pengguna untuk memasukkan kode MFA.

  7. Pengguna memasukkan kode MFA mereka.

  8. UI yang dihosting mengarahkan pengguna ke aplikasi.

  9. Aplikasi mengumpulkan kode otorisasi dari parameter permintaan URL yang ditambahkan UI yang di-host ke URL callback.

  10. Aplikasi meminta token dengan kode otorisasi.

  11. Titik akhir token mengembalikan JWT ke aplikasi.

  12. Aplikasi menerjemahkan, memvalidasi, dan menyimpan atau menyimpan JWT pengguna.

  13. Aplikasi menampilkan komponen yang dikontrol akses yang diminta.

  14. Pengguna melihat konten mereka.

  15. Kemudian, token akses pengguna telah kedaluwarsa, dan mereka meminta untuk melihat komponen yang dikendalikan akses.

  16. Aplikasi menentukan bahwa sesi pengguna harus bertahan. Ini meminta token baru dari titik akhir token dengan token penyegaran.

Varian dan kustomisasi

Anda dapat menyesuaikan tampilan dan nuansa UI yang dihosting dengan CSS di klien aplikasi apa pun. Anda juga dapat mengonfigurasi klien aplikasi dengan penyedia identitas mereka sendiri, cakupan, akses ke atribut pengguna, dan konfigurasi keamanan lanjutan.

Autentikasi kumpulan pengguna dengan penyedia identitas pihak ketiga

Masuk dengan penyedia identitas eksternal (iDP), atau otentikasi federasi, adalah model yang mirip dengan UI yang dihosting. Aplikasi Anda adalah pihak yang mengandalkan OIDC ke kumpulan pengguna Anda, sementara kumpulan pengguna Anda berfungsi sebagai passthrough ke iDP. IDP dapat berupa direktori pengguna konsumen seperti Facebook atau Google, atau dapat berupa direktori perusahaan SAMP 2.0 atau OIDC seperti Azure.

Alih-alih UI yang dihosting di browser pengguna, aplikasi Anda memanggil titik akhir pengalihan pada server otorisasi kumpulan pengguna. Dari tampilan pengguna, mereka memilih tombol masuk di aplikasi Anda. Kemudian iDP mereka meminta mereka untuk masuk. Seperti otentikasi UI yang dihosting, aplikasi mengumpulkan JWT di lokasi pengalihan di aplikasi.

Otentikasi dengan iDP pihak ketiga sesuai dengan model di mana pengguna mungkin tidak ingin membuat kata sandi baru saat mereka mendaftar untuk aplikasi Anda. Otentikasi pihak ketiga dapat ditambahkan dengan upaya rendah ke aplikasi yang menerapkan otentikasi UI yang dihosting. Akibatnya, UI yang dihosting dan pihak ketiga IdPs menghasilkan hasil otentikasi yang konsisten dari variasi kecil dalam apa yang Anda panggil di browser pengguna.

Seperti otentikasi UI yang dihosting, otentikasi federasi adalah yang terbaik untuk model otorisasi lanjutan dengan cakupan OAuth 2.0.

Diagram berikut menggambarkan sesi masuk khas untuk otentikasi federasi.

Diagram alur yang menunjukkan aplikasi yang meminta pengguna untuk memasukkan dan menandatanganinya dengan iDP pihak ketiga.
Alur otentikasi federasi
  1. Seorang pengguna mengakses aplikasi Anda.

  2. Mereka memilih tautan “Masuk”.

  3. Aplikasi mengarahkan pengguna ke prompt masuk dengan IDP mereka.

  4. Mereka memasukkan nama pengguna dan kata sandi mereka.

  5. IDP memvalidasi kredensi pengguna dan menentukan bahwa pengguna telah mengaktifkan otentikasi multi-faktor (MFA).

  6. IDP meminta pengguna untuk memasukkan kode MFA.

  7. Pengguna memasukkan kode MFA mereka.

  8. IdP mengarahkan pengguna ke kumpulan pengguna dengan respons SAMP atau kode otorisasi.

  9. Jika pengguna melewati kode otorisasi, kumpulan pengguna diam-diam menukar kode untuk token iDP. Kumpulan pengguna memvalidasi token IDP dan mengarahkan pengguna ke aplikasi dengan kode otorisasi baru.

  10. Aplikasi mengumpulkan kode otorisasi dari parameter permintaan URL yang ditambahkan kumpulan pengguna ke URL callback.

  11. Aplikasi meminta token dengan kode otorisasi.

  12. Titik akhir token mengembalikan JWT ke aplikasi.

  13. Aplikasi menerjemahkan, memvalidasi, dan menyimpan atau menyimpan JWT pengguna.

  14. Aplikasi menampilkan komponen yang dikontrol akses yang diminta.

  15. Pengguna melihat konten mereka.

  16. Kemudian, token akses pengguna telah kedaluwarsa, dan mereka meminta untuk melihat komponen yang dikendalikan akses.

  17. Aplikasi menentukan bahwa sesi pengguna harus bertahan. Ini meminta token baru dari titik akhir token dengan token penyegaran.

Varian dan kustomisasi

Anda dapat memulai autentikasi federasi di UI yang dihosting, tempat pengguna dapat memilih dari daftar IdPs yang ditetapkan ke klien aplikasi Anda. UI yang dihosting juga dapat meminta alamat email dan secara otomatis merutekan permintaan pengguna ke IDP SAMP yang sesuai. Otentikasi dengan penyedia identitas pihak ketiga tidak memerlukan interaksi pengguna dengan UI yang dihosting. Aplikasi Anda dapat menambahkan parameter permintaan ke permintaan server otorisasi pengguna dan menyebabkan pengguna diam-diam mengalihkan ke halaman masuk IDP mereka.

Autentikasi kumpulan identitas

Identity pool adalah komponen untuk aplikasi Anda yang berbeda dari kumpulan pengguna dalam fungsi, namespace API, dan model SDK. Jika kumpulan pengguna menawarkan otentikasi dan otorisasi berbasis token, kumpulan identitas menawarkan otorisasi untuk (IAM). AWS Identity and Access Management

Anda dapat menetapkan satu set kumpulan IdPs identitas dan masuk pengguna dengan mereka. Kumpulan pengguna terintegrasi erat sebagai kumpulan identitas IdPs dan memberikan kolam identitas opsi terbanyak untuk kontrol akses. Pada saat yang sama, ada berbagai pilihan opsi otentikasi untuk kumpulan identitas. Kumpulan pengguna bergabung dengan sumber identitas SAMP, OIDC, sosial, pengembang, dan tamu sebagai rute ke AWS kredensi sementara dari kumpulan identitas.

Otentikasi dengan kumpulan identitas bersifat eksternal—ini mengikuti salah satu alur kumpulan pengguna yang diilustrasikan sebelumnya, atau aliran yang Anda kembangkan secara independen dengan iDP lain. Setelah aplikasi Anda melakukan otentikasi awal, ia meneruskan bukti ke kumpulan identitas dan menerima sesi sementara sebagai imbalan.

Otentikasi dengan kumpulan identitas sesuai dengan model tempat Anda menerapkan kontrol akses untuk aset dan data aplikasi Layanan AWS dengan otorisasi IAM. Seperti autentikasi API di kumpulan pengguna, aplikasi yang berhasil menyertakan AWS SDK untuk setiap layanan yang ingin Anda akses untuk keuntungan pengguna Anda. AWS SDK menerapkan kredensil dari autentikasi kumpulan identitas sebagai tanda tangan ke permintaan API.

Diagram berikut mengilustrasikan sesi masuk khas untuk otentikasi kumpulan identitas dengan IDP.

Diagram alur yang menunjukkan aplikasi yang meminta pengguna untuk memasukkan dan menandatanganinya dengan iDP pihak ketiga.
Alur otentikasi federasi
  1. Seorang pengguna mengakses aplikasi Anda.

  2. Mereka memilih tautan “Masuk”.

  3. Aplikasi mengarahkan pengguna ke prompt masuk dengan IDP mereka.

  4. Mereka memasukkan nama pengguna dan kata sandi mereka.

  5. IdP memvalidasi kredensi pengguna.

  6. IdP mengarahkan pengguna ke aplikasi dengan respons SAMP atau kode otorisasi.

  7. Jika pengguna melewati kode otorisasi, aplikasi menukar kode untuk token iDP.

  8. Aplikasi menerjemahkan, memvalidasi, dan menyimpan atau menyimpan JWT atau pernyataan pengguna.

  9. Aplikasi memanggil metode yang membuat permintaan GetIdAPI. Ini melewati token atau pernyataan pengguna dan meminta ID identitas.

  10. Kumpulan identitas memvalidasi token atau pernyataan terhadap penyedia identitas yang dikonfigurasi.

  11. Identity pool mengembalikan ID identitas.

  12. Aplikasi memanggil metode yang membuat permintaan GetCredentialsForIdentityAPI. Ini melewati token atau pernyataan pengguna dan meminta peran IAM.

  13. Kumpulan identitas menghasilkan JWT baru. JWT baru berisi klaim yang meminta peran IAM. Kumpulan identitas menentukan peran berdasarkan permintaan pengguna dan kriteria pemilihan peran dalam konfigurasi kumpulan identitas untuk iDP.

  14. AWS Security Token Service (AWS STS) menanggapi AssumeRoleWithWebIdentitypermintaan dari kumpulan identitas. Respons berisi kredensil API untuk sesi sementara dengan peran IAM.

  15. Aplikasi menyimpan kredensil sesi.

  16. Pengguna mengambil tindakan di aplikasi yang membutuhkan sumber daya yang dilindungi akses. AWS

  17. Aplikasi menerapkan kredensil sementara sebagai tanda tangan untuk permintaan API untuk yang diperlukan. Layanan AWS

  18. IAM mengevaluasi kebijakan yang melekat pada peran dalam kredensi. Ini membandingkannya dengan permintaan.

  19. Layanan AWS Mengembalikan data yang diminta.

  20. Aplikasi merender data di antarmuka pengguna.

  21. Pengguna melihat data.

Varian dan kustomisasi

Untuk memvisualisasikan otentikasi dengan kumpulan pengguna, masukkan salah satu ikhtisar kumpulan pengguna sebelumnya setelah langkah token/pernyataan Masalah. Otentikasi pengembang menggantikan semua langkah sebelum Minta identitas dengan permintaan yang ditandatangani oleh kredensi pengembang. Otentikasi tamu juga melompat langsung ke identitas Permintaan, tidak memvalidasi otentikasi, dan mengembalikan kredensional untuk peran IAM akses terbatas.