Cara Menguji API OAuth 2.0 di Apidog: Authorization Code, Client Credentials, dan Token Refresh

Menguji OAuth 2.0 di Apidog: PKCE, Client Credentials, dan Token Otomatis

Setiap tim API menemui kendala yang sama: endpoint bekerja secara terpisah, lalu OAuth 2.0 diaktifkan dan separuh suite pengujian mulai mengembalikan kode 401. Anda harus mengelola server otorisasi, token akses berumur pendek, scopes, serta menyalin token secara manual dari respons curl ke header.

Coba Apidog hari ini

Solusinya bukan melewatkan autentikasi dalam pengujian, melainkan menjadikan penanganan token sebagai bagian dari konfigurasi pengujian.

Panduan ini membahas dua alur OAuth 2.0 yang paling sering digunakan:

1. Authorization Code dengan PKCE untuk API yang bertindak atas nama pengguna.
2. Client Credentials untuk komunikasi antarlayanan atau machine-to-machine.

Untuk ikhtisar lengkap jenis grant, lihat ikhtisar alur OAuth 2.0.

Kemudian, kita akan mengonfigurasi OAuth 2.0 di Apidog, menggunakan kembali token di beberapa permintaan, menyegarkan token secara otomatis, mewarisi autentikasi dari folder, dan menguji jalur kegagalan.

Dua alur OAuth 2.0 penting untuk pengujian API

OAuth 2.0 mendefinisikan beberapa grant. Untuk pengujian API sehari-hari, pemilihannya bergantung pada satu pertanyaan:

Apakah API bertindak atas nama pengguna atau atas nama layanan?

Authorization Code dengan PKCE

Authorization Code adalah cara standar untuk mendapatkan token yang terikat pada pengguna:

1. Klien mengarahkan pengguna ke server otorisasi.
2. Pengguna masuk dan memberikan persetujuan.
3. Server mengarahkan kembali dengan kode satu kali.
4. Klien menukar kode tersebut dengan access token di endpoint token.

Proses ini didefinisikan dalam RFC 6749 bagian 4.1.

PKCE (Proof Key for Code Exchange) memperkuat pertukaran tersebut. Klien membuat verifier acak, mengirim challenge yang telah di-hash saat meminta otorisasi, lalu membuktikan kepemilikan verifier asli ketika menukar kode.

Penyerang yang menyadap kode tidak dapat menggunakannya. PKCE awalnya ditujukan untuk aplikasi seluler, tetapi panduan oauth.net saat ini merekomendasikannya untuk setiap pertukaran authorization code, termasuk confidential client.

Gunakan alur ini ketika perilaku endpoint bergantung pada identitas pengguna, misalnya:

• GET /orders hanya mengembalikan pesanan milik pemanggil.
• Endpoint admin dibatasi berdasarkan peran.
• Batas laju diterapkan per pengguna.

Client Credentials

Client Credentials menghilangkan pengguna dari alur OAuth. Klien mengautentikasi dirinya sendiri menggunakan client ID dan client secret, lalu menerima token yang mewakili aplikasi.

Contoh permintaan [REDACTED CREDENTIAL]
curl -X POST https://auth.example.com/oauth/token \
-d grant_type=client_credentials \
-d client_id=orders_service \
-d [REDACTED CREDENTIAL] \
-d scope="orders:read orders:write"

