OAuth 2.0 untuk Aplikasi Desktop

Dokumen ini menjelaskan cara aplikasi desktop (seperti aplikasi yang berjalan di Windows, macOS, atau Linux, atau alat antarmuka command line (CLI)) menggunakan endpoint OAuth 2.0 Google untuk mengizinkan akses ke Google API.

OAuth 2.0 memungkinkan pengguna berbagi data tertentu dengan aplikasi sekaligus menjaga kerahasiaan nama pengguna, sandi, dan informasi lainnya. Misalnya, aplikasi dapat menggunakan OAuth 2.0 untuk mendapatkan izin dari pengguna untuk menyimpan file di Google Drive mereka.

Aplikasi desktop diinstal secara lokal di komputer pengguna (seperti software desktop mandiri, alat CLI developer, utilitas sinkronisasi latar belakang, atau skrip). Karena aplikasi ini didistribusikan ke perangkat individual, diasumsikan bahwa aplikasi ini tidak dapat menyimpan rahasia (aplikasi ini adalah klien publik). Mereka dapat mengakses Google API saat pengguna aktif berinteraksi dengan aplikasi atau saat aplikasi berjalan di latar belakang.

Alur otorisasi ini mirip dengan yang digunakan untuk aplikasi server web. Perbedaan utamanya adalah aplikasi desktop harus membuka browser sistem dan menyediakan URI pengalihan lokal (seperti alamat IP loopback) untuk menangani respons dari server otorisasi Google.

Library dan contoh

Sebaiknya gunakan Library Klien Google API untuk bahasa pemrograman Anda (misalnya, Python, Java, Node.js, Go, .NET) saat menerapkan OAuth 2.0 untuk aplikasi desktop. Library klien menangani otorisasi pengguna dan pengelolaan token, sehingga implementasi menjadi lebih sederhana dan tidak rentan terhadap error dibandingkan dengan menggunakan endpoint HTTP/REST level rendah secara langsung.

Untuk aplikasi seluler, lihat panduan otorisasi Android dan iOS.

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

Setiap aplikasi yang memanggil Google API harus mengaktifkan API tersebut di Konsol API.

Untuk mengaktifkan API untuk project Anda:

1. Buka Library API di Konsol API Google.
2. Jika diminta, pilih project, atau buat project baru.
3. Library API menampilkan daftar semua API yang tersedia, yang dikelompokkan berdasarkan kelompok produk dan popularitas. Jika API yang ingin Anda aktifkan tidak terlihat dalam daftar, gunakan penelusuran untuk menemukannya, atau klik View All di kelompok produk yang sesuai.
4. Pilih API yang ingin Anda aktifkan, lalu klik tombol Aktifkan.
5. Jika diminta, aktifkan penagihan.
6. Jika diminta, baca dan setujui Persyaratan Layanan API.

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. Kemudian, aplikasi Anda dapat menggunakan kredensial tersebut untuk mengakses API yang telah Anda aktifkan untuk project tersebut.

1. Buka halaman Klien.
2. Klik Buat klien.
3. Pilih jenis aplikasi aplikasi desktop.
4. Di kolom Name, masukkan nama untuk klien OAuth. Nama ini ditampilkan di halaman Klien project Anda untuk mengidentifikasi klien.
5. Klik Buat.

Client ID dan rahasia klien Anda akan dibuat dan ditampilkan di konsol Google Cloud. Aplikasi desktop adalah klien publik dan tidak dapat menjaga kerahasiaan rahasia. Selalu gunakan PKCE (Proof Key for Code Exchange) saat meminta kode otorisasi.

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 memperoleh izin pengguna.

Sebelum mulai menerapkan otorisasi OAuth 2.0, sebaiknya identifikasi cakupan yang memerlukan izin akses dari aplikasi Anda.

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

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 menjalankan permintaan Google API yang memerlukan otorisasi pengguna.

Langkah 1: Buat verifikasi kode dan tantangan

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

Membuat pemverifikasi kode

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

Pemverifikasi kode harus memiliki entropi yang cukup agar nilainya tidak dapat ditebak.

Membuat tantangan kode

Dua metode pembuatan tantangan kode didukung.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

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 mendapatkan izin pengguna. Endpoint hanya dapat diakses melalui SSL, dan menolak koneksi HTTP (non-SSL).

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

