OAuth 2.0 untuk Aplikasi Seluler &amp

175 Ringkasan 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 Google API.

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

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

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

Alternatif

Untuk aplikasi seluler, Anda dapat memilih menggunakan Login dengan Google untuk Android atau iOS. Library klien Login dengan Google menangani autentikasi dan otorisasi pengguna, dan dapat lebih mudah diimplementasikan daripada protokol tingkat rendah yang dijelaskan di sini.

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.

Library dan sampel

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

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. API Library mencantumkan semua API yang tersedia, yang dikelompokkan berdasarkan kelompok produk dan popularitas. Jika API yang ingin Anda aktifkan tidak terlihat dalam daftar, gunakan penelusuran untuk mencarinya, atau klik Lihat Semua dalam kategori produk asalnya.
  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.

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.

  1. Go to the Credentials page.
  2. Klik Buat kredensial > client ID OAuth.
  3. Bagian di bawah ini menjelaskan jenis klien dan metode pengalihan yang didukung server otorisasi Google. Pilih jenis klien yang direkomendasikan untuk aplikasi Anda, beri nama klien OAuth Anda, dan tetapkan kolom lain dalam 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 project Anda Credentials page untuk mengidentifikasi klien.
  3. Masukkan nama paket aplikasi Android Anda. Nilai ini ditentukan dalam atribut package elemen <manifest> dalam 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 Konsol Play.
    • Jika Anda mengelola keystore dan kunci penandatanganan Anda sendiri, gunakan aplikasi utilitas keytool yang disertakan dengan Java untuk mencetak informasi sertifikat dalam format yang dapat dibaca manusia. Salin nilai SHA1 di bagian Certificate fingerprints pada output keytool. Baca bagian Mengautentikasi Klien Anda dalam dokumentasi Google API for Android untuk mendapatkan informasi lebih lanjut.
  5. Klik Create.
iOS
  1. Pilih jenis aplikasi iOS.
  2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan di project Anda Credentials page untuk mengidentifikasi klien.
  3. Masukkan ID paket untuk aplikasi Anda. ID paket adalah nilai kunci CFBundleIdentifier di file resource daftar properti informasi aplikasi Anda (info.plist). Nilainya paling sering ditampilkan di panel General atau panel Signing & Capabilities pada editor project Xcode. ID paket juga ditampilkan di bagian Informasi Umum pada halaman Informasi Aplikasi untuk aplikasi di situs App Store Connect Apple.
  4. (Opsional)

    Masukkan ID App Store aplikasi Anda jika aplikasi dipublikasikan di App Store Apple. ID Toko adalah string numerik 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 atas).
    4. Pilih Salin Link.
    5. Tempel link 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 Menemukan ID Tim Anda di dokumentasi Apple Developer Account untuk informasi selengkapnya.

  6. Klik Create.
UWP
  1. Pilih jenis aplikasi Universal Windows Platform.
  2. Masukkan nama untuk klien OAuth. Nama ini ditampilkan di project Anda Credentials page untuk mengidentifikasi klien.
  3. Masukkan ID Microsoft Store 12 karakter aplikasi Anda. Anda dapat menemukan nilai ini di Microsoft Partner Center pada halaman Identitas aplikasi di bagian Pengelolaan aplikasi.
  4. Klik Create.

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

Alamat IP loopback (macOS, Linux, Windows desktop)

Untuk menerima kode otorisasi menggunakan URL ini, aplikasi Anda harus diproses di server web lokal. Hal ini mungkin dilakukan di banyak platform, tetapi tidak semuanya. Namun, jika platform Anda mendukungnya, ini adalah mekanisme yang direkomendasikan untuk mendapatkan kode otorisasi.

Saat menerima respons otorisasi, aplikasi harus meresponsnya dengan menampilkan halaman HTML yang meminta pengguna untuk menutup browser dan kembali ke aplikasi Anda saat aplikasi menerima respons otorisasi.

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

Salin/tempel manual

Identifikasi cakupan akses

Cakupan memungkinkan aplikasi Anda untuk hanya meminta akses ke resource yang dibutuhkan, sekaligus memungkinkan pengguna untuk mengontrol jumlah akses yang diberikan ke aplikasi Anda. Dengan demikian, mungkin ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan untuk mendapatkan izin pengguna.

Sebelum mulai menerapkan otorisasi OAuth 2.0, sebaiknya Anda mengidentifikasi cakupan yang memerlukan izin untuk diakses oleh aplikasi Anda.

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

Memperoleh token akses OAuth 2.0

Langkah-langkah berikut menunjukkan cara 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 memerlukan otorisasi pengguna.

Langkah 1: Buat verifikasi kode dan verifikasi login

Google mendukung protokol Key Key untuk Code Exchange (PKCE) agar alur penginstalan aplikasi menjadi lebih aman. Pemverifikasi kode unik dibuat untuk setiap permintaan otorisasi, dan nilainya yang diubah, yang disebut "code_challenge", dikirim ke server otorisasi untuk mendapatkan kode otorisasi.

Membuat pemverifikasi kode

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

