OAuth 2.0 untuk Aplikasi Seluler dan Desktop

<0x0Ringkasan ini merangkum alur OAuth 2.0 yang didukung Google, yang dapat membantu Anda memastikan bahwa Anda telah memilih alur yang tepat untuk aplikasi Anda.

Dokumen ini menjelaskan cara aplikasi yang diinstal di perangkat seperti ponsel, tablet, dan komputer menggunakan endpoint OAuth 2.0 Google untuk mengizinkan akses ke YouTube Analytics API atau YouTube Reporting API.

OAuth 2.0 memungkinkan pengguna berbagi data tertentu dengan aplikasi, sekaligus menjaga kerahasiaan nama pengguna, sandi, dan informasi mereka lainnya. Misalnya, aplikasi dapat menggunakan OAuth 2.0 untuk mendapatkan izin guna mengambil data YouTube Analytics channel.

Aplikasi yang diinstal didistribusikan ke perangkat individual, dan diasumsikan bahwa aplikasi ini tidak dapat menyimpan rahasia. Aplikasi dapat mengakses Google API saat pengguna berada di aplikasi atau saat aplikasi berjalan di latar belakang.

Alur otorisasi ini mirip dengan alur yang digunakan untuk aplikasi server web. Perbedaan utamanya adalah aplikasi yang diinstal harus membuka browser sistem dan menyediakan URI pengalihan lokal untuk menangani respons dari server otorisasi Google.

Library dan contoh

Untuk aplikasi iOS, sebaiknya gunakan versi terbaru Sign In With Google iOS SDK. SDK menangani otorisasi pengguna dan lebih mudah diterapkan daripada protokol tingkat rendah yang dijelaskan dalam panduan ini.

Untuk aplikasi yang berjalan di perangkat yang tidak mendukung browser sistem atau yang memiliki kemampuan input terbatas, seperti TV, konsol game, kamera, atau printer, lihat OAuth 2.0 untuk TV & Perangkat atau Login di TV dan Perangkat Input Terbatas.

Prasyarat

Mengaktifkan API untuk project Anda

Aplikasi apa pun yang memanggil Google API harus mengaktifkan API tersebut di API Console.

Untuk mengaktifkan API untuk project Anda:

1. Open the API Library di Google API Console.
2. If prompted, select a project, or create a new one.
3. Gunakan halaman Library untuk menemukan dan mengaktifkan YouTube Analytics API dan YouTube Reporting API. Banyak aplikasi yang mengambil data YouTube Analytics juga berinteraksi dengan YouTube Data API. Temukan API lain yang akan digunakan aplikasi Anda dan aktifkan juga API tersebut.

Membuat kredensial otorisasi

Setiap aplikasi yang menggunakan OAuth 2.0 untuk mengakses Google API harus memiliki kredensial otorisasi yang mengidentifikasi aplikasi ke server OAuth 2.0 Google. Langkah-langkah berikut menjelaskan cara membuat kredensial untuk project Anda. Aplikasi Anda kemudian dapat menggunakan kredensial untuk mengakses API yang telah Anda aktifkan untuk project tersebut.

1. Go to the Clients page.
2. Klik Buat klien.
3. Bagian berikut menjelaskan jenis klien yang didukung server otorisasi Google. Pilih jenis klien yang direkomendasikan untuk aplikasi Anda, beri nama klien OAuth Anda, dan tetapkan kolom lainnya dalam formulir sesuai kebutuhan.

iOS

1. Pilih tipe aplikasi iOS.
2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan pada Clients page proyek Anda untuk mengidentifikasi klien.
3. Masukkan pengidentifikasi bundel untuk aplikasi Anda. ID bundel adalah nilai dari kunci CFBundleIdentifier dalam file sumber daya daftar properti informasi aplikasi Anda (info.plist). Nilai tersebut paling sering ditampilkan di panel Umum atau panel Penandatanganan & Kemampuan pada editor proyek Xcode. ID bundel juga ditampilkan di bagian Informasi Umum pada halaman Informasi Aplikasi untuk aplikasi tersebut.Situs App Store Connect milik Apple .

   Pastikan Anda menggunakan ID bundel yang benar untuk aplikasi Anda, karena Anda tidak dapat mengubahnya jika menggunakan fitur Pemeriksaan Aplikasi.

4. (Opsional)

   Masukkan ID App Store aplikasi Anda jika aplikasi tersebut diterbitkan di App Store Apple. ID Toko adalah rangkaian angka yang disertakan dalam setiap URL Apple App Store.

   1. Buka aplikasi Apple App Store di perangkat iOS atau iPadOS Anda.
   2. Telusuri aplikasi Anda.
   3. Pilih tombol Bagikan (simbol persegi dan panah ke atas).
   4. Pilih Salin Tautan.
   5. Salin tautan tersebut ke editor teks. ID App Store adalah bagian terakhir dari URL.

      Contoh: https://apps.apple.com/app/google/id284815942

5. (Opsional)

   Masukkan ID Tim Anda. Lihat Temukan ID Tim Anda di dokumentasi Akun Pengembang Apple untuk informasi selengkapnya.

   Catatan: Kolom ID Tim wajib diisi jika Anda mengaktifkan Pemeriksaan Aplikasi untuk klien Anda.
6. (Opsional)

   Aktifkan Pemeriksaan Aplikasi untuk aplikasi iOS Anda. Saat Anda mengaktifkan Pemeriksaan Aplikasi, layanan App Attest milik Apple digunakan untuk memverifikasi bahwa permintaan OAuth 2.0 yang berasal dari klien OAuth Anda adalah asli dan berasal dari aplikasi Anda. Ini membantu mengurangi risiko peniruan identitas aplikasi. Pelajari selengkapnya tentang mengaktifkan Pemeriksaan Aplikasi untuk aplikasi iOS Anda.

7. Klik Buat.

UWP

