Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

OAuth 2.0 untuk Aplikasi Seluler & Desktop

Dokumen ini menjelaskan bagaimana aplikasi yang dipasang pada perangkat seperti ponsel, tablet, dan komputer menggunakan titik akhir OAuth 2.0 Google untuk memberi otorisasi akses ke Google API.

OAuth 2.0 memungkinkan pengguna untuk berbagi data tertentu dengan aplikasi sambil tetap 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 yang diinstal didistribusikan ke perangkat individu, dan diasumsikan bahwa aplikasi ini tidak dapat menyimpan rahasia. Mereka dapat mengakses Google API saat pengguna berada di aplikasi atau saat aplikasi berjalan di latar belakang.

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

Alternatif

Untuk aplikasi seluler, Anda mungkin lebih suka menggunakan Masuk dengan Google untuk Android atau iOS . Library klien Login dengan Google menangani autentikasi dan otorisasi pengguna, dan mungkin lebih sederhana untuk diterapkan daripada protokol tingkat yang lebih rendah yang dijelaskan di sini.

Untuk aplikasi yang berjalan pada perangkat yang tidak mendukung browser sistem atau yang memiliki kemampuan masukan terbatas, seperti TV, konsol game, kamera, atau printer, lihat OAuth 2.0 untuk TV & Perangkat atau Masuk dengan Google untuk perangkat .

Perpustakaan dan sampel

Kami merekomendasikan pustaka dan contoh berikut untuk membantu Anda menerapkan aliran OAuth 2.0 yang dijelaskan dalam dokumen ini:

Prasyarat

Aktifkan API untuk proyek Anda

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

Untuk mengaktifkan API untuk proyek Anda:

  1. Open the API Library di Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library mencantumkan semua API yang tersedia, dikelompokkan menurut kelompok produk dan popularitas. Jika API yang ingin Anda aktifkan tidak terlihat dalam daftar, gunakan penelusuran untuk menemukannya, atau klik Lihat Semua di keluarga produknya.
  4. Pilih API yang ingin Anda aktifkan, lalu klik tombol Aktifkan .
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Buat kredensial otorisasi

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

  1. Go to the Credentials page.
  2. Klik Buat kredensial> ID klien OAuth .
  3. Bagian di bawah ini menjelaskan jenis klien dan metode pengalihan yang didukung oleh server otorisasi Google. Pilih jenis klien yang direkomendasikan untuk aplikasi Anda, beri nama klien OAuth Anda, dan setel bidang lain di formulir yang sesuai.

Skema URI kustom (Android, iOS, UWP)

Skema URI kustom direkomendasikan untuk aplikasi Android, aplikasi iOS, dan aplikasi Universal Windows Platform (UWP).

Android
  1. Pilih jenis aplikasi Android .
  2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan di Credentials page proyek Anda untuk mengidentifikasi klien.
  3. Masukkan nama paket aplikasi Android Anda. Nilai ini ditentukan dalam atribut package dari elemen <manifest> di file manifes aplikasi Anda.
  4. Masukkan sidik jari sertifikat penandatanganan SHA-1 dari distribusi aplikasi.
    • Jika aplikasi Anda menggunakan penandatanganan aplikasi oleh Google Play , salin sidik jari SHA-1 dari halaman penandatanganan aplikasi di Konsol Play.
    • Jika Anda mengelola keystore dan kunci penandatanganan Anda sendiri, gunakan utilitas keytool yang disertakan dengan Java untuk mencetak informasi sertifikat dalam format yang dapat dibaca manusia. Salin nilai SHA1 di bagian Certificate fingerprints dari keluaran keytool . Lihat Mengautentikasi Klien Anda di Google API untuk dokumentasi Android untuk informasi lebih lanjut.
  5. Klik Buat .
iOS
  1. Pilih jenis aplikasi iOS .
  2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan di Credentials page proyek Anda untuk mengidentifikasi klien.
  3. Masukkan pengenal paket untuk aplikasi Anda. ID paket adalah nilai kunci CFBundleIdentifier dalam file sumber daya daftar properti informasi aplikasi Anda ( info.plist ). Nilai ini paling sering ditampilkan di panel General atau panel Signing & Capabilities editor proyek Xcode. ID bundel juga ditampilkan di bagian Informasi Umum pada halaman Informasi Aplikasi untuk aplikasi di situs Apple's App Store Connect .
  4. (Pilihan)

    Masukkan ID App Store aplikasi Anda jika aplikasi tersebut diterbitkan di App Store Apple. ID Toko adalah string numerik yang disertakan di 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. Tempel tautan ke editor teks. ID App Store adalah bagian terakhir dari URL.

      Contoh: https://apps.apple.com/app/google/id 284815942

  5. (Pilihan)

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

  6. Klik Buat .