Pemverifikasi kode harus memiliki entropi yang cukup agar tidak mudah menebak nilainya.

Membuat tantangan kode

Ada dua metode pembuatan tantangan kode.

Metode Pembuatan Tantangan Kode
S256 (direkomendasikan) Tantangan kode adalah hash SHA256 yang dienkode Base64URL (tanpa padding) dari pemverifikasi kode.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
biasa Tantangan kode adalah 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. Endpoint ini menangani pencarian sesi aktif, mengautentikasi pengguna, dan mendapatkan izin pengguna. Endpoint hanya dapat diakses melalui SSL, dan endpoint ini menolak koneksi HTTP (non-SSL).

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

Parameter
client_id Wajib

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

redirect_uri Wajib

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

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

Tabel di bawah ini 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 berada di bawah kendali Anda. Skema kustom harus berisi titik agar valid.
  • com.googleusercontent.apps.123 adalah notasi DNS terbalik dari client ID.
  • redirect_uri_path adalah komponen jalur opsional, seperti /oauth2redirect. Perlu diketahui bahwa jalur harus diawali dengan garis miring, yang berbeda dengan URL HTTP reguler.
Alamat IP Loop http://127.0.0.1:port atau http://[::1]:port

Buat kueri platform Anda untuk mendapatkan alamat IP loopback yang relevan dan mulai pemroses HTTP di port yang tersedia secara acak. Ganti port dengan nomor port sebenarnya yang didengarkan aplikasi Anda.

Perhatikan bahwa dukungan untuk opsi pengalihan alamat IP loopback di aplikasi seluler TIDAK DIGUNAKAN LAGI.

response_type Wajib

Menentukan apakah endpoint Google OAuth 2.0 menampilkan kode otorisasi.

Setel parameter value ke code untuk aplikasi yang diinstal.

scope Wajib

Daftar cakupan yang dipisahkan spasi yang mengidentifikasi resource yang dapat diakses aplikasi Anda atas nama pengguna. Nilai ini menunjukkan layar izin yang ditampilkan Google kepada pengguna.

Dengan cakupan, aplikasi Anda hanya dapat meminta akses ke resource yang diperlukan sekaligus memungkinkan pengguna mengontrol jumlah akses yang diberikan ke aplikasi Anda. Dengan demikian, ada hubungan terbalik antara jumlah cakupan yang diminta dan kemungkinan untuk mendapatkan izin pengguna.

code_challenge Direkomendasikan

Menentukan code_verifier yang dienkode yang akan digunakan sebagai tantangan sisi server selama pertukaran kode otorisasi. Lihat bagian membuat tantangan kode di atas untuk informasi selengkapnya.

code_challenge_method Direkomendasikan

Menentukan metode yang digunakan untuk mengenkode code_verifier yang akan digunakan selama pertukaran kode otorisasi. Parameter ini harus digunakan dengan parameter code_challenge yang dijelaskan di atas. Nilai code_challenge_method ditetapkan secara default ke 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 menampilkan nilai persis seperti yang Anda kirim sebagai pasangan name=value dalam ID 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 resource yang benar di aplikasi, mengirim nonce, dan mengurangi pemalsuan permintaan lintas situs. Karena redirect_uri Anda dapat ditebak, menggunakan nilai state dapat meningkatkan jaminan bahwa koneksi yang masuk adalah hasil dari permintaan autentikasi. Jika Anda membuat string acak atau mengenkode hash cookie atau nilai lainnya yang menangkap status klien, Anda dapat memvalidasi respons untuk memastikan bahwa permintaan dan respons berasal dari browser yang sama, yang memberikan perlindungan terhadap serangan seperti pemalsuan permintaan lintas situs. Lihat dokumentasi OpenID Connect untuk mengetahui contoh cara membuat dan mengonfirmasi token state.

login_hint Opsional

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

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

Contoh URL otorisasi

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

URL 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 jeda baris dan spasi agar lebih mudah dibaca.

Skema URI kustom

https://accounts.google.com/o/oauth2/v2/auth?
 scope=&
 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=&
 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 kepada aplikasi Anda. Pada tahap ini, Google menampilkan jendela izin yang menampilkan nama aplikasi Anda dan layanan Google API yang meminta izin untuk mengakses dengan kredensial otorisasi pengguna dan ringkasan cakupan akses yang akan diberikan. Kemudian, pengguna dapat memberikan izin 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 ada akses yang diberikan. Respons tersebut dijelaskan dalam langkah-langkah berikut.

Error

Permintaan ke endpoint otorisasi OAuth 2.0 Google mungkin menampilkan pesan error yang ditampilkan kepada pengguna, bukan alur autentikasi dan otorisasi yang diharapkan. Kode error dan penyelesaian yang disarankan tercantum di bawah.

admin_policy_enforced