1. Pilih tipe aplikasi Universal Windows Platform.
2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan pada Clients page proyek Anda untuk mengidentifikasi klien.
3. Masukkan ID Microsoft Store 12 karakter aplikasi Anda. Anda dapat menemukan nilai ini di Microsoft Partner Center di halaman Identitas aplikasi di bagian Pengelolaan aplikasi.
4. Klik Buat.

Untuk aplikasi UWP, URI pengalihan dibuat menggunakan ID Keamanan Paket (SID) unik aplikasi Anda. Anda dapat menemukan Package SID aplikasi di file Package.appxmanifest dalam project Visual Studio Anda.

Saat membuat client ID di konsol Google Cloud, Anda harus menentukan URI pengalihan dalam format berikut, menggunakan nilai huruf kecil dari SID Paket Anda:

ms-app://YOUR_APP_PACKAGE_SID

Catatan: Skema ms-app:// diperlukan agar pengalihan OAuth 2.0 berfungsi dengan benar. Skema ini digunakan untuk aktivasi protokol, yang memungkinkan sistem operasi meluncurkan aplikasi Anda dan mengirimkan respons otorisasi dari Google setelah pengguna melakukan autentikasi di browser.

Untuk aplikasi UWP, skema URI kustom tidak boleh lebih dari 39 karakter, seperti yang ditentukan dalam dokumentasi Microsoft.

Mengidentifikasi cakupan akses

Cakupan memungkinkan aplikasi Anda hanya meminta akses ke resource yang diperlukan sekaligus memungkinkan pengguna mengontrol jumlah akses yang mereka berikan ke aplikasi Anda. Oleh karena itu, mungkin ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan mendapatkan izin pengguna.

Sebelum mulai menerapkan otorisasi OAuth 2.0, sebaiknya Anda mengidentifikasi cakupan yang izin aksesnya akan diperlukan oleh aplikasi Anda.

Catatan: Otorisasi inkremental tidak didukung untuk aplikasi atau perangkat yang diinstal.

YouTube Analytics API menggunakan cakupan berikut:

Cakupan	Deskripsi
https://www.googleapis.com/auth/youtube	Mengelola akun YouTube Anda
https://www.googleapis.com/auth/youtube.readonly	Melihat akun YouTube Anda
https://www.googleapis.com/auth/youtubepartner	Melihat dan mengelola aset Anda dan konten terkait di YouTube
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	Melihat laporan moneter dan non-moneter YouTube Analytics untuk konten YouTube Anda
https://www.googleapis.com/auth/yt-analytics.readonly	Melihat laporan YouTube Analytics untuk konten YouTube Anda

YouTube Reporting API menggunakan cakupan berikut:

Cakupan	Deskripsi
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	Melihat laporan moneter dan non-moneter YouTube Analytics untuk konten YouTube Anda
https://www.googleapis.com/auth/yt-analytics.readonly	Melihat laporan YouTube Analytics untuk konten YouTube Anda

Dokumen Cakupan API OAuth 2.0 berisi daftar lengkap cakupan yang dapat Anda gunakan untuk mengakses Google API.

Jika aplikasi publik Anda menggunakan cakupan yang mengizinkan akses ke data pengguna tertentu, aplikasi tersebut harus menyelesaikan proses verifikasi. Jika Anda melihat aplikasi belum diverifikasi di layar saat menguji aplikasi, Anda harus mengirimkan permintaan verifikasi untuk menghapusnya. Cari tahu lebih lanjut tentang aplikasi yang tidak diverifikasi dan dapatkan jawaban atas pertanyaan umum tentang verifikasi aplikasi di Pusat Bantuan.

Mendapatkan token akses OAuth 2.0

Langkah-langkah berikut menunjukkan cara aplikasi Anda berinteraksi dengan server OAuth 2.0 Google untuk mendapatkan izin pengguna dalam melakukan permintaan API atas nama pengguna. Aplikasi Anda harus memiliki izin tersebut sebelum dapat mengeksekusi permintaan Google API yang memerlukan otorisasi pengguna.

Langkah 1: Buat verifier dan tantangan kode

Google mendukung protokol Proof Key for Code Exchange (PKCE) untuk membuat alur aplikasi yang diinstal lebih aman. Verifikasi kode unik dibuat untuk setiap permintaan otorisasi, dan nilai yang diubah, yang disebut "code_challenge", dikirim ke server otorisasi untuk mendapatkan kode otorisasi.

Buat verifier kode