UWP
  1. Pilih jenis aplikasi Universal Windows Platform .
  2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan di Credentials page proyek Anda untuk mengidentifikasi klien.
  3. Masukkan ID Microsoft Store 12 karakter aplikasi Anda. Anda dapat menemukan nilai ini di Pusat Mitra Microsoft di halaman Identitas aplikasi di bagian Manajemen aplikasi.
  4. Klik Buat .

Untuk aplikasi UWP, skema URI kustom tidak boleh lebih dari 39 karakter.

Alamat IP Loopback (macOS, Linux, desktop Windows)

Untuk menerima kode otorisasi menggunakan URL ini, aplikasi Anda harus mendengarkan di server web lokal. Itu mungkin terjadi di banyak, tetapi tidak semua, platform. Namun, jika platform Anda mendukungnya, ini adalah mekanisme yang disarankan untuk mendapatkan kode otorisasi.

Saat aplikasi Anda menerima respons otorisasi, untuk kegunaan terbaik, aplikasi harus merespons dengan menampilkan halaman HTML yang menginstruksikan pengguna untuk menutup browser dan kembali ke aplikasi Anda.

Penggunaan yang disarankan aplikasi macOS, Linux, dan desktop Windows (tetapi bukan Universal Windows Platform)
Nilai bentuk Setel jenis aplikasi ke aplikasi Desktop .

Salin / tempel manual

Ekstraksi terprogram

Identifikasi cakupan akses

Cakupan 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, mungkin ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan mendapatkan izin pengguna.

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

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

Mendapatkan token akses OAuth 2.0

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

Langkah 1: Buat pemverifikasi kode dan tantangan

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

Buat pemverifikasi kode

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

Pemverifikasi kode harus memiliki cukup entropi agar tidak praktis untuk menebak nilainya.

Buat tantangan kode

Dua metode untuk membuat tantangan kode didukung.

Metode Pembuatan Tantangan Kode
S256 (disarankan) Tantangan kode adalah hash SHA256 yang dikodekan Base64URL (tanpa padding) dari pemverifikasi kode.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
polos Tantangan kode memiliki nilai yang sama dengan pemverifikasi kode yang dibuat 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 . Titik akhir ini menangani pencarian sesi aktif, mengautentikasi pengguna, dan mendapatkan persetujuan pengguna. Endpoint hanya dapat diakses melalui SSL, dan menolak koneksi HTTP (non-SSL).

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

Parameter
client_id Yg dibutuhkan

ID klien untuk aplikasi Anda. Anda dapat menemukan nilai ini di API Console Credentials page.

redirect_uri Yg dibutuhkan

Menentukan bagaimana server otorisasi Google mengirimkan respons ke aplikasi Anda. Ada beberapa opsi pengalihan yang tersedia untuk aplikasi yang diinstal, dan Anda akan menyiapkan kredensial otorisasi Anda dengan metode pengalihan tertentu.

Nilai harus sama persis dengan salah satu URI pengalihan resmi untuk klien OAuth 2.0, yang Anda konfigurasikan di API Console Credentials page klien Anda. Jika nilai ini tidak cocok dengan URI resmi, Anda akan mendapatkan kesalahan redirect_uri_mismatch .

Tabel di bawah ini menunjukkan nilai parameter redirect_uri sesuai untuk setiap metode:

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 di bawah kendali Anda. Skema kustom harus berisi periode 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 harus dimulai dengan satu garis miring, yang berbeda dari URL HTTP biasa.
Alamat IP loopback http://127.0.0.1: port atau http://[::1]: port

Buat kueri platform Anda untuk alamat IP loopback yang relevan dan mulai pemroses HTTP pada port yang tersedia secara acak. Gantikan port dengan nomor port aktual yang didengarkan aplikasi Anda.

Salin / tempel manual urn:ietf:wg:oauth:2.0:oob
Ekstraksi terprogram urn:ietf:wg:oauth:2.0:oob:auto
response_type Yg dibutuhkan

