# OAuth Adalah: Pengertian, Cara Kerja, dan Contohnya

> OAuth adalah standar otorisasi agar aplikasi bisa mengakses data atas nama pengguna tanpa password. Pahami peran, alur, PKCE, grant, dan praktik keamanannya.

**URL:** https://www.ciptadusa.com/blog/oauth-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Keamanan Aplikasi  
**Published:** 2026-11-14  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-11/1794622936198-oauth-adalah-20261114.webp  

## Article

OAuth adalah standar otorisasi yang memungkinkan sebuah aplikasi mengakses data atau layanan atas nama pengguna, tanpa pengguna harus memberikan password-nya ke aplikasi itu. Spesifikasi resminya, RFC 6749, menyebut OAuth 2.0 sebagai kerangka otorisasi yang memungkinkan aplikasi pihak ketiga mendapat akses terbatas ke sebuah layanan HTTP, baik atas nama pemilik data maupun atas nama aplikasi itu sendiri ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

Contoh sehari-harinya: aplikasi akuntansi meminta izin membaca email tagihan Anda, atau aplikasi penjadwalan meminta akses ke kalender. Anda menyetujui di halaman penyedia akun, lalu aplikasi mendapat token akses, bukan password Anda. Artikel ini membahas pengertian OAuth, masalah yang diselesaikannya, peran-peran di dalamnya, cara kerja authorization code flow, jenis grant, praktik keamanan terbaru, dan kapan bisnis perlu menerapkannya.

## Pengertian OAuth

Sebelum OAuth, cara paling mudah memberi akses ke aplikasi lain adalah membagikan password. RFC 6749 menjelaskan masalah dari cara lama itu ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)):

- Aplikasi pihak ketiga harus menyimpan password pengguna, biasanya dalam bentuk teks biasa.
- Server harus tetap mendukung login dengan password, padahal password punya kelemahan keamanan bawaan.
- Aplikasi pihak ketiga mendapat akses yang terlalu luas, dan pengguna tidak bisa membatasi durasi atau cakupannya.
- Pengguna tidak bisa mencabut akses satu aplikasi saja tanpa mencabut semuanya, dan harus mengganti password untuk melakukannya.

OAuth menyelesaikan masalah itu dengan token akses. RFC 6749 mendefinisikan access token sebagai kredensial untuk mengakses resource yang dilindungi, berupa string yang mewakili izin yang diberikan ke client. Token mewakili cakupan (scope) dan durasi akses tertentu ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

### OAuth Bukan untuk Login

OAuth adalah standar otorisasi (izin akses), bukan autentikasi (membuktikan siapa pengguna). Untuk login dan single sign-on, yang dipakai adalah OpenID Connect, lapisan identitas di atas OAuth 2.0. Penjelasan lengkapnya ada di artikel [SSO adalah](/blog/sso-adalah).

## Peran dalam OAuth

RFC 6749 mendefinisikan empat peran ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)):

| Peran | Definisi resmi (diringkas) | Contoh (ilustrasi CDS) |
|---|---|---|
| Resource owner | Pihak yang bisa memberi akses ke resource yang dilindungi; jika orang, disebut end-user | Pemilik toko online |
| Resource server | Server yang menyimpan resource yang dilindungi dan menerima request dengan access token | API marketplace yang menyimpan data pesanan |
| Client | Aplikasi yang meminta akses ke resource atas nama dan dengan izin resource owner | Aplikasi gudang yang ingin membaca pesanan |
| Authorization server | Server yang menerbitkan access token ke client setelah mengautentikasi resource owner dan mendapat izinnya | Server login marketplace |

RFC 6749 juga mencatat bahwa authorization server bisa sama dengan resource server atau terpisah, dan satu authorization server bisa menerbitkan token yang diterima banyak resource server ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

## Cara Kerja OAuth: Authorization Code Flow

Flow yang paling umum dan paling direkomendasikan adalah authorization code. Menurut RFC 6749, client tidak meminta izin langsung ke pengguna, melainkan mengarahkan pengguna ke authorization server, yang kemudian mengarahkan pengguna kembali ke client dengan membawa authorization code ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)). Alurnya kira-kira seperti ini:

1. Pengguna menekan tombol "Hubungkan akun" di aplikasi (client).
2. Client mengarahkan browser ke authorization server, membawa client ID, scope yang diminta, alamat redirect, dan parameter PKCE.
3. Pengguna login di authorization server (bukan di aplikasi client) dan melihat halaman persetujuan berisi izin yang diminta.
4. Setelah pengguna setuju, authorization server mengarahkan browser kembali ke alamat redirect client dengan authorization code.
5. Backend client menukar authorization code itu ke token endpoint, bersama bukti PKCE, untuk mendapatkan access token dan kadang refresh token.
6. Client memanggil API resource server dengan access token. Resource server memeriksa token dan cakupannya sebelum melayani request.
7. Saat access token kedaluwarsa, client bisa memakai refresh token untuk mendapat token baru tanpa meminta pengguna login ulang.