Contoh URL otorisasi

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

URL-nya identik, kecuali untuk nilai parameter redirect_uri. URL juga berisi parameter response_type dan client_id yang diperlukan serta parameter state opsional. Setiap URL berisi baris baru dan spasi agar lebih mudah dibaca.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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 izin pengguna

Pada langkah ini, pengguna memutuskan apakah akan memberikan akses yang diminta ke aplikasi Anda. Pada tahap ini, Google menampilkan jendela izin yang menunjukkan nama aplikasi Anda dan layanan Google API yang meminta izin untuk diakses dengan kredensial otorisasi pengguna dan ringkasan cakupan akses yang akan diberikan. Pengguna kemudian dapat mengizinkan untuk memberikan akses ke satu atau beberapa cakupan yang diminta oleh aplikasi Anda atau menolak permintaan tersebut.

Aplikasi Anda tidak perlu melakukan apa pun pada tahap ini karena aplikasi menunggu respons dari server OAuth 2.0 Google yang menunjukkan apakah akses diberikan. Respons tersebut dijelaskan di langkah berikut.

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 menukar kode otorisasi dengan token akses dan token refresh seperti yang dijelaskan pada langkah berikutnya.

Langkah 5: Tukarkan kode otorisasi dengan token refresh dan akses

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

Meskipun penggunaan DPoP bersifat opsional, sebaiknya gunakan untuk meningkatkan keamanan. Keamanan DPoP bergantung pada kunci pribadi yang dibatasi untuk satu perangkat; sebaiknya simpan kunci tersebut dengan cara yang tidak dapat disalin dari perangkat, misalnya dengan menggunakan TPM, Secure Enclave, atau keystore yang didukung hardware lainnya. Untuk menggunakan DPoP, aplikasi Anda harus membuat JWT bukti DPoP baru yang unik untuk setiap permintaan ke endpoint token dan menambahkannya sebagai header permintaan HTTP.

Cuplikan berikut menunjukkan contoh permintaan:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

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

Membuat bukti DPoP

Langkah-langkah berikut menunjukkan cara membuat bukti DPoP menggunakan OpenSSL dari command line:

1. Buat pasangan kunci EC P-256:

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. Buat header DPoP:

   Header harus menyertakan klaim typ, alg, dan jwk (kunci publik). Nilai x dan y adalah koordinat berenkode Base64Url dari kunci publik EC Anda. Enkode Base64Url JSON ini:

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. Buat payload DPoP:

   Payload harus menyertakan jti (ID unik untuk permintaan), htm (metode HTTP, misalnya, POST), htu (URI HTTP, misalnya, https://oauth2.googleapis.com/token), dan iat (diterbitkan pada waktu). Jika Anda menerima nonce dari server di header DPoP-Nonce pada respons terhadap permintaan sebelumnya, Anda harus menyertakan nilai nonce tersebut dalam klaim nonce. Klaim nonce bersifat opsional untuk pertukaran kode otorisasi dan hanya digunakan jika header DPoP-Nonce telah diterima sebelumnya. Enkode Base64Url JSON ini:

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   Nilai jti bergantung pada jenis pertukaran:

   • Untuk pertukaran kode otorisasi, jti harus berupa hash SHA256 berenkode Base64Url dari kode otorisasi: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
   • Untuk pertukaran token refresh, jti harus berupa ID unik per permintaan: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
4. Menandatangani bukti:

   Gabungkan header dan payload yang dienkode dengan titik (.), lalu tanda tangani hasilnya dengan kunci pribadi Anda menggunakan ES256. Perhatikan bahwa JWS mengharuskan tanda tangan dalam format R | S mentah yang digabungkan (64 byte untuk P-256). Jika menggunakan OpenSSL secara langsung, Anda harus mengonversi tanda tangan berenkode DER ASN.1 default ke format mentah ini.

Pertukaran yang berhasil ditunjukkan dengan respons 200 OK yang berisi token. Jika bukti DPoP yang valid digunakan selama pertukaran, token refresh yang ditampilkan Google akan terikat DPoP ke kunci Anda, tetapi token akses tidak akan terikat DPoP. Token akses akan mempertahankan token_type dari Bearer, bukan DPoP. Selain itu, Google menampilkan header HTTP DPoP-Nonce dalam respons. Klien Anda harus meng-cache nonce ini dan menyertakannya dalam klaim nonce dari bukti DPoP dalam permintaan berikutnya (seperti saat menukar token refresh dengan token akses baru, atau saat memanggil API yang dilindungi DPoP). Dengan menggunakan nonce yang dikeluarkan lebih awal ini, Anda dapat menghindari kegagalan round-trip tambahan (use_dpop_nonce) pada permintaan berikutnya.

Bukti DPoP harus disertakan untuk permintaan pertukaran token yang dibuat dengan token refresh yang terikat DPoP.

Pertukaran yang gagal terjadi jika header DPoP tidak ada saat diharapkan, tidak valid, atau jika bukti menggunakan kunci yang berbeda dengan kunci yang terikat ke token. Dalam kasus ini, server akan menampilkan error 400 Bad Request. Jika bukti DPoP memiliki klaim htm atau htu yang tidak cocok, iat yang sudah tidak berlaku, jti yang digunakan kembali, atau tanda tangan yang tidak valid, Google akan menampilkan kode error invalid_dpop_proof. Jika nonce DPoP diperlukan, seperti selama pertukaran token refresh, dan bukti DPoP tidak memiliki klaim nonce, atau nilai nonce tidak dapat diterima oleh server (misalnya, sudah tidak berlaku, sudah digunakan, atau salah), Google akan menampilkan kode error use_dpop_nonce beserta header HTTP DPoP-Nonce yang berisi nonce baru yang dapat Anda gunakan dalam permintaan berikutnya. Kegagalan lainnya mungkin menampilkan invalid_grant.

Google merespons permintaan ini dengan menampilkan objek JSON yang berisi token akses berumur pendek dan token refresh.

Respons berisi kolom berikut:

Cuplikan berikut menunjukkan contoh header respons dan isi yang berhasil saat DPoP digunakan:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

Langkah 6: Periksa cakupan yang diberikan pengguna

Saat meminta beberapa izin (cakupan), pengguna mungkin tidak memberikan akses ke semua izin tersebut kepada aplikasi Anda. Aplikasi Anda harus memverifikasi cakupan mana yang benar-benar diberikan dan menangani situasi saat beberapa izin ditolak dengan baik, biasanya dengan menonaktifkan fitur yang mengandalkan cakupan yang ditolak tersebut.

Namun, terdapat pengecualian. Aplikasi Google Workspace Enterprise dengan delegasi otoritas di seluruh domain, atau aplikasi yang ditandai sebagai Tepercaya, akan mengabaikan layar izin terperinci. Untuk aplikasi ini, pengguna tidak akan melihat layar izin terperinci. Sebagai gantinya, aplikasi Anda akan menerima semua cakupan yang diminta atau tidak sama sekali.

Untuk informasi yang lebih mendetail, lihat Cara menangani izin terperinci.

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

Misalnya, contoh respons token akses berikut menunjukkan bahwa pengguna telah memberikan akses ke aplikasi Anda untuk izin aktivitas Drive hanya baca dan acara Kalender:

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

Memanggil Google API

Setelah aplikasi Anda mendapatkan token akses, Anda dapat menggunakan token tersebut untuk melakukan panggilan ke Google API atas nama akun pengguna tertentu jika cakupan akses yang diperlukan oleh API telah diberikan. Untuk melakukannya, sertakan token akses dalam permintaan ke API dengan menyertakan parameter kueri access_token atau nilai Bearer header HTTP Authorization. Jika memungkinkan, header HTTP lebih disarankan, karena string kueri cenderung terlihat di log server. Dalam sebagian besar kasus, Anda dapat menggunakan library klien untuk menyiapkan panggilan ke Google API (misalnya, saat memanggil Drive Files API).

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

Contoh HTTP GET

Panggilan ke endpoint drive.files (Drive Files API) menggunakan header HTTP Authorization: Bearer mungkin terlihat seperti berikut. Perhatikan bahwa Anda harus menentukan token akses Anda sendiri:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

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/drive/v2/files

Atau, opsi parameter string kueri:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Memperbarui token akses

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

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

Meskipun penggunaan DPoP bersifat opsional, sebaiknya gunakan untuk meningkatkan keamanan. Untuk menggunakan DPoP dengan token refresh, aplikasi Anda harus membuat JWT bukti DPoP baru yang unik untuk setiap permintaan ke endpoint token. Bukti ini harus ditandatangani dengan kunci pribadi yang sama dengan yang digunakan selama pertukaran kode otorisasi awal. Aplikasi Anda menambahkan bukti sebagai header permintaan HTTP.

Cuplikan berikut menunjukkan contoh permintaan:

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Untuk menggunakan DPoP dengan token refresh, Anda harus membuat JWT bukti DPoP baru yang unik untuk permintaan tersebut. Lihat Membuat bukti DPoP untuk mengetahui petunjuk langkah demi langkah dalam membuat pasangan kunci dan membuat JWT.

Pertukaran yang berhasil ditunjukkan dengan respons 200 OK yang berisi token akses baru. Jika DPoP digunakan, token_type adalah Bearer. Respons yang berhasil mengonfirmasi bahwa bukti DPoP untuk token refresh telah diterima. Google juga dapat menampilkan header HTTP DPoP-Nonce baru dalam respons; jika ditampilkan, klien Anda harus meng-cache nonce ini dan menyertakannya dalam klaim nonce bukti DPoP dalam permintaan berikutnya.

Pertukaran yang gagal terjadi jika header DPoP tidak ada, tidak valid, atau menggunakan kunci yang salah. Untuk mengetahui detail tentang kode error DPoP tertentu dan penanganan nonce, lihat Pertukaran gagal.

Cuplikan berikut menunjukkan contoh header respons dan isi yang berhasil saat DPoP digunakan:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "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"
}