Akun Google tidak dapat mengotorisasi satu atau beberapa cakupan yang diminta karena kebijakan administrator Google Workspace-nya. Lihat artikel bantuan Admin Google Workspace Mengontrol aplikasi pihak ketiga & internal yang mengakses data Google Workspace untuk mengetahui informasi selengkapnya tentang cara administrator dapat membatasi akses ke semua cakupan atau cakupan yang sensitif dan dibatasi hingga akses diberikan secara eksplisit ke client ID OAuth Anda.

disallowed_useragent

Endpoint otorisasi ditampilkan di dalam agen pengguna tersemat yang dilarang oleh Kebijakan OAuth 2.0 Google.

Android

Developer Android mungkin mendapati pesan error ini saat membuka permintaan otorisasi di android.webkit.WebView. Sebagai gantinya, developer sebaiknya menggunakan library Android seperti Login dengan Google untuk Android atau AppAuth untuk Android dalam OpenID Foundation.

Developer web mungkin mengalami error ini saat aplikasi Android membuka link web umum di agen pengguna tersemat dan pengguna membuka endpoint otorisasi OAuth 2.0 Google dari situs Anda. Developer harus mengizinkan link umum terbuka di pengendali link default sistem operasi, yang mencakup pengendali Link Aplikasi Android atau aplikasi browser default. Library Tab Khusus Android juga merupakan opsi yang didukung.

iOS

Developer iOS dan macOS mungkin mengalami error ini saat membuka permintaan otorisasi di WKWebView. Sebagai gantinya, developer sebaiknya menggunakan library iOS seperti Login dengan Google untuk iOS atau AppAuth untuk iOS OpenID Foundation.

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

org_internal

Client ID OAuth dalam permintaan adalah bagian dari project yang membatasi akses ke Akun Google dalam Organisasi Google Cloud tertentu. Untuk mendapatkan informasi selengkapnya tentang opsi konfigurasi ini, lihat bagian Jenis pengguna di artikel bantuan layar menyiapkan izin OAuth.

redirect_uri_mismatch

redirect_uri yang diteruskan dalam permintaan otorisasi tidak cocok dengan URI pengalihan yang diotorisasi untuk client ID OAuth. Tinjau URI pengalihan yang diotorisasi di Google API Console Credentials page.

redirect_uri yang diteruskan mungkin tidak valid untuk jenis klien.

Langkah 4: Menangani respons server OAuth 2.0

Cara aplikasi Anda menerima respons otorisasi bergantung pada skema URI pengalihan yang digunakannya. Terlepas dari skema, 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 dapat menukarkan kode otorisasi untuk token akses dan token refresh seperti yang dijelaskan pada langkah berikutnya.

Langkah 5: Tukar kode otorisasi untuk refresh dan token akses

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

Kolom
client_id Client ID yang diperoleh dari API Console Credentials page.
client_secret Rahasia klien yang diperoleh dari API Console Credentials page.
code Kode otorisasi yang ditampilkan dari permintaan awal.
code_verifier Pemverifikasi kode yang Anda buat di Langkah 1.
grant_type Seperti yang ditentukan dalam spesifikasi OAuth 2.0, nilai kolom ini harus ditetapkan ke authorization_code.
redirect_uri Salah satu URI pengalihan yang tercantum untuk project Anda di API Console Credentials page untuk client_id tertentu.

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&
client_secret=your_client_secret&
redirect_uri=http%3A//127.0.0.1%3A9004&
grant_type=authorization_code

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

Respons berisi kolom berikut:

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

Cuplikan berikut menunjukkan respons contoh:

{
  "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 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 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 terautentikasi yang 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 berakhir masa berlakunya dan menjadi kredensial yang tidak valid untuk permintaan API terkait. Anda dapat memuat ulang token akses tanpa meminta izin pengguna (termasuk ketika pengguna tidak ada) jika Anda meminta akses offline ke cakupan yang terkait dengan token.

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

Kolom
client_id Client ID yang diperoleh dari API Console.
client_secret Rahasia klien yang diperoleh dari API Console. (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 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 tidak mencabut akses yang diberikan ke aplikasi, server token akan menampilkan 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",
  "token_type": "Bearer"
}

Perhatikan bahwa ada batasan jumlah token refresh yang akan dikeluarkan; satu batas per kombinasi klien/pengguna, dan satu lagi per pengguna untuk semua klien. Anda harus menyimpan token refresh dalam penyimpanan jangka panjang dan terus menggunakannya selama masih valid. Jika meminta terlalu banyak token refresh, aplikasi Anda mungkin akan mencapai batas tersebut. Jika tidak, 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 membuka Setelan Akun. Lihat bagian Menghapus situs atau akses aplikasi dari Situs pihak ketiga & aplikasi yang memiliki akses ke akun Anda untuk informasi selengkapnya.

Aplikasi juga dapat mencabut akses yang diberikan kepadanya secara terprogram. Pencabutan terprogram penting dilakukan jika 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 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 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 respons adalah 200. Untuk kondisi error, kode status HTTP 400 ditampilkan bersama dengan kode error.

Bacaan Lebih Lanjut

Praktik Terbaik Terbaik IETF OAuth 2.0 untuk Aplikasi Native menerapkan banyak praktik terbaik yang didokumentasikan di sini.