Langkah 7 sesuai definisi RFC 6749: refresh token dipakai untuk mendapatkan access token baru saat token lama tidak berlaku atau kedaluwarsa, dan penerbitan refresh token bersifat opsional ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

### Scope: Membatasi Akses

Client menyebutkan cakupan akses lewat parameter `scope`. RFC 6749 menjelaskan bahwa nilai scope berupa daftar string yang dipisah spasi, dan setiap string menambah satu cakupan akses. Nilai string itu ditentukan oleh authorization server ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)). Contoh ilustrasi CDS: aplikasi laporan hanya meminta `orders.read`, bukan `orders.write`, karena ia hanya perlu membaca pesanan.

## Jenis Grant di OAuth 2.0

RFC 6749 mendefinisikan empat jenis grant: authorization code, implicit, resource owner password credentials, dan client credentials ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)). Namun praktik keamanan sudah berubah sejak 2012. RFC 9700, dokumen praktik keamanan terbaik OAuth 2.0 yang terbit Januari 2025, memperbarui rekomendasinya ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)):

| Grant | Status menurut RFC 9700 | Kapan dipakai |
|---|---|---|
| Authorization code + PKCE | Direkomendasikan; client publik wajib memakai PKCE | Aplikasi web, mobile, dan SPA yang bertindak atas nama pengguna |
| Client credentials | Tetap dipakai | Komunikasi antar server, saat client bertindak atas namanya sendiri ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)) |
| Implicit | Sebaiknya tidak dipakai (SHOULD NOT) karena rawan kebocoran dan replay token | Tidak disarankan untuk sistem baru |
| Resource owner password credentials | Tidak boleh dipakai (MUST NOT) | Tidak disarankan untuk sistem baru |

RFC 9700 menjelaskan alasan grant password dilarang: grant ini membuka kredensial pengguna ke client, memperluas tempat password bisa bocor, membiasakan pengguna mengetik password di luar authorization server, dan tidak dirancang untuk autentikasi dua faktor ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)).

## PKCE: Lapisan Pengaman Authorization Code

PKCE (Proof Key for Code Exchange, dibaca "pixy") dibuat karena client publik yang memakai authorization code rentan terhadap serangan penyadapan authorization code. RFC 7636 menjelaskan serangan itu dan teknik untuk mencegahnya ([sumber](https://www.rfc-editor.org/rfc/rfc7636.html)).

Cara kerjanya sederhana: client membuat rahasia acak sementara (code verifier), lalu mengirim versi hash-nya (code challenge) di awal flow. Saat menukar authorization code, client harus menunjukkan rahasia aslinya. Penyerang yang hanya mencuri authorization code tidak bisa menukarnya.

RFC 9700 menegaskan bahwa client publik wajib memakai PKCE, client confidential disarankan memakai PKCE, dan authorization server wajib mendukung PKCE. Meski awalnya dirancang untuk aplikasi native, saran ini berlaku untuk semua jenis client, termasuk aplikasi web. Metode challenge yang disarankan adalah S256 ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)).

## Checklist Keamanan OAuth

Ringkasan dari RFC 9700 untuk tim developer ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)):

1. Cocokkan redirect URI dengan string yang sama persis dengan yang terdaftar, kecuali nomor port localhost untuk aplikasi native.
2. Jangan sediakan open redirector, yaitu URL yang meneruskan browser ke alamat apa pun dari parameter query.
3. Cegah CSRF pada endpoint redirect. PKCE juga membantu mencegahnya.
4. Batasi hak access token seminimal mungkin sesuai kebutuhan aplikasi, dan batasi audience token ke resource server tertentu.
5. Untuk client publik, refresh token harus terikat ke pengirim (sender-constrained) atau dirotasi setiap dipakai.
6. Pertimbangkan sender-constrained access token, misalnya mutual TLS atau DPoP, agar token curian tidak bisa dipakai pihak lain.

Panduan internal CDS sebagai tambahan: simpan client secret hanya di backend, jangan di aplikasi mobile atau kode frontend; catat setiap penerbitan dan pencabutan token; dan sediakan halaman bagi pengguna untuk melihat serta mencabut akses aplikasi yang sudah terhubung. Ingat juga bahwa MFA saja tidak mencegah penyalahgunaan halaman persetujuan OAuth, seperti yang kami bahas di [artikel tentang OAuth consent abuse](/blog/mfa-tidak-cegah-oauth-consent-abuse-20260921).