Perhatikan bahwa ada batasan jumlah token refresh yang akan dikeluarkan; satu batas per kombinasi klien/pengguna, dan batas lainnya per pengguna di semua klien. Anda harus menyimpan token refresh dalam penyimpanan jangka panjang dan terus menggunakannya selama masih valid. Jika aplikasi Anda meminta terlalu banyak token refresh, aplikasi tersebut mungkin akan mencapai batas ini, sehingga token refresh yang lebih lama akan berhenti berfungsi.

Pencabutan token

Dalam beberapa kasus, pengguna mungkin ingin mencabut akses yang diberikan ke aplikasi. Pengguna dapat mencabut akses dengan membuka Setelan Akun. Lihat bagian Menghapus akses situs atau aplikasi di Situs & aplikasi pihak ketiga yang memiliki akses ke akun Anda dalam dokumen dukungan untuk mengetahui informasi selengkapnya.

Aplikasi juga dapat mencabut akses yang diberikan kepadanya secara terprogram. Pencabutan terprogram penting dalam situasi saat pengguna berhenti berlangganan, menghapus aplikasi, atau resource API yang diperlukan oleh aplikasi telah berubah secara signifikan. Dengan kata lain, bagian dari proses penghapusan dapat mencakup permintaan API untuk memastikan izin yang sebelumnya diberikan ke aplikasi 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 refresh yang sesuai, token refresh juga akan dicabut.

Jika pencabutan berhasil diproses, kode status HTTP responsnya adalah 200. Untuk kondisi error, kode status HTTP 400 ditampilkan bersama dengan kode error.

Metode pengalihan aplikasi

Melindungi aplikasi Anda

Akses berbasis waktu

Akses berbasis waktu memungkinkan pengguna memberi aplikasi Anda akses ke data mereka selama durasi terbatas untuk menyelesaikan tindakan. Akses berbasis waktu tersedia di produk Google tertentu selama alur izin, yang memberi pengguna opsi untuk memberikan akses selama jangka waktu terbatas. Contohnya adalah Data Portability API yang memungkinkan transfer data satu kali.

Saat pengguna memberikan akses berbasis waktu ke aplikasi Anda, masa berlaku token refresh akan berakhir setelah durasi yang ditentukan. Perhatikan bahwa token refresh dapat dibatalkan lebih awal dalam keadaan tertentu; lihat kasus ini untuk mengetahui detailnya. Kolom refresh_token_expires_in yang ditampilkan dalam respons pertukaran kode otorisasi mewakili waktu yang tersisa hingga token refresh habis masa berlakunya dalam kasus tersebut.

Bacaan Lebih Lanjut

Praktik Terbaik Saat Ini dari IETF OAuth 2.0 for Aplikasi Native menetapkan banyak praktik terbaik yang didokumentasikan di sini.