Dokumen ini menjelaskan cara menerapkan otorisasi OAuth 2.0 untuk mengakses YouTube Data API melalui aplikasi yang berjalan di perangkat seperti TV, konsol game, dan {i>printer<i}. Lebih spesifiknya, alur ini didesain untuk perangkat yang tidak memiliki akses ke browser atau memiliki kemampuan input yang terbatas.
OAuth 2.0 memungkinkan pengguna untuk berbagi data tertentu dengan aplikasi sambil tetap mempertahankan nama pengguna, {i>password<i}, dan informasi lainnya secara rahasia. Misalnya, sebuah aplikasi TV bisa menggunakan OAuth 2.0 untuk mendapatkan izin untuk pilih file yang disimpan di Google Drive.
Karena aplikasi yang menggunakan aliran ini didistribusikan ke perangkat individu, maka berasumsi bahwa aplikasi tidak dapat menyimpan rahasia. Mereka dapat mengakses Google API saat pengguna ada di aplikasi atau saat aplikasi berjalan di latar belakang.
Alternatif
Jika Anda menulis aplikasi untuk platform seperti Android, iOS, macOS, Linux, atau Windows (termasuk Universal Windows Platform), yang memiliki akses ke browser dan input penuh gunakan alur OAuth 2.0 untuk seluler dan aplikasi desktop. (Anda harus menggunakan alur tersebut meskipun aplikasi Anda adalah command line tanpa antarmuka grafis).
Jika Anda hanya ingin memproses login pengguna dengan Akun Google mereka dan menggunakan token ID JWT untuk mendapatkan informasi dasar profil pengguna, lihat 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 project Anda:
- Open the API Library di Google API Console.
- If prompted, select a project, or create a new one.
- Gunakan halaman Koleksi untuk menemukan dan mengaktifkan YouTube Data API. Temukan API lain yang akan digunakan aplikasi Anda dan aktifkan juga API tersebut.
Membuat kredensial otorisasi
Aplikasi apa pun 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. Selanjutnya, aplikasi Anda dapat menggunakan kredensial tersebut untuk mengakses API yang telah Anda aktifkan untuk project tersebut.
- Go to the Credentials page.
- Klik Create credentials > Client ID OAuth yang baru.
- Pilih jenis aplikasi TVs and Limited Input devices.
- Beri nama klien OAuth 2.0 Anda, lalu klik Create.
Mengidentifikasi cakupan akses
Dengan cakupan, aplikasi Anda dapat hanya meminta akses ke resource yang diperlukannya sekaligus memungkinkan pengguna untuk mengontrol jumlah akses yang mereka berikan ke aplikasi Anda. Oleh karena itu, mungkin merupakan hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan mendapatkan izin pengguna.
Sebelum mulai menerapkan otorisasi OAuth 2.0, sebaiknya Anda mengidentifikasi cakupan aplikasi Anda memerlukan izin untuk mengaksesnya.
YouTube Data API v3 menggunakan cakupan berikut:
| Teropong senjata api | |
|---|---|
| https://www.googleapis.com/auth/youtube | Mengelola akun YouTube Anda |
| https://www.googleapis.com/auth/youtube.channel-memberships.creator | Melihat daftar pelanggan yang saat ini aktif di channel Anda, level mereka saat ini, dan kapan mereka menjadi pelanggan |
| https://www.googleapis.com/auth/youtube.force-ssl | Melihat, mengedit, dan secara permanen menghapus video, rating, komentar, dan teks YouTube |
| https://www.googleapis.com/auth/youtube.readonly | Melihat akun YouTube Anda |
| https://www.googleapis.com/auth/youtube.upload | Mengelola video YouTube Anda |
| https://www.googleapis.com/auth/youtubepartner | Melihat dan mengelola aset Anda dan konten terkait di YouTube |
| https://www.googleapis.com/auth/youtubepartner-channel-audit | Melihat informasi pribadi channel YouTube Anda yang relevan selama proses audit bersama partner YouTube |
Lihat daftar Cakupan yang diizinkan untuk aplikasi atau perangkat terinstal.
Mendapatkan token akses OAuth 2.0
Meskipun aplikasi Anda berjalan pada perangkat dengan kemampuan input yang terbatas, pengguna harus memiliki akses terpisah ke perangkat yang memiliki kemampuan input yang lebih lengkap untuk menyelesaikan alur otorisasi ini. Alurnya memiliki langkah-langkah berikut:
- Aplikasi Anda mengirimkan permintaan ke server otorisasi Google yang mengidentifikasi cakupan aplikasi Anda akan meminta izin aksesnya.
- Server merespons dengan beberapa informasi yang digunakan dalam langkah berikutnya, seperti kode perangkat dan kode pengguna.
- Anda menampilkan informasi yang dapat dimasukkan pengguna pada perangkat terpisah untuk memberikan otorisasi .
- Aplikasi Anda mulai memeriksa server otorisasi Google untuk menentukan apakah pengguna telah memberi otorisasi pada aplikasi Anda.
- Pengguna beralih ke perangkat yang memiliki kemampuan input yang lebih lengkap, meluncurkan {i>browser<i} web, membuka URL yang ditampilkan di langkah 3 dan memasukkan kode yang juga ditampilkan di langkah 3. Tujuan selanjutnya pengguna dapat memberikan (atau menolak) akses ke aplikasi Anda.
- Respons berikutnya terhadap permintaan polling Anda berisi token yang perlu diotorisasi oleh aplikasi Anda permintaan atas nama pengguna. (Jika pengguna menolak akses ke aplikasi Anda, respons tidak berisi token.)
Gambar di bawah mengilustrasikan proses ini:
Bagian berikut menjelaskan langkah-langkah ini secara mendetail. Dengan mempertimbangkan rentang kemampuan dan runtime
yang mungkin dimiliki perangkat, contoh yang ditampilkan dalam dokumen ini menggunakan metode curl
utilitas command line. Contoh ini harus mudah ditransfer ke berbagai bahasa dan runtime.
Langkah 1: Minta kode perangkat dan pengguna
Pada langkah ini, perangkat Anda mengirimkan permintaan POST HTTP ke server otorisasi Google, di
https://oauth2.googleapis.com/device/code, yang mengidentifikasi aplikasi Anda
serta cakupan akses yang ingin
diakses aplikasi Anda atas nama pengguna.
Anda harus mengambil URL ini dari bagian
Dokumen penemuan menggunakan
Nilai metadata device_authorization_endpoint. Sertakan permintaan HTTP berikut
parameter:
| Parameter | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Wajib
Client ID untuk aplikasi Anda. Anda dapat menemukan nilai ini di kolom API Console Credentials page. |
||||||||||||||||
scope |
Wajib
J dipisahkan spasi daftar cakupan yang mengidentifikasi sumber daya yang dapat diakses aplikasi Anda di atas nama pengguna. Nilai ini memberi tahu layar izin yang ditampilkan Google kepada . Lihat Daftar cakupan yang diizinkan untuk aplikasi atau perangkat terinstal. Dengan cakupan, aplikasi Anda dapat hanya meminta akses ke resource yang diperlukan sekaligus memungkinkan pengguna mengontrol jumlah akses yang mereka berikan kepada Anda aplikasi. Jadi, ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan untuk mendapatkan izin pengguna. YouTube Data API v3 menggunakan cakupan berikut:
Dokumen Cakupan OAuth 2.0 API memberikan daftar lengkap cakupan yang dapat Anda gunakan untuk mengakses Google API. |
||||||||||||||||
Contoh
Cuplikan berikut menunjukkan contoh permintaan:
POST /device/code HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl
Contoh ini menunjukkan perintah curl untuk mengirim permintaan yang sama:
curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
https://oauth2.googleapis.com/device/code
Langkah 2: Tangani respons server otorisasi
Server otorisasi akan menampilkan salah satu respons berikut:
Respons berhasil
Jika permintaan valid, respons Anda akan berupa objek JSON yang berisi hal berikut properti:
| Properti | |
|---|---|
device_code |
Nilai yang ditetapkan secara unik oleh Google untuk mengidentifikasi perangkat yang menjalankan permintaan aplikasi
otorisasi. Pengguna akan memberi otorisasi pada perangkat tersebut dari perangkat lain dengan kode
kapabilitas input teks. Misalnya, pengguna mungkin menggunakan laptop atau ponsel untuk mengotorisasi
yang berjalan di TV. Dalam hal ini, device_code mengidentifikasi TV.
Kode ini memungkinkan perangkat yang menjalankan aplikasi dengan aman menentukan apakah pengguna telah memberikan izin atau ditolak aksesnya. |
expires_in |
Durasi waktu, dalam detik, saat device_code dan
user_code valid. Jika, pada saat itu, pengguna tidak menyelesaikan
dan perangkat Anda juga tidak mencari informasi untuk
mengambil informasi tentang
keputusan pengguna, Anda mungkin perlu
memulai ulang proses ini dari langkah 1. |
interval |
Durasi waktu, dalam detik, saat perangkat Anda harus menunggu di antara permintaan polling. Sebagai
misalnya, jika nilainya 5, perangkat Anda harus mengirim permintaan polling ke
Server otorisasi Google setiap lima detik. Lihat
langkah 3 untuk detail selengkapnya. |
user_code |
Nilai yang peka huruf besar/kecil yang mengidentifikasi kepada Google cakupan aplikasi yang akses. Antarmuka pengguna Anda akan menginstruksikan pengguna untuk memasukkan nilai ini pada perangkat terpisah dengan kemampuan input yang lebih kaya. Google kemudian menggunakan nilai tersebut untuk menampilkan cakupan yang benar saat meminta pengguna memberikan akses ke aplikasi Anda. |
verification_url |
URL yang harus dibuka oleh pengguna, pada perangkat terpisah, untuk memasukkan
user_code dan berikan atau tolak akses ke aplikasi Anda. Antarmuka pengguna Anda
juga akan menampilkan nilai ini. |
Cuplikan berikut menunjukkan contoh respons:
{
"device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
"user_code": "GQVQ-JKEC",
"verification_url": "https://www.google.com/device",
"expires_in": 1800,
"interval": 5
}
Respons kuota terlampaui
Jika permintaan kode perangkat Anda telah melampaui kuota yang dikaitkan dengan client ID, Anda akan menerima respons 403, yang berisi error berikut:
{
"error_code": "rate_limit_exceeded"
}
Dalam hal ini, gunakan strategi backoff untuk mengurangi rasio permintaan.
Langkah 3: Tampilkan kode pengguna
Tampilkan verification_url dan user_code yang diperoleh di langkah 2 ke
. Kedua nilai dapat berisi karakter apa pun yang dapat dicetak dari himpunan karakter US-ASCII. Konten
yang Anda tampilkan kepada pengguna harus menginstruksikan pengguna untuk menuju
verification_url di perangkat terpisah, lalu masukkan user_code.
Desain antarmuka pengguna (UI) Anda dengan mempertimbangkan aturan berikut:
user_codeuser_codeharus ditampilkan di kolom yang dapat menangani 15 'W' ukuran karakter. Dengan kata lain, jika Anda dapat menampilkan kodeWWWWWWWWWWWWWWWdengan benar, UI Anda valid, dan kami sarankan untuk menggunakan nilai string tersebut saat menguji carauser_codeakan ditampilkan di UI Anda.user_codepeka huruf besar/kecil dan tidak boleh dimodifikasi dengan cara apa pun, seperti seperti mengubah huruf besar/kecil atau memasukkan karakter pemformatan lain.
verification_url- Ruang tempat Anda menampilkan
verification_urlharus cukup lebar untuk menangani {i>string<i} URL yang panjangnya 40 karakter. - Anda tidak boleh mengubah
verification_urldengan cara apa pun, kecuali jika Anda menghapus skema untuk ditampilkan. Jika Anda berencana mencabut skema itu (misalnya,https://) dari URL untuk alasan tampilan, pastikan aplikasi Anda dapat menangani varianhttpdanhttps.
- Ruang tempat Anda menampilkan
Langkah 4: Lakukan polling server otorisasi Google
Karena pengguna akan menggunakan perangkat terpisah untuk membuka verification_url
dan memberikan (atau menolak) akses, perangkat yang meminta tidak secara otomatis diberi tahu ketika pengguna
merespons permintaan akses. Oleh karena itu, perangkat yang meminta perlu memeriksa
server otorisasi untuk menentukan
kapan pengguna merespons permintaan.
Perangkat yang meminta harus terus mengirimkan permintaan polling hingga menerima respons
yang menunjukkan bahwa pengguna telah merespons permintaan akses atau hingga device_code
dan user_code diperoleh di
langkah 2 telah berakhir. interval yang ditampilkan di langkah 2 menentukan jumlah
waktu, dalam detik, untuk menunggu di antara permintaan.
URL endpoint untuk polling adalah https://oauth2.googleapis.com/token. Permintaan polling
berisi parameter berikut:
| Parameter | |
|---|---|
client_id |
Client ID untuk aplikasi Anda. Anda dapat menemukan nilai ini di kolom API Console Credentials page. |
client_secret |
Rahasia klien untuk client_id yang disediakan. Anda dapat menemukan nilai ini di kolom
API Console
Credentials page. |
device_code |
device_code yang ditampilkan oleh server otorisasi di
langkah 2. |
grant_type |
Tetapkan nilai ini ke urn:ietf:params:oauth:grant-type:device_code. |
Contoh
Cuplikan berikut menunjukkan contoh permintaan:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id& client_secret=client_secret& device_code=device_code& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
Contoh ini menunjukkan perintah curl untuk mengirim permintaan yang sama:
curl -d "client_id=client_id&client_secret=client_secret& \
device_code=device_code& \
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
-H "Content-Type: application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/token
Langkah 5: Pengguna merespons permintaan akses
Gambar berikut menampilkan halaman yang mirip dengan yang dilihat pengguna saat mereka membuka
verification_url yang Anda tampilkan di langkah 3:
Setelah memasukkan user_code dan, jika belum login, login ke Google,
pengguna akan melihat layar izin seperti yang ditunjukkan di bawah ini:
Langkah 6: Tangani respons terhadap permintaan polling
Server otorisasi Google merespons setiap permintaan polling dengan salah satu respons:
Akses diberikan
Jika pengguna memberikan akses ke perangkat (dengan mengklik Allow di layar izin),
respons tersebut berisi
token akses dan token pembaruan. Token memungkinkan perangkat Anda untuk
mengakses Google API atas nama pengguna. (scope
dalam respons menentukan API mana
yang dapat diakses perangkat.)
Dalam hal ini, respons API berisi kolom-kolom berikut:
| Kolom | |
|---|---|
access_token |
Token yang dikirimkan aplikasi Anda untuk mengizinkan permintaan Google API. |
expires_in |
Sisa masa pakai token akses dalam hitungan detik. |
refresh_token |
Token yang dapat digunakan untuk mendapatkan token akses baru. Token refresh berlaku hingga pengguna mencabut akses. Perhatikan bahwa token refresh selalu ditampilkan untuk perangkat. |
scope |
Cakupan akses yang diberikan oleh access_token yang dinyatakan sebagai daftar
{i>string<i} yang peka huruf besar/kecil dan dipisahkan spasi. |
token_type |
Jenis token yang ditampilkan. Saat ini, nilai bidang ini selalu disetel ke
Bearer. |
Cuplikan berikut menunjukkan contoh respons:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
"token_type": "Bearer",
"refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}
Token akses memiliki masa berlaku yang terbatas. Jika aplikasi Anda membutuhkan akses ke API dalam waktu tertentu, aplikasi dapat menggunakan token refresh untuk mendapatkan akses baru sebelumnya yang benar. Jika aplikasi Anda membutuhkan akses jenis ini, maka aplikasi itu harus menyimpan token pembaruan untuk digunakan nanti.
Akses ditolak
Jika pengguna menolak memberikan akses ke perangkat, respons server memiliki
Kode status respons HTTP 403 (Forbidden). Respons berisi
error berikut:
{
"error": "access_denied",
"error_description": "Forbidden"
}
Otorisasi tertunda
Jika pengguna belum menyelesaikan alur otorisasi, maka server akan mengembalikan
Kode status respons HTTP 428 (Precondition Required). Respons
berisi error berikut:
{
"error": "authorization_pending",
"error_description": "Precondition Required"
}
Polling terlalu sering
Jika perangkat terlalu sering mengirim permintaan polling, server akan menampilkan 403
Kode status respons HTTP (Forbidden). Respons berisi hal berikut
{i>error<i}:
{
"error": "slow_down",
"error_description": "Forbidden"
}
Error lainnya
Server otorisasi juga menampilkan error jika permintaan polling tidak memiliki
parameter atau memiliki nilai parameter yang salah. Permintaan ini biasanya memiliki 400
Status respons HTTP (Bad Request) atau 401 (Unauthorized)
pada kode sumber. Error tersebut mencakup:
| Error | Kode Status HTTP | Deskripsi |
|---|---|---|
admin_policy_enforced |
400 |
Akun Google tidak dapat memberikan otorisasi ke satu atau beberapa cakupan yang diminta karena kebijakan administrator Google Workspace mereka. Lihat bantuan Admin Google Workspace artikel Mengontrol layanan & aplikasi internal mengakses data Google Workspace untuk mendapatkan informasi selengkapnya tentang cara administrator dapat membatasi akses ke cakupan hingga akses diberikan secara eksplisit ke OAuth Anda dengan ID klien. |
invalid_client |
401 |
Klien OAuth tidak ditemukan. Misalnya, error ini terjadi jika
Nilai parameter Jenis klien OAuth salah. Pastikan bahwa jenis aplikasi untuk client ID disetel ke TV dan perangkat Input Terbatas. |
invalid_grant |
400 |
Nilai parameter code tidak valid, telah diklaim, atau tidak dapat
diuraikan. |
unsupported_grant_type |
400 |
Nilai parameter grant_type tidak valid. |
org_internal |
403 |
Client ID OAuth dalam permintaan adalah bagian dari project yang membatasi akses ke Akun Google secara spesifik Organisasi Google Cloud. Konfirmasi jenis pengguna untuk aplikasi OAuth Anda. |
Memanggil Google API
Setelah aplikasi Anda mendapatkan token akses, Anda bisa menggunakan token tersebut untuk melakukan panggilan ke
API atas nama objek
jika cakupan akses yang diperlukan oleh API telah diberikan. Untuk melakukannya, sertakan
token akses dalam permintaan ke API dengan menyertakan kueri access_token
atau nilai Bearer header HTTP Authorization. Jika memungkinkan,
header HTTP lebih disukai, karena string kueri cenderung terlihat di log server. Dalam sebagian besar
Anda dapat menggunakan library klien untuk menyiapkan panggilan ke Google API (misalnya, saat
memanggil YouTube Live Streaming API).
Perhatikan bahwa YouTube Live Streaming API tidak mendukung alur akun layanan. Karena ada
bukanlah cara untuk menautkan Akun Layanan ke akun YouTube, berupaya mengotorisasi permintaan dengan
alur akan menghasilkan error NoLinkedYouTubeAccount.
Anda dapat mencoba semua Google API dan melihat cakupannya di OAuth 2.0 Playground.
Contoh GET HTTP
Panggilan ke
liveBroadcasts.list
endpoint (YouTube Live Streaming API) menggunakan HTTP Authorization: Bearer
{i>header<i} akan terlihat seperti berikut. Perhatikan bahwa Anda perlu menentukan token akses Anda sendiri:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Berikut adalah panggilan ke API yang sama untuk pengguna terautentikasi menggunakan access_token
parameter string kueri:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Contoh curl
Anda dapat menguji perintah ini dengan aplikasi command line curl. Berikut adalah
contoh yang menggunakan opsi header HTTP (lebih disukai):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
Atau, sebagai alternatif, opsi parameter string kueri:
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Memperbarui token akses
Masa berlaku token akses habis secara berkala dan menjadi kredensial yang tidak valid untuk permintaan API terkait. Anda dapat memperbarui token akses tanpa meminta izin kepada pengguna (termasuk saat pengguna tidak ada) jika Anda meminta akses offline ke cakupan yang terkait dengan token.
Untuk memuat ulang token akses, aplikasi Anda mengirim POST HTTPS
permintaan ke server otorisasi Google (https://oauth2.googleapis.com/token) yang
mencakup parameter berikut:
| Kolom | |
|---|---|
client_id |
Client ID yang diperoleh dari API Console. |
client_secret |
Rahasia klien yang diperoleh dari API Console. |
grant_type |
Sebagai
yang didefinisikan dalam
Spesifikasi OAuth 2.0,
nilai kolom ini harus ditetapkan ke refresh_token. |
refresh_token |
Token refresh yang ditampilkan 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& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
Selama pengguna belum mencabut akses yang diberikan ke aplikasi, server token menampilkan objek JSON yang berisi token akses baru. Cuplikan berikut menampilkan contoh respons:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
Perhatikan bahwa ada batasan jumlah token refresh yang akan diterbitkan; satu batas per kombinasi klien/pengguna, dan satu lagi per pengguna di semua klien. Anda harus menyimpan token refresh dalam penyimpanan jangka panjang dan terus menggunakannya selama masih valid. Jika pengajuan permohonan Anda meminta terlalu banyak token refresh, mungkin akan mencapai batas ini, sehingga token refresh yang lebih lama akan berhenti berfungsi.
Mencabut token
Dalam beberapa kasus, pengguna mungkin ingin mencabut akses yang diberikan ke aplikasi. Pengguna dapat mencabut akses dengan mengunjungi Setelan Akun. Lihat Hapus bagian akses situs atau aplikasi di situs pihak ketiga & aplikasi yang memiliki akses ke akun Anda dokumen dukungan untuk informasi selengkapnya.
Aplikasi juga dapat mencabut akses yang diberikan kepadanya secara terprogram. Pencabutan terprogram penting jika pengguna berhenti berlangganan, menghapus aplikasi, atau sumber daya API yang dibutuhkan oleh aplikasi telah berubah secara signifikan. Dengan kata lain, {i>SUMIF<i} memiliki daftar sel bagian dari proses penghapusan dapat mencakup permintaan API untuk memastikan yang diberikan ke aplikasi akan 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 dapat berupa token akses atau token refresh. Jika token tersebut adalah token akses dan memiliki token pembaruan yang sesuai, token pembaruan juga akan dicabut.
Jika pencabutan berhasil diproses, kode status HTTP respons tersebut adalah
200. Untuk kondisi error, kode status HTTP 400 ditampilkan bersama
dengan kode error.
Cakupan yang diizinkan
Alur OAuth 2.0 untuk perangkat hanya didukung untuk cakupan berikut:
OpenID Connect, Login dengan Google
emailopenidprofile
API Drive
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
YouTube API
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly
Menerapkan Perlindungan Lintas Akun
Langkah tambahan yang harus Anda ambil untuk melindungi akun menerapkan Lintas Akun Perlindungan dengan menggunakan Layanan Perlindungan Lintas Akun Google. Layanan ini memungkinkan Anda berlangganan pemberitahuan peristiwa keamanan yang memberikan informasi ke aplikasi Anda tentang perubahan besar pada akun pengguna. Selanjutnya, Anda dapat menggunakan informasi tersebut untuk mengambil tindakan, bergantung pada bagaimana Anda memutuskan untuk menanggapi peristiwa.
Beberapa contoh jenis peristiwa yang dikirim ke aplikasi Anda oleh Cross-Account Protection Service 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 Melindungi akun pengguna dengan halaman Perlindungan Lintas Akun untuk mengetahui informasi selengkapnya tentang cara menerapkan Perlindungan Lintas Akun dan daftar lengkap peristiwa yang tersedia.