## OAuth 2.1 dan Arah Standar

RFC 9700 menyebut OAuth 2.1 sedang dikembangkan dan akan memasukkan rekomendasi keamanan dari dokumen tersebut ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)). Artinya, praktik seperti PKCE untuk semua client dan meninggalkan grant implicit serta password akan menjadi bagian inti standar. Untuk sistem baru, ikuti rekomendasi RFC 9700 sejak awal.

## Contoh Pemakaian OAuth di Bisnis

Berikut contoh yang sering ditemui tim CDS (ilustrasi, bukan proyek tertentu):

- **Integrasi marketplace dan aplikasi gudang.** Penjual menghubungkan akun marketplace ke aplikasi stok tanpa memberikan password akun marketplace.
- **Aplikasi pihak ketiga di platform Anda.** Jika bisnis Anda menyediakan [API](/blog/api-adalah) untuk mitra, OAuth memungkinkan pelanggan mengizinkan aplikasi mitra mengakses datanya secara terbatas.
- **Komunikasi antar layanan internal.** Layanan dalam arsitektur [microservices](/blog/microservices-adalah) memakai client credentials untuk memanggil layanan lain.
- **Login ke aplikasi internal.** Untuk kebutuhan ini, gunakan OpenID Connect di atas OAuth, seperti dijelaskan di artikel [SSO](/blog/sso-adalah).

## Kapan Bisnis Perlu Menerapkan OAuth?

Panduan internal CDS:

1. Aplikasi Anda perlu mengakses data pengguna di layanan lain, seperti email, kalender, penyimpanan file, atau marketplace.
2. Anda membuka API untuk mitra atau developer luar, dan pelanggan perlu mengizinkan aplikasi mitra mengakses data mereka.
3. Anda ingin pengguna bisa mencabut akses satu aplikasi tanpa mengganti password.
4. Sistem Anda terdiri dari beberapa layanan yang perlu saling memanggil dengan izin yang jelas.

Jangan membangun authorization server sendiri dari nol kecuali benar-benar perlu. Pakai library atau layanan identitas yang sudah matang, lalu fokus pada konfigurasi yang benar.

## FAQ Seputar OAuth

### OAuth adalah apa dalam bahasa sederhana?

OAuth adalah cara memberi izin aplikasi untuk mengakses data Anda di layanan lain tanpa memberikan password, dengan memakai token akses yang cakupan dan durasinya terbatas ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

### Apa bedanya OAuth dan SSO?

OAuth mengatur izin akses, sedangkan SSO membuat pengguna cukup login sekali untuk banyak aplikasi. SSO berbasis standar modern biasanya memakai OpenID Connect, yang dibangun di atas OAuth 2.0. Lihat artikel [SSO adalah](/blog/sso-adalah).

### Apa itu access token dan refresh token?

Access token adalah kredensial untuk mengakses resource yang dilindungi. Refresh token dipakai untuk mendapatkan access token baru saat token lama kedaluwarsa ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

### Apakah OAuth aman?

OAuth aman jika diterapkan sesuai praktik terbaru: authorization code dengan PKCE, redirect URI yang dicocokkan persis, hak token yang minimal, dan tanpa grant implicit atau password ([sumber](https://www.rfc-editor.org/rfc/rfc9700.html)).

### Apa itu PKCE?

PKCE adalah teknik untuk mencegah serangan penyadapan authorization code, terutama pada client publik seperti aplikasi mobile dan SPA ([sumber](https://www.rfc-editor.org/rfc/rfc7636.html)).

### Apakah OAuth sama dengan JWT?

Tidak. OAuth adalah kerangka otorisasi, sedangkan [JWT](/blog/jwt-adalah) adalah format token. Access token OAuth bisa berbentuk JWT, tetapi bisa juga berupa string acak; RFC 6749 menyebut token biasanya tidak bisa dibaca isinya oleh client ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)).

## Butuh Bantuan Integrasi atau Keamanan API?

Tim CDS membangun API, integrasi antar sistem, dan alur otorisasi OAuth yang mengikuti praktik keamanan terbaru lewat [jasa pembuatan software custom](/services/software). Jika Anda ingin meninjau alur login dan izin akses di sistem yang sudah berjalan, mulai dari [konsultasi IT](/services/consulting). Anda juga bisa melihat [karya CDS](/works) untuk proyek yang sudah kami kerjakan.


---

*Markdown version of https://www.ciptadusa.com/blog/oauth-adalah — generated for AI agents and LLM crawlers.*