Panduan konsep penautan Login dengan Google berbasis OAuth yang "Sederhana"

Login dengan Google berbasis OAuth "Disederhanakan" jenis penautan akan menambahkan Login dengan Google Penautan akun berbasis OAuth. Jika Anda menggunakan jenis penautan ini dalam Action Anda, dimulai dengan Login dengan Google, yang memungkinkan Anda memeriksa apakah informasi profil ada dalam sistem Anda. Jika tidak, alur OAuth standar dimulai. Dengan memberikan kombinasi dari kedua jenis penautan ini, pengguna Anda dapat menautkan identitasnya di Action Anda dengan akun Google atau non-Google. Jika yang dipilih, mereka juga dapat membuat akun baru dengan profil Google tidak akurat atau tidak sesuai.

Penautan yang disederhanakan adalah solusi penautan akun yang direkomendasikan jika ada hal-hal berikut berlaku:

• Anda memiliki Action yang mencakup beberapa platform (misalnya, jika Action berfungsi dengan aplikasi Android).
• Anda sudah memiliki sistem otentikasi dan Anda ingin mengizinkan pengguna untuk menautkan identitas mereka dengan akun non-Google. Misalnya, jika Anda menawarkan sebuah program loyalitas dan ingin memastikan bahwa pengguna tidak kehilangan poin yang terakumulasi di akun mereka yang ada.

Untuk memastikan bahwa Penautan sederhana adalah solusi yang tepat untuk Anda, lihat Halaman Pilih jenis penautan akun.

Istilah utama

Sebelum membaca cara kerja Penautan yang disederhanakan, pelajari diri Anda dengan persyaratan berikut:

• Token ID Google: Pernyataan bertanda tangan tentang identitas pengguna yang berisi informasi profil Google dasar pengguna (nama, alamat email, dan gambar profil tertentu). Token ID Google adalah Token Web JSON (JWT). Berikut adalah contoh token yang didekode:

{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The token's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Client ID assigned to your Actions project
  "iat": 233366400,         // Unix timestamp of the token's creation time
  "exp": 233370000,         // Unix timestamp of the token's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "[e-mail]", // If present, the user's email address
  "locale": "en_US"
}

• user.verificationStatus: Properti yang ditetapkan oleh sistem untuk menunjukkan apakah sesi saat ini memiliki pengguna yang terverifikasi.

• user.accountLinkingStatus: Properti yang ditetapkan oleh sistem untuk menunjukkan apakah pengguna di sesi saat ini memiliki identitas tertaut.

• Adegan sistem penautan akun: Adegan standar yang menerapkan konfirmasi untuk penautan akun, dan dapat disesuaikan agar cocok dengan kasus penggunaan tertentu.

• Alur kode otorisasi: Alur OAuth 2.0 yang dapat Anda terapkan Penautan yang disederhanakan. Alur ini memerlukan dua endpoint:

  • Endpoint otorisasi: Endpoint yang menampilkan UI login kepada pengguna yang belum login. Ini mencatat persetujuan akses yang diminta dalam bentuk kode otorisasi berjangka pendek.
  • Endpoint pertukaran token: Endpoint ini bertanggung jawab atas dua jenis dari pertukaran:
    1. Menukar kode otorisasi dengan token refresh yang berumur panjang dan token akses berumur pendek. Pertukaran ini terjadi ketika pengguna melalui alur penautan akun.
    2. Menukar token refresh berumur panjang dengan akses berumur pendek sebelumnya yang benar. Pertukaran ini terjadi ketika Google memerlukan token akses baru karena sudah tidak berlaku.

• Alur kode implisit: Alur OAuth 2.0 yang dapat Anda implementasikan dengan Penautan yang disederhanakan. Alur ini hanya memerlukan endpoint otorisasi. Selama alur ini, Google akan membuka endpoint otorisasi Anda di bagian browser. Jika berhasil login, Anda mengembalikan token akses jangka panjang ke Google. Token akses ini kini disertakan dalam setiap permintaan yang dikirim dari Asisten ke Action Anda.

• Token akses: Token yang memberi otorisasi layanan Anda untuk mengakses bagian data pengguna. Token akses dikaitkan dengan setiap pengguna.

• Token refresh: Token yang ditukarkan dengan token akses baru setelah masa berlaku token akses singkat telah berakhir.

Prasyarat

Untuk menggunakan jenis Penautan yang disederhanakan, Anda memerlukan hal berikut:

• Server OAuth 2.0

• Endpoint pertukaran token

  Endpoint pertukaran token harus diperpanjang untuk menambahkan dukungan bagi protokol untuk penautan otomatis dan pembuatan akun dari token ID (yaitu, menambahkan parameter intent=get dan intent=create dalam permintaan ke endpoint ini).

Cara kerjanya

Bagian ini menjelaskan alur umum untuk Penautan yang disederhanakan. Bagian berikut, Alur penautan yang disederhanakan, menjelaskan beragam alur yang dapat terjadi berdasarkan a) apakah Anda mengaktifkan atau menonaktifkan pembuatan akun melalui suara dan b) baik Anda menggunakan alur kode otorisasi.