Lihat juga dokumentasi [OAuth 2.0 Client Credentials](https://oauth.net/2/grant-types/client-credentials/).

Alur ini cocok untuk API machine-to-machine, seperti:

- Layanan mikro internal.
- Cron job.
- Pipeline CI yang memanggil API deployment.

Client Credentials juga ideal untuk pengujian otomatis karena tidak membutuhkan interaksi manusia. Gunakan alur ini untuk hampir semua suite otomatis, kecuali ketika identitas pengguna memang menjadi bagian dari skenario yang diuji.

## Mengonfigurasi OAuth 2.0 di Apidog

[Apidog](https://apidog.com/?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) menyediakan OAuth 2.0 sebagai tipe autentikasi kelas satu. Konfigurasi dapat dilakukan sekali pada tab **Auth** di tingkat permintaan atau folder.

Apidog mendukung:

- Authorization Code
- Authorization Code (With PKCE)
- Client Credentials
- Password Credentials
- Implicit

Contoh berikut menggunakan API manajemen pesanan fiktif.

### Konfigurasi Client Credentials

Buka permintaan atau folder, ubah tipe autentikasi menjadi **OAuth 2.0**, lalu pilih **Client Credentials**.

Isi kolom berikut:

- **URL Token Akses:** `https://auth.example.com/oauth/token`
- **ID Klien:** `orders_service`
- **Rahasia Klien:** secret yang disediakan
- **Scope:** `orders:read orders:write` di bagian opsi lanjutan

Apidog menyediakan dua cara untuk mengirim kredensial:

- Header Basic Auth.
- Body permintaan.

Pilih format yang sesuai dengan server otorisasi. Auth0 dan Okta menerima keduanya, tetapi beberapa server internal hanya memproses kredensial di body.

Klik **Dapatkan Token**. Apidog akan:

1. Memanggil endpoint token.
2. Menyimpan hasilnya.
3. Menampilkan token dan periode validitasnya.
4. Melampirkan token ke header berikut pada pengiriman berikutnya:

http
[REDACTED CREDENTIAL]

Anda tidak perlu menyalin token atau membuat variabel `{{token}}` secara manual.

### Konfigurasi Authorization Code dengan PKCE

Untuk menguji konteks pengguna, pilih **Authorization Code (With PKCE)**. Di Apidog, PKCE merupakan pilihan grant tersendiri, bukan checkbox tambahan.

Isi kolom berikut:

- **URL Otentikasi:** `https://auth.example.com/oauth/authorize`
- **URL Token Akses:** `https://auth.example.com/oauth/token`
- **URL Callback:** URI pengalihan yang terdaftar pada penyedia OAuth
- **ID Klien dan Rahasia Klien:** dari pendaftaran aplikasi OAuth

Klik **Dapatkan Token**. Apidog akan membuka jendela browser menuju halaman login. Masuk menggunakan pengguna pengujian, setujui layar persetujuan, lalu token akan disimpan di slot terkelola yang sama.

Jika penyedia mengembalikan ID token OpenID Connect bersama access token, gunakan opsi **Token Type Used** untuk menentukan token mana yang akan dilampirkan. Ini berguna ketika API memvalidasi ID token, bukan access token.

Sediakan pengguna pengujian khusus untuk setiap peran yang perlu diuji, misalnya:

- Pembeli.
- Admin.
- Auditor read-only.

Ambil token untuk setiap pengguna dan jalankan ulang skenario yang sama untuk memverifikasi aturan akses berbasis peran.

## Menggunakan kembali dan menyegarkan token otomatis

Access token biasanya kedaluwarsa dalam waktu satu jam. Tanpa pengelolaan token, token kedaluwarsa menyebabkan eksekusi gagal dan memerlukan pengambilan token secara manual.

Apidog kini menyegarkan token OAuth 2.0 secara otomatis ketika server otorisasi mengeluarkan refresh token. Fitur ini dirilis dalam [pembaruan Apidog bulan Juni](https://apidog.com/id/blog/apidog-june-updates-ai-powered-cli-workflows-smoother-imports-oauth-2-auto-refresh?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

Ketika access token tersimpan kedaluwarsa, Apidog akan:

1. Menggunakan refresh token untuk memperoleh token baru.
2. Mengganti token lama.
3. Mengirim permintaan menggunakan token baru.

Jika penyedia memisahkan endpoint refresh token, Anda dapat menetapkan URL khusus tersebut di opsi lanjutan.

Pada Client Credentials, banyak server tidak mengeluarkan refresh token. Spesifikasi OAuth mengizinkannya karena klien dapat melakukan autentikasi ulang kapan saja. Dalam praktiknya, Anda cukup:

- Mengklik **Dapatkan Token** untuk mengambil token baru.
- Meminta token baru di awal setiap eksekusi terjadwal atau CI.

## Mewarisi autentikasi di tingkat folder

Mengonfigurasi OAuth pada setiap permintaan akan membuat konfigurasi sulit dipelihara. Apidog memungkinkan autentikasi ditetapkan pada folder, lalu diwariskan oleh semua permintaan di dalamnya.

Atur OAuth 2.0 sekali pada folder **Orders API**. Semua permintaan di dalam folder, termasuk permintaan baru yang ditambahkan pada sprint berikutnya, akan menggunakan konfigurasi dan token yang sama.

Hal ini sangat berguna untuk skenario pengujian multi-langkah, misalnya:

1. `POST /carts`
2. `POST /carts/{id}/items`
3. `POST /orders`

Dengan autentikasi tingkat folder:

- Ketiga langkah menggunakan token yang sama.
- Refresh token ditangani otomatis.
- Rotasi client secret cukup dilakukan pada satu folder, bukan puluhan permintaan.

Permintaan individual tetap dapat mengesampingkan konfigurasi induk. Gunakan kemampuan ini untuk menyisipkan pengujian negatif ke dalam skenario yang sama.

## Menguji jalur kegagalan OAuth

Pengujian jalur sukses membuktikan bahwa pipeline token berfungsi. Pengujian jalur kegagalan membuktikan bahwa API benar-benar menerapkan autentikasi.

Untuk konteks kode status dan perbandingan autentikasi, lihat [API key vs. Bearer [REDACTED]](https://apidog.com/id/blog/api-key-vs-bearer-token?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

### Token kedaluwarsa atau hilang: harapkan `401`

Gandakan permintaan dalam skenario, lalu timpa autentikasi yang diwarisi dengan salah satu opsi berikut:

- Tanpa autentikasi.
- Bearer [REDACTED] kedaluwarsa yang di-hardcode:

http
[REDACTED CREDENTIAL] [REDACTED]

Tegaskan bahwa:

- Kode status sama dengan `401`.
- Header respons `WWW-Authenticate` tersedia.
- Body tidak membocorkan stack trace atau hostname internal.

Kode `200` merupakan bug kritis. Kode `403` juga menunjukkan masalah desain: server perlu membedakan antara “Saya tidak tahu siapa Anda” dan “Saya tahu siapa Anda, tetapi Anda tidak memiliki izin”.

### Scope salah: harapkan `403`

Buat klien pengujian kedua yang hanya memiliki scope `orders:read`. Ambil tokennya, lalu panggil endpoint tulis seperti `POST /orders`.

Tegaskan bahwa:

- Kode status sama dengan `403`.
- Jika API mengikuti RFC 6750, header `WWW-Authenticate` menyertakan:

text
error="insufficient_scope"

Pengujian ini dapat menangkap konfigurasi yang tidak konsisten, misalnya scope diperiksa di gateway untuk sebagian rute tetapi terlupakan di rute lain. Untuk penjelasan lebih lanjut, baca [penjelasan OAuth 2.0 scopes](https://apidog.com/id/blog/what-are-oauth-2-scopes?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

### Klien tidak valid: harapkan error endpoint token yang bersih

Arahkan permintaan langsung ke:

text
https://auth.example.com/oauth/token

Gunakan `client_secret` palsu. Berdasarkan [RFC 6749 bagian 5.2](https://datatracker.ietf.org/doc/html/rfc6749), server seharusnya mengembalikan status `400` atau `401`, dengan body JSON yang berisi:

json
{
"error": "invalid_client"
}

Tegaskan status dan body tersebut. Server otorisasi juga merupakan API, sehingga kontrak error-nya termasuk bagian dari permukaan yang harus diuji.

## Menegaskan respons token

Endpoint token perlu diuji secara terpisah dari kasus klien tidak valid. Tambahkan langkah yang memanggil endpoint token secara langsung, lalu tambahkan penegasan berikut:

- `access_token` ada dan tidak kosong.
- `token_type` sama dengan `bearer`, tanpa membedakan huruf besar-kecil.
- `expires_in` lebih besar dari `0` dan sesuai kebijakan, misalnya tidak lebih dari `3600`.
- `scope` sesuai dengan yang diminta.

Penegasan scope membantu menemukan server yang secara diam-diam mempersempit grant.

Skenario pengujian Apidog memungkinkan penegasan ini dibuat secara visual pada JSON respons, tanpa skrip. Anda juga dapat mengekstrak `access_token` ke variabel untuk menguji handshake mentah menggunakan langkah berikutnya.

Hubungkan skenario ke CI agar server otorisasi yang bermasalah menggagalkan build, bukan muncul sebagai `401` misterius di produksi.

## Pola konfigurasi yang direkomendasikan

Gunakan pola berikut:

1. Konfigurasikan OAuth 2.0 pada tingkat folder untuk jalur sukses.
2. Gunakan override per permintaan untuk kasus `401` dan `403`.
3. Tambahkan skenario khusus untuk menguji kontrak endpoint token.
4. Gunakan Authorization Code dengan PKCE untuk API berbasis identitas pengguna.
5. Gunakan Client Credentials untuk API layanan-ke-layanan.
6. Aktifkan refresh token otomatis jika penyedia mendukungnya.

[Unduh Apidog](https://apidog.com/download?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) dan coba secara gratis. Tipe autentikasi OAuth 2.0 tersedia pada paket gratis, sehingga Anda dapat mengarahkannya ke endpoint token sendiri dalam beberapa menit.

## Pertanyaan Umum

### Alur OAuth mana yang harus digunakan untuk pengujian API?

Gunakan Client Credentials untuk komunikasi antarmesin dan sebagian besar suite otomatis karena tidak memerlukan browser.

Gunakan Authorization Code dengan PKCE ketika pengujian bergantung pada:

- Identitas pengguna.
- Isolasi data per pengguna.
- Pemeriksaan peran.
- Perilaku persetujuan.

Hindari grant implicit dan password pada rencana pengujian baru karena keduanya tidak direkomendasikan dalam [panduan OAuth saat ini](https://oauth.net/2/).

### Bagaimana cara menyegarkan token kedaluwarsa secara otomatis di Apidog?

Konfigurasikan OAuth 2.0 pada tab **Auth**, lalu ambil token menggunakan **Dapatkan Token**.

Jika server otorisasi mengembalikan refresh token, Apidog akan menyegarkan access token secara otomatis ketika kedaluwarsa. URL refresh token terpisah dapat diatur di opsi lanjutan.

Untuk Client Credentials tanpa refresh token, jalankan kembali **Dapatkan Token** untuk memperoleh token baru.

### Bisakah setiap permintaan dalam skenario berbagi satu token OAuth?

Bisa. Atur konfigurasi OAuth 2.0 pada folder induk agar semua permintaan di dalamnya mewarisi token yang dikelola.

Permintaan individual tetap dapat mengesampingkan konfigurasi folder. Dengan begitu, pengujian token kedaluwarsa dan scope yang salah dapat ditempatkan dalam skenario yang sama.

### Apa arti `401` dan `403` pada API yang dilindungi OAuth?

Gunakan `401` ketika autentikasi gagal, misalnya [REDACTED CREDENTIAL] Hilang.
- Kedaluwarsa.
- Salah format.

Gunakan `403` ketika token valid tetapi tidak memiliki izin, misalnya scope yang diperlukan tidak tersedia.

Perbedaan ini penting bagi logika retry klien: `401` mengisyaratkan bahwa klien perlu melakukan autentikasi ulang, sedangkan `403` mengisyaratkan bahwa klien harus berhenti. Untuk validasi token lebih lanjut, baca [panduan pengujian autentikasi JWT](https://apidog.com/id/blog/test-jwt-authentication-api?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).