Menentukan apakah endpoint Google OAuth 2.0 mengembalikan kode otorisasi.

Tetapkan nilai parameter ke code untuk aplikasi yang diinstal.

scope Yg dibutuhkan

Daftar cakupan yang dipisahkan spasi yang mengidentifikasi resource yang dapat diakses aplikasi Anda atas nama pengguna. Nilai-nilai ini menginformasikan layar persetujuan yang ditampilkan Google kepada pengguna.

Cakupan memungkinkan aplikasi Anda hanya meminta akses ke sumber daya yang dibutuhkannya sekaligus memungkinkan pengguna untuk mengontrol jumlah akses yang mereka berikan ke aplikasi Anda. Jadi, ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan mendapatkan izin pengguna.

code_challenge Direkomendasikan

Menentukan code_verifier yang code_verifier yang akan digunakan sebagai tantangan sisi server selama pertukaran kode otorisasi. Parameter ini harus digunakan dengan parameter code_challenge dijelaskan di atas. Lihat bagian membuat tantangan kode di atas untuk informasi lebih lanjut.

code_challenge_method Direkomendasikan

Menentukan metode apa yang digunakan untuk mengenkode code_verifier yang akan digunakan selama pertukaran kode otorisasi. Parameter ini harus digunakan dengan parameter code_challenge . Nilai default code_challenge_method menjadi plain jika tidak ada dalam permintaan yang menyertakan code_challenge . Satu-satunya nilai yang didukung untuk parameter ini adalah S256 atau plain .

state Direkomendasikan

Menentukan nilai string apa pun yang digunakan aplikasi Anda untuk mempertahankan status antara permintaan otorisasi dan respons server otorisasi. Server mengembalikan nilai persis yang Anda kirimkan sebagai pasangan name=value di pengenal 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 benar dalam aplikasi Anda, mengirim nonce, dan mengurangi pemalsuan permintaan lintas situs. Karena redirect_uri Anda dapat ditebak, menggunakan nilai state dapat meningkatkan jaminan Anda bahwa koneksi masuk adalah hasil dari permintaan otentikasi. Jika Anda membuat string acak atau menyandikan hash cookie atau nilai lain yang menangkap status klien, Anda dapat memvalidasi respons untuk juga memastikan bahwa permintaan dan respons berasal dari browser yang sama, memberikan perlindungan terhadap serangan seperti lintas situs meminta pemalsuan. Lihat dokumentasi OpenID Connect untuk contoh cara membuat dan mengonfirmasi token state .

login_hint Pilihan

Jika aplikasi Anda mengetahui pengguna mana yang mencoba mengautentikasi, ia dapat menggunakan parameter ini untuk memberikan petunjuk ke Server Otentikasi Google. Server menggunakan petunjuk untuk menyederhanakan alur login baik dengan mengisi kolom email di formulir login atau dengan memilih sesi multi-login yang sesuai.

Tetapkan nilai parameter ke alamat email atau sub pengenal, yang setara dengan ID Google pengguna.

Contoh URL otorisasi

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

URL identik kecuali untuk nilai parameter redirect_uri . URL juga berisi parameter response_type dan client_id diperlukan serta parameter state opsional. Setiap URL berisi jeda baris dan spasi agar mudah dibaca.

Skema URI kustom

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

Alamat IP loopback

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

Salin / Tempel

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

Ekstraksi terprogram

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

Langkah 3: Google meminta persetujuan pengguna

Pada langkah ini, pengguna memutuskan apakah akan memberikan aplikasi Anda akses yang diminta. Pada tahap ini, Google menampilkan jendela persetujuan yang menunjukkan nama aplikasi Anda dan layanan Google API yang dimintanya untuk mengakses dengan kredensial otorisasi pengguna dan ringkasan cakupan akses yang akan diberikan. Pengguna kemudian dapat menyetujui 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 menunggu respons dari server OAuth 2.0 Google yang menunjukkan apakah ada akses yang diberikan. Tanggapan itu dijelaskan dalam 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 kesalahan ( error ). Misalnya, error=access_denied menunjukkan bahwa pengguna menolak permintaan tersebut.

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

Langkah 5: Tukarkan kode otorisasi untuk penyegaran dan akses token

Untuk menukar kode otorisasi dengan token akses, panggil titik akhir https://oauth2.googleapis.com/token dan setel parameter berikut:

Fields
client_id ID klien diperoleh dari API Console Credentials page.
client_secret Rahasia klien diperoleh dari API Console Credentials page.
code Kode otorisasi dikembalikan dari permintaan awal.
code_verifier Pemverifikasi kode yang Anda buat pada Langkah 1 .
grant_type Seperti yang ditentukan dalam spesifikasi OAuth 2.0 , nilai bidang ini harus disetel ke authorization_code .
redirect_uri Salah satu URI pengalihan yang terdaftar untuk proyek Anda di API Console Credentials page untuk client_id diberikan.

Cuplikan berikut menunjukkan permintaan sampel:

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&
client_secret=your_client_secret&
redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

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

Tanggapan tersebut berisi bidang-bidang berikut:

Fields
access_token Token yang dikirim aplikasi Anda untuk mengotorisasi permintaan Google API.
expires_in Masa pakai token akses yang tersisa dalam hitungan detik.
id_token Catatan: Properti ini hanya dikembalikan jika permintaan Anda menyertakan cakupan identitas, seperti openid , profile , atau email . Nilainya adalah JSON Web Token (JWT) yang berisi informasi identitas yang ditandatangani secara digital tentang pengguna.
refresh_token Token yang dapat Anda gunakan untuk mendapatkan token akses baru. Segarkan token valid hingga pengguna mencabut akses. Perhatikan bahwa token penyegaran selalu dikembalikan untuk aplikasi yang diinstal.
scope Cakupan akses yang diberikan oleh access_token dinyatakan sebagai daftar string peka huruf besar / kecil yang dipisahkan spasi.
token_type Jenis token yang dikembalikan. Saat ini, nilai bidang ini selalu disetel ke Bearer .

Cuplikan berikut menunjukkan contoh tanggapan:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.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 memasukkan parameter kueri access_token atau nilai Bearer header HTTP Authorization . Jika memungkinkan, header HTTP lebih disukai, karena string kueri cenderung terlihat di log server. Dalam kebanyakan kasus, Anda dapat menggunakan pustaka klien untuk menyiapkan panggilan Anda ke Google API (misalnya, saat memanggil API File Drive ).

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 perlu 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 baris perintah 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, sebagai alternatif, opsi parameter string kueri:

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

Memperbarui token akses

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

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

Fields
client_id ID klien diperoleh dari API Console.
client_secret Rahasia klien diperoleh dari API Console tersebut. ( client_secret tidak berlaku untuk permintaan dari klien yang terdaftar sebagai aplikasi Android, iOS, atau Chrome.)
grant_type Seperti yang ditentukan dalam spesifikasi OAuth 2.0 , nilai bidang ini harus disetel ke refresh_token .
refresh_token Token penyegaran dikembalikan dari pertukaran kode otorisasi.

Cuplikan berikut menunjukkan permintaan sampel:

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 tidak mencabut akses yang diberikan ke aplikasi, server token mengembalikan objek JSON yang berisi token akses baru. Cuplikan berikut menunjukkan contoh tanggapan:

{
  "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 penyegaran yang akan dikeluarkan; satu batas per kombinasi klien / pengguna, dan satu lagi per pengguna di semua klien. Anda harus menyimpan token penyegaran dalam penyimpanan jangka panjang dan terus menggunakannya selama masih valid. Jika aplikasi Anda meminta terlalu banyak token penyegaran, aplikasi mungkin akan melewati batasan ini, dalam hal ini token penyegaran yang lebih lama akan berhenti berfungsi.

Mencabut token

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

Mungkin juga aplikasi mencabut akses yang diberikan kepadanya secara terprogram. Pencabutan terprogram penting jika pengguna berhenti berlangganan, menghapus aplikasi, atau sumber daya API yang diperlukan oleh aplikasi telah berubah secara signifikan. Dengan kata lain, bagian dari proses penghapusan dapat menyertakan permintaan API untuk memastikan izin yang sebelumnya diberikan ke aplikasi tersebut 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 adalah token akses dan memiliki token penyegaran yang sesuai, token penyegaran juga akan dicabut.

Jika pembatalan berhasil diproses, maka kode status HTTP dari responsnya adalah 200 . Untuk kondisi kesalahan, kode status HTTP 400 dikembalikan bersama dengan kode kesalahan.

Bacaan lebih lanjut

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