Alur dasarnya adalah sebagai berikut:

1. Action Anda meminta izin kepada pengguna untuk mengakses profil Google miliknya.
2. Setelah pengguna memberikan izin, Action Anda akan menerima token ID Google yang berisi informasi profil Google pengguna.
3. Anda harus memvalidasi dan mendekode token untuk membaca konten profil.
4. Action Anda menggunakan token ini untuk memeriksa apakah profil Google pengguna informasi ada di dalam sistem.
   1. Jika ya, pengguna telah masuk ke sistem Anda dengan Akun Google, dan Asisten menautkan identitas pengguna dengan Akun Google. Pengguna dapat melanjutkan percakapan dengan Asisten dengan akunnya yang ditautkan.
   2. Jika tidak, lihat langkah 5.
5. Pengguna dapat a) membuat akun baru dengan profil Google miliknya atau b) masuk ke sistem Anda dengan akun lain. Tujuan pilihan yang diberikan kepada pengguna berbeda berdasarkan apakah Anda mengaktifkan atau nonaktifkan pembuatan akun via suara. Jika pengguna memilih untuk login ke dengan akun yang berbeda, alur OAuth standar akan dimulai.
6. Setelah pengguna membuat akun baru atau {i>login<i} dengan penyedia yang berbeda, layanan Anda mengembalikan token akses ke Google. (Jika Anda menggunakan alur kode otorisasi, layanan Anda juga akan menampilkan token refresh.)
7. Pengguna kini dapat melanjutkan percakapan dengan Asisten menggunakan akun ditautkan.

Alur penautan yang disederhanakan

Bagian ini membahas berbagai alur yang dapat terjadi dengan Penautan yang disederhanakan. Diagram ini membahas alur yang terjadi dengan alur kode otorisasi bukan alur kode implisit, dan menganggap Anda menggunakan Action Builder.

Catatan: Alur berikut mengasumsikan bahwa pengguna memberikan izin untuk Action Anda untuk mengakses informasi profil Google mereka. Jika pengguna tidak memberikan izin, memberi mereka cara untuk melanjutkan Action Anda dengan alur alternatif dan terbatas. Untuk mengetahui informasi selengkapnya, baca Praktik terbaik.

Setiap alur berisi langkah-langkah umum berikut setelah pengguna memanggil Action Anda:

Dalam alur di atas, Anda beralih ke adegan sistem penautan akun dan memberikan alasan yang disesuaikan. Adegan meminta izin kepada pengguna untuk mengakses informasi profil Google mereka. Setelah pengguna memberikan izin, Asisten akan mengirimkan permintaan yang berisi informasi profil untuk [e-mail].

Alur setelah tahap ini berbeda berdasarkan apakah Anda mengonfigurasi akun atau tidak menautkan dengan suara dan apakah informasi pengguna sudah ada di sistem file. Setiap alur ini dijelaskan di bagian berikut.

Alur dengan pembuatan akun suara diaktifkan

Bagian ini menjelaskan alur penautan akun yang dapat terjadi jika Anda mengaktifkan pembuatan akun melalui suara.

Catatan: Diagram berikut dibuat dari diagram Langkah-langkah umum di atas.

Alur 1: Informasi pengguna ada dalam sistem Anda

Catatan: Baris dari Webhook ke Pengguna mewakili tanggapan sederhana yang Anda buat dan sesuaikan. Garis yang digambar dari Asisten ke Pengguna mewakili perintah yang dimiliki oleh Asisten dan memiliki opsi penyesuaian terbatas (permintaan yang memerlukan izin selalu dimiliki oleh Asisten). Dari perspektif pengguna, kedua jenis respons tersebut akan disampaikan dari Asisten.

Dalam hal ini, pengguna yang diwakili oleh [e-mail] ada di backend Anda, jadi endpoint pertukaran token Anda menampilkan token untuk pengguna. identitas di Action Anda sekarang ditautkan ke Akun Google mereka. permintaan asli (“Pesan seperti biasa”) cocok dengan intent pengguna order_drink. Webhook Anda kemudian akan menangani fulfillment intent yang cocok dan mengkueri database untuk pesanan biasa [e-mail]. Pengguna kemudian dapat melanjutkan percakapan dengan Asisten.

Alur 2: Informasi pengguna tidak ada dan pengguna membuat akun

Karena Anda mengaktifkan pembuatan akun melalui suara dan [e-mail] tidak melakukannya ada di backend Anda, Asisten bertanya kepada pengguna apakah mereka ingin melakukannya salah satu dari hal berikut:

a) Membuat akun baru di sistem menggunakan informasi profil Google, yang dilakukan melalui suara

b) Login ke sistem Anda dengan akun lain

Catatan: Anda juga dapat mengizinkan pengguna membuat akun baru dengan penyedia yang berbeda. Penyedia berikut adalah yang Anda sediakan di halaman otorisasi.