code_verifier adalah string acak kriptografi entropi tinggi menggunakan karakter yang tidak dicadangkan [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", dengan panjang minimum 43 karakter dan panjang maksimum 128 karakter.

Verifier kode harus memiliki entropi yang cukup sehingga nilai tersebut tidak mungkin ditebak.

Membuat tantangan kode

Dua metode pembuatan tantangan kode didukung.

Metode Pembuatan Tantangan Kode
S256 (direkomendasikan)	Tantangan kode tersebut adalah hash SHA256 yang dikodekan Base64URL (tanpa padding) dari verifikator kode. code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain	Tantangan kode memiliki nilai yang sama dengan verifikasi kode yang dihasilkan di atas. code_challenge = code_verifier

Langkah 2: Kirim permintaan ke server OAuth 2.0 Google

Untuk mendapatkan otorisasi pengguna, kirim permintaan ke server otorisasi Google di https://accounts.google.com/o/oauth2/v2/auth. Endpoint ini menangani pencarian sesi aktif, mengautentikasi pengguna, dan memperoleh persetujuan pengguna. Endpoint ini hanya dapat diakses melalui SSL, dan menolak koneksi HTTP (non-SSL).

Server otorisasi mendukung parameter string kueri berikut untuk aplikasi yang terinstal:

Parameter
client_id	Wajib ID klien untuk aplikasi Anda. Anda dapat menemukan nilai ini di Cloud Console Clients page.
redirect_uri	Wajib Menentukan bagaimana server otorisasi Google mengirimkan respons ke aplikasi Anda. Ada beberapa opsi pengalihan yang tersedia untuk aplikasi yang terinstal, dan Anda pasti telah mengatur kredensial otorisasi Anda dengan metode pengalihan tertentu yang Anda inginkan. Nilainya harus sama persis dengan salah satu URI pengalihan resmi untuk klien OAuth 2.0, yang telah Anda konfigurasikan di Cloud Console Clients pageklien Anda. Jika nilai ini tidak sesuai dengan URI yang diizinkan, Anda akan mendapatkan kesalahan redirect_uri_mismatch. Tabel tersebut menunjukkan nilai parameter redirect_uri yang sesuai untuk setiap metode: Nilai redirect_uri Skema URI Kustom com.example.app:redirect_uri_path atau com.googleusercontent.apps.123:redirect_uri_path com.example.app adalah notasi DNS terbalik dari domain yang Anda kendalikan. Skema kustom harus mengandung titik agar valid. com.googleusercontent.apps.123 adalah notasi DNS terbalik dari ID klien. redirect_uri_path adalah komponen jalur opsional, seperti /oauth2redirect. Perhatikan bahwa jalur tersebut harus diawali dengan garis miring tunggal, yang berbeda dari URL HTTP biasa. Catatan : Skema URI kustom tidak lagi didukung pada aplikasi Android dan Chrome. Pelajari selengkapnya tentang alternatif skema kustom. Alamat IP Loopback http://127.0.0.1:port atau http://[::1]:port Lakukan query pada platform Anda untuk mendapatkan alamat IP loopback yang relevan dan mulai listener HTTP pada port acak yang tersedia. Ganti port dengan nomor port sebenarnya yang digunakan aplikasi Anda. Perlu dicatat bahwa dukungan untuk opsi pengalihan alamat IP loopback pada aplikasi seluler mobile apps sudah TIDAK DIGUNAKAN LAGI.
response_type	Wajib Menentukan apakah endpoint Google OAuth 2.0 mengembalikan kode otorisasi. Atur nilai parameter menjadi code untuk aplikasi yang terpasang.
scope	Wajib Daftar cakupan yang dipisahkan spasi yang mengidentifikasi sumber daya yang dapat diakses aplikasi Anda atas nama pengguna. Nilai-nilai ini menjadi dasar layar persetujuan yang ditampilkan Google kepada pengguna. Scope memungkinkan aplikasi Anda hanya meminta akses ke sumber daya yang dibutuhkannya, sekaligus memungkinkan pengguna untuk mengontrol jumlah akses yang mereka berikan ke aplikasi Anda. Dengan demikian, terdapat hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan memperoleh persetujuan pengguna. API YouTube Analytics menggunakan cakupan berikut: Cakupan Deskripsi https://www.googleapis.com/auth/youtube Mengelola akun YouTube Anda https://www.googleapis.com/auth/youtube.readonly Melihat akun YouTube Anda https://www.googleapis.com/auth/youtubepartner Melihat dan mengelola aset Anda dan konten terkait di YouTube https://www.googleapis.com/auth/yt-analytics-monetary.readonly Melihat laporan moneter dan non-moneter YouTube Analytics untuk konten YouTube Anda https://www.googleapis.com/auth/yt-analytics.readonly Melihat laporan YouTube Analytics untuk konten YouTube Anda API Pelaporan YouTube menggunakan cakupan berikut: Cakupan Deskripsi https://www.googleapis.com/auth/yt-analytics-monetary.readonly Melihat laporan moneter dan non-moneter YouTube Analytics untuk konten YouTube Anda https://www.googleapis.com/auth/yt-analytics.readonly Melihat laporan YouTube Analytics untuk konten YouTube Anda Dokumen OAuth 2.0 API Scopes menyediakan daftar lengkap cakupan yang dapat Anda gunakan untuk mengakses API Google.
code_challenge	Direkomendasikan Menentukan code_verifier yang dikodekan yang akan digunakan sebagai tantangan sisi server selama pertukaran kode otorisasi. Lihat tantangan membuat kode untuk informasi selengkapnya.
code_challenge_method	Direkomendasikan Menentukan metode apa yang digunakan untuk mengkodekan code_verifier yang akan digunakan selama pertukaran kode otorisasi. Parameter ini harus digunakan bersama dengan parameter code_challenge. Nilai code_challenge_method akan secara default menjadi plain jika tidak ada dalam permintaan yang menyertakan code_challenge. Satu-satunya nilai yang didukung untuk parameter ini adalahS256 atauplain.
state	Direkomendasikan Menentukan nilai string apa pun yang digunakan aplikasi Anda untuk mempertahankan status antara permintaan otorisasi Anda dan respons server otorisasi. Server mengembalikan nilai persis yang Anda kirim sebagai pasangan name=value dalam pengidentifikasi fragmen URL (#) dari redirect_uri setelah pengguna menyetujui atau menolak permintaan akses aplikasi Anda. Anda dapat menggunakan parameter ini untuk beberapa tujuan, seperti mengarahkan pengguna ke sumber daya yang tepat di aplikasi Anda, mengirim nonce, dan mengurangi serangan pemalsuan permintaan lintas situs (cross-site request forgery). Karena redirect_uri Anda dapat ditebak, menggunakan nilai state dapat meningkatkan kepastian bahwa koneksi masuk adalah hasil dari permintaan otentikasi. Jika Anda menghasilkan string acak atau mengenkode hash dari cookie atau nilai lain yang menangkap status klien, Anda dapat memvalidasi respons untuk memastikan bahwa permintaan dan respons berasal dari browser yang sama, sehingga memberikan perlindungan terhadap serangan seperti pemalsuan permintaan lintas situs. Lihat dokumentasi OpenID Connect untuk contoh cara membuat dan mengkonfirmasi token state. Penting: Klien OAuth harus mencegah CSRF seperti yang disebutkan dalam Spesifikasi OAuth2 . Salah satu cara untuk mencapai hal ini adalah dengan menggunakan parameter state untuk mempertahankan status antara permintaan otorisasi Anda dan respons server otorisasi.
login_hint	Opsional Jika aplikasi Anda mengetahui pengguna mana yang mencoba melakukan autentikasi, aplikasi dapat menggunakan parameter ini untuk memberikan petunjuk kepada Server Autentikasi Google. Server menggunakan petunjuk tersebut untuk menyederhanakan alur login, baik dengan mengisi otomatis kolom email pada formulir masuk atau dengan memilih sesi multi-login yang sesuai. Tetapkan nilai parameter ke alamat email atau pengidentifikasi sub, yang setara dengan ID Google pengguna.

Catatan: otorisasi inkremental dengan aplikasi yang terpasang tidak didukung karena klien tidak dapat menjaga kerahasiaan client_secret tersebut.

Contoh URL otorisasi

Tab di bawah ini menampilkan contoh URL otorisasi untuk berbagai opsi URI pengalihan.

Setiap URL meminta akses ke cakupan yang memungkinkan akses untuk mengambil laporan YouTube Analytics pengguna.

URL-nya identik kecuali nilai parameter redirect_uri. URL tersebut juga berisi parameter response_type dan client_id yang wajib serta parameter state opsional. Setiap URL berisi jeda baris dan spasi agar mudah dibaca.

Skema URI khusus

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

Alamat IP loopback

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Langkah 3: Google meminta persetujuan pengguna

Pada langkah ini, pengguna memutuskan apakah akan memberikan akses yang diminta kepada aplikasi Anda. Pada tahap ini, Google menampilkan jendela persetujuan yang menunjukkan nama aplikasi Anda dan layanan API Google yang diminta izin aksesnya beserta kredensial otorisasi pengguna dan ringkasan cakupan akses yang akan diberikan. Pengguna kemudian dapat menyetujui untuk memberikan akses ke satu atau lebih cakupan yang diminta oleh aplikasi Anda atau menolak permintaan tersebut.

Aplikasi Anda tidak perlu melakukan apa pun pada tahap ini karena sedang menunggu respons dari server OAuth 2.0 Google yang menunjukkan apakah akses telah diberikan. Jawaban tersebut dijelaskan pada langkah selanjutnya.

Error

Permintaan ke titik akhir otorisasi OAuth 2.0 Google mungkin menampilkan pesan kesalahan yang ditujukan kepada pengguna, alih-alih alur autentikasi dan otorisasi yang diharapkan. Kode kesalahan umum dan solusi yang disarankan adalah:

admin_policy_enforced

Akun Google tidak dapat mengotorisasi satu atau lebih cakupan yang diminta karena kebijakan administrator Google Workspace mereka. Lihat artikel bantuan Admin Google Workspace Kontrol aplikasi pihak ketiga & internal mana yang mengakses data Google Workspace untuk informasi lebih lanjut tentang bagaimana administrator dapat membatasi akses ke semua cakupan atau cakupan sensitif dan terbatas hingga akses diberikan secara eksplisit ke ID klien OAuth Anda.

disallowed_useragent

Endpoint otorisasi ditampilkan di dalam user-agent tersemat yang tidak diizinkan oleh Google.Kebijakan OAuth 2.0 .

Pengembang iOS dan macOS mungkin menemui kesalahan ini saat membuka permintaan otorisasi.WKWebView . Sebaiknya pengembang menggunakan pustaka iOS seperti Google Sign-In for iOS atau AppAuth for iOS dari OpenID Foundation.

Developer web mungkin mengalami error ini saat aplikasi iOS atau macOS membuka link web umum di agen pengguna yang disematkan dan pengguna membuka endpoint otorisasi OAuth 2.0 Google dari situs Anda. Developer harus mengizinkan link umum dibuka di pengendali link default sistem operasi, yang mencakup pengendali Universal Link atau aplikasi browser default. Library SFSafariViewController juga merupakan opsi yang didukung.

org_internal

ID klien OAuth dalam permintaan merupakan bagian dari proyek yang membatasi akses ke Akun Google di Organisasi Google Cloud tertentu. Untuk mengetahui informasi selengkapnya tentang opsi konfigurasi ini, lihat bagian Jenis pengguna dalam artikel bantuan Menyiapkan layar izin OAuth.

deleted_client

Klien OAuth yang digunakan untuk membuat permintaan tersebut telah dihapus. Penghapusan dapat dilakukan secara manual atau otomatis jika terdapat klien yang tidak digunakan . Klien yang dihapus dapat dipulihkan dalam waktu 30 hari setelah penghapusan. Pelajari lebih lanjut .

invalid_grant

Jika Anda menggunakan pemeriksa kode dan tantangan, parameter code_callenge tidak valid atau hilang. Pastikan parameter code_challenge diatur dengan benar.

Saat memperbarui token akses, token tersebut mungkin telah kedaluwarsa atau telah dibatalkan. Lakukan otentikasi pengguna lagi dan mintalah persetujuan pengguna untuk mendapatkan token baru. Jika Anda masih mengalami kesalahan ini, pastikan aplikasi Anda telah dikonfigurasi dengan benar dan Anda menggunakan token dan parameter yang tepat dalam permintaan Anda. Jika tidak, akun pengguna mungkin telah dihapus atau dinonaktifkan.

redirect_uri_mismatch

redirect_uri yang dilewatkan dalam permintaan otorisasi tidak sesuai dengan URI pengalihan resmi untuk ID klien OAuth. Tinjau URI pengalihan yang sah di Google Cloud Console Clients page.

redirect_uri yang diteruskan mungkin tidak valid untuk jenis klien.

Parameter redirect_uri dapat mengacu pada alur OAuth out-of-band (OOB) yang telah usang dan tidak lagi didukung. Lihat panduan migrasi untuk memperbarui integrasi Anda.

invalid_request

Terjadi kesalahan pada permintaan yang Anda buat. Hal ini dapat disebabkan oleh beberapa alasan:

• Permintaan tersebut tidak diformat dengan benar.
• Permintaan tidak memiliki parameter yang diperlukan
• Permintaan menggunakan metode otorisasi yang tidak didukung oleh Google. Memastikan integrasi OAuth Anda menggunakan metode integrasi yang direkomendasikan
• Skema kustom yang tidak didukung digunakan untuk URI pengalihan. Jika Anda melihat pesan kesalahan Skema URI kustom tidak didukung pada aplikasi Android atau Chrome, pelajari lebih lanjut tentang alternatif skema URI kustom.

Langkah 4: Tangani respons server OAuth 2.0

Cara aplikasi Anda menerima respons otorisasi bergantung pada...skema URI pengalihan yang digunakannya. Terlepas dari skemanya, respons akan berisi kode otorisasi (code) atau error (error). Misalnya, error=access_denied menunjukkan bahwa pengguna menolak permintaan.

Jika pengguna memberikan akses ke aplikasi Anda, Anda dapat menukarkan kode otorisasi dengan token akses dan token penyegaran seperti yang dijelaskan pada langkah berikutnya.

Langkah 5: Tukarkan kode otorisasi dengan token penyegaran dan akses

Untuk menukarkan kode otorisasi dengan token akses, panggil endpoint https://oauth2.googleapis.com/token dan atur parameter berikut:

Kolom
client_id	ID klien diperoleh dari Cloud Console Clients page.
client_secret	Opsional Rahasia klien diperoleh dari Cloud Console Clients page.
code	Kode otorisasi yang dikembalikan dari permintaan awal.
code_verifier	Verifikator kode yang Anda buat di Langkah 1.
grant_type	Sebagaimana didefinisikan dalam spesifikasi OAuth 2.0, nilai bidang ini harus diatur ke authorization_code.
redirect_uri	Salah satu URI pengalihan yang tercantum untuk proyek Anda di Cloud Console Clients page untuk client_id yang diberikan.

Cuplikan berikut menunjukkan contoh permintaan:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google menanggapi permintaan ini dengan mengembalikan objek JSON yang berisi token akses berumur pendek dan token penyegaran.

Respons tersebut berisi kolom-kolom berikut:

Kolom
access_token	Token yang dikirimkan aplikasi Anda untuk mengotorisasi permintaan API Google.
expires_in	Sisa masa berlaku token akses dalam detik.
id_token	Catatan: Properti ini hanya dikembalikan jika permintaan Anda menyertakan cakupan identitas, seperti openid, profile, atau email. Nilai tersebut adalah JSON Web Token (JWT) yang berisi informasi identitas pengguna yang ditandatangani secara digital.
refresh_token	Token yang dapat Anda gunakan untuk mendapatkan token akses baru. Token penyegaran berlaku hingga pengguna mencabut akses atau token penyegaran kedaluwarsa. Perlu dicatat bahwa token penyegaran selalu dikembalikan untuk aplikasi yang terinstal.
refresh_token_expires_in	Sisa masa berlaku refresh token dalam detik. Nilai ini hanya diatur ketika pengguna memberikan akses berdasarkan waktu .
scope	Lingkup akses yang diberikan oleh access_token dinyatakan sebagai daftar string yang dipisahkan spasi dan peka huruf besar/kecil.
token_type	Jenis token yang dikembalikan. Saat ini, nilai field ini selalu diatur ke Bearer.

Penting: Aplikasi Anda harus menyimpan kedua token tersebut di lokasi yang aman dan tahan lama, serta dapat diakses di antara berbagai pemanggilan aplikasi Anda. Refresh token memungkinkan aplikasi Anda untuk mendapatkan access token baru jika access token yang Anda miliki telah kedaluwarsa. Oleh karena itu, jika aplikasi Anda kehilangan token penyegaran (refresh token), pengguna perlu mengulangi alur persetujuan OAuth 2.0 agar aplikasi Anda dapat memperoleh token penyegaran yang baru.

Cuplikan berikut menunjukkan contoh respons:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Catatan: Aplikasi Anda harus mengabaikan bidang yang tidak dikenali yang termasuk dalam respons.

Langkah 6: Periksa cakupan apa saja yang telah diberikan kepada pengguna.

Saat meminta beberapa izin (cakupan), pengguna mungkin tidak memberikan akses aplikasi Anda ke semua izin tersebut. Aplikasi Anda harus memverifikasi cakupan mana yang sebenarnya diberikan dan menangani situasi di mana beberapa izin ditolak dengan baik, biasanya dengan menonaktifkan fitur yang bergantung pada cakupan yang ditolak tersebut.

Namun, ada pengecualian. Aplikasi Google Workspace Enterprise dengan delegasi wewenang di seluruh domain, atau aplikasi yang ditandai sebagai Tepercaya, melewati layar persetujuan izin yang lebih rinci. Untuk aplikasi-aplikasi ini, pengguna tidak akan melihat layar persetujuan izin yang lebih rinci. Sebaliknya, aplikasi Anda akan menerima semua cakupan yang diminta atau tidak sama sekali.

Untuk informasi lebih rinci, lihat Cara menangani izin granular.

Untuk memeriksa apakah pengguna telah memberikan akses aplikasi Anda ke cakupan tertentu, periksa kolom scope pada respons token akses. Cakupan akses yang diberikan oleh access_token dinyatakan sebagai daftar string yang dipisahkan spasi dan peka terhadap huruf besar/kecil.

Sebagai contoh, respons token akses berikut menunjukkan bahwa pengguna telah memberikan akses kepada aplikasi Anda untuk aktivitas Drive dan acara Kalender yang hanya dapat dibaca:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Memanggil Google API

Setelah aplikasi Anda memperoleh token akses, Anda dapat menggunakan token tersebut untuk melakukan panggilan ke API Google atas nama akun pengguna tertentu jika cakupan akses yang dibutuhkan oleh API telah diberikan. Untuk melakukan ini, sertakan token akses dalam permintaan ke API dengan menyertakan parameter kueri access_token atau nilai header HTTP Authorization Bearer. Jika memungkinkan, header HTTP lebih disukai, karena string kueri cenderung terlihat di log server. Dalam kebanyakan kasus, Anda dapat menggunakan pustaka klien untuk mengatur panggilan Anda ke API Google (misalnya, saat memanggil API Analitik YouTube).

Perlu dicatat bahwa API YouTube Analytics tidak mendukung alur akun layanan. API Pelaporan YouTube hanya mendukung akun layanan untuk pemilik konten YouTube yang memiliki dan mengelola beberapa saluran YouTube, seperti label rekaman dan studio film.

Anda dapat mencoba semua API Google dan melihat cakupannya di OAuth 2.0 Playground.

Contoh HTTP GET

Seruan kepada reports.query titik akhir (API Analitik YouTube) menggunakanAuthorization: Bearer Header HTTP mungkin terlihat seperti berikut. Perhatikan bahwa Anda perlu menentukan token akses Anda sendiri:

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Berikut adalah panggilan ke API yang sama untuk pengguna yang telah diautentikasi menggunakan parameter string kueri access_token:

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

Contoh curl

Anda dapat menguji perintah-perintah ini dengan aplikasi baris perintah curl. Berikut contoh yang menggunakan opsi header HTTP (lebih disukai):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

Atau, sebagai alternatif, opsi parameter string kueri:

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

Perbarui token akses

Token akses secara berkala kedaluwarsa dan menjadi kredensial yang tidak valid untuk permintaan API terkait. Anda dapat memperbarui token akses tanpa meminta izin pengguna (termasuk saat pengguna tidak hadir) jika Anda meminta akses offline ke cakupan yang terkait dengan token tersebut.

Untuk memperbarui token akses, aplikasi Anda mengirimkan permintaan HTTPS POST ke server otorisasi Google (https://oauth2.googleapis.com/token) yang mencakup parameter berikut:

Kolom
client_id	ID klien diperoleh dari API Console.
client_secret	Opsional Rahasia klien diperoleh dari API Console. (Angka client_secret tidak berlaku untuk permintaan dari klien yang terdaftar sebagai aplikasi Android, iOS, atau Chrome.)
grant_type	Sebagaimana didefinisikan dalam spesifikasi OAuth 2.0, nilai bidang ini harus diatur ke refresh_token.
refresh_token	Token penyegaran yang dikembalikan dari pertukaran kode otorisasi.

Cuplikan berikut menunjukkan contoh permintaan:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Selama pengguna belum mencabut akses yang diberikan ke aplikasi, server token akan mengembalikan objek JSON yang berisi token akses baru. Cuplikan berikut menunjukkan contoh respons:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Perlu diperhatikan bahwa ada batasan jumlah token penyegaran yang akan diterbitkan; satu batasan per kombinasi klien/pengguna, dan satu batasan lagi per pengguna di semua klien. Anda sebaiknya menyimpan token penyegaran di penyimpanan jangka panjang dan terus menggunakannya selama token tersebut masih valid. Jika aplikasi Anda meminta terlalu banyak token penyegaran, aplikasi tersebut mungkin akan menemui batasan ini, dalam hal ini token penyegaran yang lebih lama akan berhenti berfungsi.

Pencabutan token

Dalam beberapa kasus, pengguna mungkin ingin mencabut akses yang diberikan ke suatu aplikasi. Pengguna dapat mencabut akses dengan mengunjungi Pengaturan Akun. Lihat bagian Hapus akses situs atau aplikasi pada dokumen dukungan Situs & aplikasi pihak ketiga yang memiliki akses ke akun Anda untuk informasi selengkapnya.

Aplikasi juga dapat mencabut akses yang diberikan kepadanya secara terprogram. Pencabutan secara terprogram penting dalam kasus-kasus di mana pengguna berhenti berlangganan, menghapus aplikasi, atau sumber daya API yang dibutuhkan oleh aplikasi telah berubah secara signifikan. Dengan kata lain, bagian dari proses penghapusan dapat mencakup permintaan API untuk memastikan izin yang sebelumnya diberikan kepada aplikasi telah dihapus.

Untuk mencabut token secara terprogram, aplikasi Anda membuat permintaan ke https://oauth2.googleapis.com/revoke dan menyertakan token sebagai parameter:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Token tersebut dapat berupa token akses atau token penyegaran. Jika token tersebut adalah token akses dan memiliki token penyegaran yang sesuai, maka token penyegaran tersebut juga akan dicabut.

Jika pencabutan berhasil diproses, maka kode status HTTP dari respons adalah 200. Untuk kondisi error, kode status HTTP 400 dikembalikan bersama dengan kode error.

Poin Penting: Pencabutan menghapus semua cakupan OAuth 2.0 yang sebelumnya diberikan kepada suatu proyek, sehingga membatalkan token akses atau token penyegaran yang diterbitkan untuk semua klien yang terdaftar di bawah proyek tersebut.

Catatan: Setelah respons pencabutan berhasil, mungkin diperlukan beberapa waktu sebelum pencabutan tersebut berlaku sepenuhnya.

Metode pengalihan aplikasi

Skema URI khusus

Skema URI kustom adalah bentuk deeplinking yang menggunakan skema yang ditentukan sendiri untuk membuka aplikasi Anda.

Penting: Skema URI kustom tidak lagi didukung karena risiko peniruan identitas aplikasi.

Alternatif untuk menggunakan skema URI khusus pada aplikasi Chrome.

Gunakan Chrome Identity API yang mengirimkan respons OAuth 2.0 langsung ke aplikasi Anda, sehingga menghilangkan kebutuhan akan URI pengalihan.

Alamat IP loopback (macOS, Linux, desktop Windows)

Penting: Opsi pengalihan alamat IP loopback TIDAK DIGUNAKAN LAGI untuk tipe klien OAuth Android, aplikasi Chrome dan iOS. Tinjau panduan migrasi alamat IP loopback untuk petunjuk tentang cara bermigrasi ke alternatif yang didukung.

Untuk menerima kode otorisasi menggunakan URL ini, aplikasi Anda harus berjalan di server web lokal. Hal itu dimungkinkan di banyak platform, tetapi tidak semua. Namun, jika platform Anda mendukungnya, ini adalah mekanisme yang direkomendasikan untuk mendapatkan kode otorisasi.

Saat aplikasi Anda menerima respons otorisasi, untuk kemudahan penggunaan, aplikasi tersebut harus menampilkan halaman HTML yang menginstruksikan pengguna untuk menutup browser dan kembali ke aplikasi Anda.

Penggunaan yang disarankan	Aplikasi desktop macOS, Linux, dan Windows (tetapi bukan Universal Windows Platform)
Nilai formulir	Atur tipe aplikasi menjadi Aplikasi desktop.

Catatan: Lihatredirect_uri Definisi parameter untuk informasi lebih lanjut tentang alamat IP loopback. Dimungkinkan juga untuk menggunakan localhost sebagai pengganti IP loopback, tetapi konfigurasi ini dapat menyebabkan masalah dengan firewall klien. Sebagian besar, tetapi tidak semua, firewall mengizinkan komunikasi loopback.

Salin/tempel manual (Tidak digunakan lagi)

Penting: Opsi salin/tempel manual, yang juga disebut sebagai metode pengalihan di luar jalur (OOB), tidak lagi didukung. Tinjau Panduan migrasi OOB untuk petunjuk tentang cara bermigrasi ke alternatif yang aman.

Lindungi aplikasi Anda

Verifikasi kepemilikan aplikasi untuk Chrome

Anda dapat memverifikasi kepemilikan aplikasi Anda untuk mengurangi risiko peniruan identitas aplikasi.

Untuk menyelesaikan proses verifikasi, Anda dapat menggunakan akun Pengembang Chrome Web Store Anda. Persyaratan berikut harus dipenuhi agar verifikasi berhasil:

• Anda harus memiliki item terdaftar di Dasbor Pengembang Chrome Web Store dengan ID item yang sama dengan klien OAuth Ekstensi Chrome yang Anda gunakan untuk menyelesaikan verifikasi.
• Anda harus menjadi penerbit untuk item di Chrome Web Store. Pelajari selengkapnya tentang manajemen akses di Dasbor Pengembang Chrome Web Store.

Di bagian Verifikasi Kepemilikan Aplikasi pada klien Ekstensi Chrome, klik tombol Verifikasi Kepemilikan untuk menyelesaikan proses verifikasi.

Catatan: Tunggu beberapa menit sebelum menyelesaikan proses verifikasi setelah memberikan akses ke akun Anda.

Jika verifikasi berhasil, pemberitahuan akan ditampilkan untuk mengkonfirmasi keberhasilan proses verifikasi. Jika tidak, pesan kesalahan akan ditampilkan.

Untuk memperbaiki verifikasi yang gagal, coba langkah-langkah berikut:

• Pastikan terdapat item terdaftar di Dasbor Pengembang Chrome Web Store dengan ID item yang sama dengan klien OAuth Ekstensi Chrome yang sedang Anda verifikasi.
• Pastikan Anda adalah penerbit aplikasi tersebut, yaitu, Anda harus menjadi penerbit individu aplikasi atau anggota grup penerbit aplikasi tersebut. Pelajari selengkapnya tentang manajemen akses di Dasbor Pengembang Chrome Web Store.
• Jika Anda baru saja memperbarui daftar penerbit grup Anda, verifikasi bahwa daftar keanggotaan penerbit grup telah disinkronkan di Dasbor Pengembang Chrome Web Store. Pelajari selengkapnya tentang sinkronisasi daftar keanggotaan penerbit Anda.

Pemeriksaan Aplikasi (khusus iOS)

Fitur App Check membantu melindungi aplikasi iOS Anda dari penggunaan yang tidak sah dengan menggunakan layanan App Attest Apple untuk memverifikasi bahwa permintaan yang dibuat ke titik akhir Google OAuth 2.0 berasal dari aplikasi Anda yang sah. Hal ini membantu mengurangi risiko peniruan identitas aplikasi.

Aktifkan Pemeriksaan Aplikasi untuk Klien iOS Anda

Persyaratan berikut harus dipenuhi agar App Check dapat diaktifkan untuk klien iOS Anda dengan sukses:

• Anda harus menentukan ID tim untuk klien iOS Anda.
• Anda tidak boleh menggunakan karakter wildcard dalam ID bundel Anda karena dapat mengarah ke lebih dari satu aplikasi. Ini berarti bahwa ID bundel tidak boleh menyertakan simbol asterisk (*).

Peringatan: Saat Pemeriksaan Aplikasi diaktifkan, Anda tidak akan dapat mengedit ID bundel klien OAuth Anda tanpa membuat klien baru. Sebelum membuat klien iOS Anda atau mengaktifkan Pemeriksaan Aplikasi, pastikan Anda menggunakan ID bundel yang benar. Memperbarui ID bundel untuk proyek yang sudah ada dapat mengakibatkan pengalaman yang buruk bagi pengguna aplikasi Anda jika Anda menggunakan ID bundel sebagai URI pengalihan.

Untuk mengaktifkan App Check, aktifkan tombol toggle Lindungi klien OAuth Anda dari penyalahgunaan dengan Firebase App Check di tampilan edit klien iOS Anda.

Setelah mengaktifkan Pemeriksaan Aplikasi, Anda akan mulai melihat metrik terkait permintaan OAuth dari klien Anda di tampilan edit klien OAuth. Permintaan dari sumber yang tidak terverifikasi tidak akan diblokir sampai Anda menerapkan Pemeriksaan Aplikasi. Informasi di halaman pemantauan metrik dapat membantu Anda menentukan kapan harus memulai penegakan aturan.

Anda mungkin melihat kesalahan terkait fitur Pemeriksaan Aplikasi saat mengaktifkan Pemeriksaan Aplikasi untuk aplikasi iOS Anda. Untuk memperbaiki kesalahan ini, coba langkah-langkah berikut:

• Pastikan bahwa ID bundel dan ID tim yang Anda tentukan valid.
• Pastikan Anda tidak menggunakan karakter wildcard untuk ID bundel.

Terapkan Pemeriksaan Aplikasi untuk Klien iOS Anda

Mengaktifkan Pemeriksaan Aplikasi untuk aplikasi Anda tidak secara otomatis memblokir permintaan yang tidak dikenal. Untuk mengaktifkan perlindungan ini, buka tampilan edit aplikasi iOS Anda. Di sana, Anda akan melihat metrik Pemeriksaan Aplikasi di sebelah kanan halaman di bawah bagian Google Identity for iOS. Metrik tersebut mencakup informasi berikut:

• Jumlah permintaan terverifikasi - permintaan yang memiliki token Pemeriksaan Aplikasi yang valid. Setelah Anda mengaktifkan penegakan Pemeriksaan Aplikasi, hanya permintaan dalam kategori ini yang akan berhasil.
• Jumlah permintaan yang belum diverifikasi: kemungkinan permintaan klien yang sudah usang - permintaan yang tidak memiliki token Pemeriksaan Aplikasi; permintaan ini mungkin berasal dari versi aplikasi Anda yang lebih lama yang tidak menyertakan implementasi Pemeriksaan Aplikasi.
• Jumlah permintaan yang belum diverifikasi: permintaan asal tidak dikenal - permintaan yang tidak memiliki token Pemeriksaan Aplikasi dan tampaknya bukan berasal dari aplikasi Anda.
• Jumlah permintaan yang belum diverifikasi: permintaan tidak valid - permintaan dengan token Pemeriksaan Aplikasi yang tidak valid, yang mungkin berasal dari klien tidak otentik yang mencoba meniru aplikasi Anda, atau dari lingkungan yang diemulasi.

Tinjau metrik ini untuk memahami bagaimana penerapan Pemeriksaan Aplikasi akan memengaruhi pengguna Anda.

Untuk memberlakukan Pemeriksaan Aplikasi, klik tombol ENFORCE dan konfirmasikan pilihan Anda. Setelah penegakan aturan diaktifkan, semua permintaan yang belum diverifikasi dari klien Anda akan ditolak.

Catatan: setelah Anda mengaktifkan penegakan, perubahan mungkin membutuhkan waktu hingga 15 menit untuk berlaku.

Nonaktifkan Pemeriksaan Aplikasi untuk Klien iOS Anda

Dengan menonaktifkan App Check untuk aplikasi Anda, penegakan akan berhenti dan semua permintaan dari klien Anda ke endpoint Google OAuth 2.0 akan diizinkan, termasuk permintaan yang belum diverifikasi.

Untuk menonaktifkan Pemeriksaan Aplikasi untuk klien iOS Anda, navigasikan ke tampilan edit klien iOS dan klik tombol UNENFORCE lalu konfirmasikan pilihan Anda.

Catatan: setelah menonaktifkan Pemeriksaan Aplikasi, perubahan mungkin membutuhkan waktu hingga 15 menit untuk berlaku.

Nonaktifkan Pemeriksaan Aplikasi untuk Klien iOS Anda

Menonaktifkan Pemeriksaan Aplikasi untuk aplikasi Anda akan menghentikan semua pemantauan Pemeriksaan Aplikasi danpelaksanaan. Pertimbangkan untuk menggunakan unenforcing App Check agar Anda dapat terus memantau metrik untuk klien Anda.

Untuk menonaktifkan App Check untuk klien iOS Anda, navigasikan ke tampilan edit klien iOS dan matikan tombol toggle Lindungi klien OAuth Anda dari penyalahgunaan dengan Firebase App Check.

Catatan: setelah menonaktifkan Pemeriksaan Aplikasi, perubahan mungkin membutuhkan waktu hingga 15 menit untuk berlaku.

Akses berdasarkan waktu

Akses berbasis waktu memungkinkan pengguna untuk memberikan akses aplikasi Anda ke data mereka untuk durasi terbatas guna menyelesaikan suatu tindakan. Akses berbasis waktu tersedia di produk Google tertentu selama proses persetujuan, memberikan pengguna pilihan untuk memberikan akses untuk jangka waktu terbatas. Salah satu contohnya adalah Data Portability API yang memungkinkan transfer data satu kali.

Saat pengguna memberikan akses berbasis waktu kepada aplikasi Anda, token penyegaran akan kedaluwarsa setelah durasi yang ditentukan. Perhatikan bahwa token penyegaran dapat dibatalkan lebih awal dalam keadaan tertentu; lihat kasus-kasus ini untuk detailnya. Kolom refresh_token_expires_in yang dikembalikan dalam respons pertukaran kode otorisasi mewakili waktu yang tersisa hingga token penyegaran kedaluwarsa dalam kasus tersebut.

Bacaan Lebih Lanjut

Pedoman Praktik Terbaik Saat Ini IETF OAuth 2.0 untuk Aplikasi Asli menetapkan banyak praktik terbaik yang didokumentasikan di sini.

Terapkan Perlindungan Lintas Akun

Langkah tambahan yang harus Anda ambil untuk melindungi akun pengguna Anda adalah menerapkan Perlindungan Lintas Akun dengan menggunakan Layanan Perlindungan Lintas Akun Google. Layanan ini memungkinkan Anda berlangganan notifikasi peristiwa keamanan yang memberikan informasi kepada aplikasi Anda tentang perubahan besar pada akun pengguna. Anda kemudian dapat menggunakan informasi tersebut untuk mengambil tindakan tergantung pada bagaimana Anda memutuskan untuk menanggapi peristiwa tersebut.

Beberapa contoh jenis peristiwa yang dikirimkan ke aplikasi Anda oleh Layanan Perlindungan Lintas Akun Google adalah:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

Lihat halaman Lindungi akun pengguna dengan Perlindungan Lintas Akun untuk informasi lebih lanjut tentang cara menerapkan Perlindungan Lintas Akun dan untuk daftar lengkap peristiwa yang tersedia.