Dalam hal ini, pengguna memilih untuk membuat akun baru melalui suara. Panggilan Google endpoint pertukaran token layanan Anda dengan permintaan untuk membuat akun. Permintaan ini berisi token ID Google, yang mencakup komponen yang diperlukan untuk membuat akun baru. Selanjutnya, Anda dapat menggunakan informasi dari token ini (nama dan alamat email pengguna) untuk membuat akun bagi pengguna tersebut.

Setelah akun dibuat, layanan Anda akan menampilkan token akses dan memuat ulang untuk akun yang baru dibuat. Identitas pengguna di Action Anda sekarang yang ditautkan ke Akun Google mereka. Permintaan asli pengguna (“Pesan seperti biasa”) cocok dengan intent pengguna order_drink. Webhook Anda lalu menangani fulfillment intent yang cocok dan mengkueri database Anda Pesanan [e-mail] yang biasa, yang belum ada karena pengguna masih baru. Action Anda kemudian dapat menanyakan kepada pengguna apa yang ingin mereka pesan.

Catatan: Sandi baru biasanya tidak disetel untuk akun baru. Disarankan agar Anda menambahkan Login dengan Google ke platform lain untuk memungkinkan pengguna login melalui Google di seluruh platform aplikasi Anda. Atau, Anda dapat mengirim email ke pengguna tautan yang memulai alur pemulihan {i>password<i} Anda untuk memungkinkan pengguna mengatur sandi untuk login di platform lain.

Alur 3: Informasi pengguna tidak ada dan pengguna login dengan akun yang berbeda

Anda mengaktifkan pembuatan akun melalui suara, jadi Asisten akan bertanya kepada pengguna apakah mereka ingin melakukan salah satu dari hal berikut:

a) Membuat akun baru di sistem menggunakan informasi profil Google, yang dilakukan melalui suara

b) Login ke sistem Anda dengan akun lain

Catatan: Anda juga dapat mengizinkan pengguna membuat akun baru dengan akun berbeda penyedia layanan. Penyedia ini adalah yang Anda sediakan berdasarkan otorisasi Anda halaman.

Dalam hal ini, pengguna memilih untuk masuk dengan akun yang berbeda, yang memulai alur OAuth standar. Jika alurnya dimulai di perangkat khusus suara, Google akan mentransfer eksekusi ke ponsel. Google kemudian membuka endpoint otorisasi Anda di browser pengguna, dan, bergantung pada pengguna dapat memilih untuk a) login ke layanan Anda dengan akun yang sudah ada yang tidak menggunakan Login dengan Google atau b) membuat akun baru menggunakan penyedia yang berbeda. Untuk informasi selengkapnya tentang alur OAuth, lihat Panduan konsep penautan OAuth.

Setelah memverifikasi kredensial pengguna, layanan Anda akan menampilkan token akses dan token refresh ke Google. Identitas pengguna di Action Anda kini ditautkan ke akun non-Google. Permintaan asli pengguna (“Pesan seperti biasa”) cocok intent pengguna order_drink. Webhook Anda kemudian akan menangani fulfillment intent yang cocok dan mengkueri database Anda untuk urutan [e-mail] yang biasa, yang belum ada karena penggunanya baru. Action Anda kemudian dapat meminta pengguna apa yang ingin mereka pesan atau meminta mereka untuk mengatur pesanan mereka seperti biasa.

Alur dengan pembuatan akun suara dinonaktifkan

Bagian ini menjelaskan alur penautan akun yang dapat terjadi jika Anda menonaktifkan pembuatan akun melalui suara.

Catatan: Diagram berikut dibuat dari diagram Langkah-langkah umum di atas.

Alur 4: Informasi pengguna tidak ada

Anda tidak mengaktifkan pembuatan akun melalui suara dan pengguna tidak ada di backend, sehingga alur OAuth standar akan dimulai. Asisten membuka endpoint otorisasi di browser pengguna (jika alur dimulai pada perangkat, Google akan mentransfer eksekusi ke perangkat yang memiliki layar). Pengguna dapat memilih untuk a) login dengan penyedia lain, jika mereka telah mendaftar ke layanan Anda dengan akun yang berbeda atau b) membuat akun baru dengan penyedia layanan yang berbeda. Untuk informasi selengkapnya tentang alur OAuth, lihat Panduan konsep penautan OAuth.

Setelah memverifikasi kredensial pengguna, layanan Anda akan menampilkan token akses dan token refresh ke Google. Identitas pengguna di Action Anda kini ditautkan ke akun non-Google. Permintaan asli pengguna (“Pesan seperti biasa”) cocok intent pengguna order_drink. Webhook Anda kemudian akan menangani fulfillment intent yang cocok dan mengkueri database Anda untuk urutan [e-mail] yang biasa, yang belum ada karena penggunanya baru. Action Anda kemudian dapat meminta pengguna untuk mengatur pesanan mereka seperti biasa.