Apa Itu OAuth? Panduan Autentikasi Modern untuk Pemula

OAuth (Open Authorization) adalah standar terbuka untuk otorisasi yang memungkinkan sebuah aplikasi mengakses data pengguna di aplikasi lain — tanpa aplikasi tersebut perlu tahu password pengguna. Kalau kamu pernah klik tombol "Sign in with Google", "Login with GitHub", atau memberi izin sebuah aplikasi mengakses foto Instagram-mu, kamu sudah pakai OAuth.

Di artikel ini kita bahas OAuth 2.0 dari dasar — apa itu, kenapa penting, komponen intinya, alur kerja (flow) yang umum dipakai, perbedaannya dengan OpenID Connect, sampai kesalahan implementasi yang wajib dihindari.

1. Kenapa OAuth ada?

Bayangkan skenario ini: kamu pakai aplikasi photo printing yang ingin mengambil foto dari akun Google Photos-mu. Sebelum OAuth ada, satu-satunya cara adalah kamu memberikan password Google ke aplikasi itu. Masalahnya banyak:

• Aplikasi jadi tahu password kamu — bisa disalahgunakan.
• Aplikasi punya akses penuh ke akun (email, drive, kalender), padahal cuma butuh foto.
• Kamu tidak bisa mencabut akses tanpa ganti password.
• Kalau aplikasi kena hack, password kamu ikut bocor.

OAuth menyelesaikan semua ini dengan konsep sederhana: kasih token, bukan password. Token itu terbatas — hanya bisa akses hal tertentu, punya masa berlaku, dan bisa dicabut kapan saja.

2. OAuth 2.0 vs OAuth 1.0

Ada dua versi utama, tapi di praktiknya hampir semua aplikasi modern pakai OAuth 2.0.

Untuk sisa artikel ini, "OAuth" merujuk ke OAuth 2.0 (RFC 6749).

3. Otentikasi vs Otorisasi — jangan tertukar

Ini konsep yang sering bikin bingung pemula:

OAuth 2.0 adalah protokol otorisasi, bukan otentikasi. Ia mengurus "apa yang boleh diakses aplikasi X atas nama user Y". Untuk otentikasi (login user), ada standar terpisah yaitu OpenID Connect yang dibangun di atas OAuth 2.0.

Ketika kamu klik "Sign in with Google", yang bekerja sebenarnya OpenID Connect (login) + OAuth 2.0 (izin akses data).

4. Empat pemain utama dalam OAuth

Setiap alur OAuth melibatkan 4 pihak:

Alur dasarnya: Client minta izin ke Resource Owner, dapat authorization grant, tukar grant itu ke Authorization Server dengan access token, lalu pakai token itu untuk mengakses data di Resource Server.

5. Komponen inti: token, scope, client credentials

Access token

"Kartu akses" berbentuk string yang dikirim di header setiap request:

GET /v1/mediaItems HTTP/1.1
Host: photoslibrary.googleapis.com
Authorization: Bearer ya29.a0AfH6SMBx...

Ciri access token:

• Bermasa berlaku pendek (biasanya 1 jam).
• Terbatas scope-nya.
• Bisa berupa opaque string atau JWT (JSON Web Token) yang bisa di-decode.

Refresh token

Karena access token cepat kedaluwarsa, ada refresh token — masa berlaku panjang (bisa bulanan/tahunan), disimpan aman di server, dipakai untuk tukar access token baru tanpa user perlu login ulang.

Scope

"Level izin" yang diminta client. Contoh scope Google:

• openid email profile — data profil dasar.
• https://www.googleapis.com/auth/photoslibrary.readonly — baca foto saja.
• https://www.googleapis.com/auth/gmail.send — kirim email atas nama user.

Prinsip: minta scope sekecil mungkin (least privilege). Aplikasi photo printing tidak butuh scope Gmail.

Client ID & Client Secret

Setiap aplikasi harus mendaftar dulu ke Authorization Server. Setelah daftar dapat:

• Client ID — identitas publik aplikasi (boleh ada di frontend).
• Client Secret — password aplikasi (wajib rahasia, hanya di backend).

6. Alur (flow) OAuth 2.0 yang umum dipakai

OAuth 2.0 punya beberapa "grant type" — pilih yang cocok dengan tipe aplikasi kamu.

Rekomendasi modern (RFC 9700, OAuth 2.1): selalu pakai Authorization Code + PKCE, kecuali skenarionya benar-benar khusus.

7. Authorization Code Flow (dengan PKCE) — step by step

Ini flow yang paling sering kamu temui. Contoh: user login ke aplikasi web pakai Google.

[User] → klik "Sign in with Google" di [Client]
[Client] → redirect ke [Auth Server]:
  GET /authorize?
    client_id=...&
    redirect_uri=https://app.com/callback&
    response_type=code&
    scope=openid%20email%20profile&
    state=xyz&
    code_challenge=hash(verifier)&
    code_challenge_method=S256

[Auth Server] → tampilkan halaman login + consent
[User] → login & klik "Allow"
[Auth Server] → redirect ke [Client]:
  GET https://app.com/callback?code=abc123&state=xyz

[Client backend] → POST /token ke [Auth Server]:
  { code, client_id, client_secret, code_verifier, redirect_uri }

[Auth Server] → balas:
  { access_token, refresh_token, id_token, expires_in }

[Client] → pakai access_token untuk request ke [Resource Server]

Beberapa hal penting:

• state — random string, wajib dicek kembali di callback untuk mencegah CSRF.
• PKCE (code_challenge / code_verifier) — mencegah authorization code interception di aplikasi publik seperti mobile & SPA. verifier = random string di client, challenge = SHA256-nya. Wajib untuk aplikasi publik, direkomendasi juga untuk web app konfidensial.
• redirect_uri — harus persis sama dengan yang didaftarkan. Ini garis pertahanan utama supaya kode tidak "dibajak" ke domain lain.
• Pertukaran code → token — dilakukan di backend, bukan browser, supaya client_secret tidak bocor.

8. OpenID Connect (OIDC) — OAuth + login

OpenID Connect adalah lapisan otentikasi tipis di atas OAuth 2.0. Yang ditambahkan:

• Scope wajib openid.
• Response berisi id_token (JWT) — berisi info identitas user (sub, email, name, dll.).
• Endpoint standar /.well-known/openid-configuration untuk discovery.

Perbedaan singkat:

Provider populer yang support OIDC: Google, Microsoft, Auth0, Okta, Keycloak, Supabase, Clerk.

9. Contoh implementasi sederhana (Node.js pseudo-code)

Backend menerima callback, tukar code → token, panggil userinfo:

// 1. Redirect user ke authorization endpoint
app.get("/login", (req, res) => {
  const state = crypto.randomBytes(16).toString("hex");
  const verifier = crypto.randomBytes(32).toString("base64url");
  const challenge = crypto
    .createHash("sha256")
    .update(verifier)
    .digest("base64url");

  req.session.state = state;
  req.session.verifier = verifier;

  const url = new URL("https://accounts.google.com/o/oauth2/v2/auth");
  url.searchParams.set("client_id", CLIENT_ID);
  url.searchParams.set("redirect_uri", REDIRECT_URI);
  url.searchParams.set("response_type", "code");
  url.searchParams.set("scope", "openid email profile");
  url.searchParams.set("state", state);
  url.searchParams.set("code_challenge", challenge);
  url.searchParams.set("code_challenge_method", "S256");
  res.redirect(url.toString());
});

// 2. Callback: tukar code jadi token
app.get("/callback", async (req, res) => {
  const { code, state } = req.query;
  if (state !== req.session.state) return res.status(400).send("bad state");

  const tokenRes = await fetch("https://oauth2.googleapis.com/token", {
    method: "POST",
    headers: { "content-type": "application/x-www-form-urlencoded" },
    body: new URLSearchParams({
      grant_type: "authorization_code",
      code,
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET,
      redirect_uri: REDIRECT_URI,
      code_verifier: req.session.verifier,
    }),
  });
  const { access_token, id_token } = await tokenRes.json();

  // 3. Pakai access_token untuk ambil profil user
  const userRes = await fetch("https://openidconnect.googleapis.com/v1/userinfo", {
    headers: { authorization: `Bearer ${access_token}` },
  });
  const user = await userRes.json();

  req.session.user = user;
  res.redirect("/dashboard");
});

Di produksi, sebaiknya pakai library matang seperti openid-client, passport, next-auth, atau built-in auth dari platform (Supabase, Clerk, Auth.js).

10. Kesalahan implementasi yang paling sering terjadi

• Menyimpan client_secret di frontend / mobile app — publik semua orang bisa lihat. Untuk aplikasi tanpa backend, pakai PKCE tanpa client secret.
• Tidak validasi state — terbuka terhadap CSRF di callback.
• Redirect URI whitelist longgar — jangan pakai wildcard sembarangan. Daftarkan URI eksplisit.
• Menyimpan token di localStorage — rentan XSS. Untuk web, lebih aman HttpOnly cookie yang di-set oleh backend.
• Tidak validasi id_token — signature JWT harus diverifikasi dengan JWKS provider, bukan sekadar di-decode.
• Scope terlalu lebar — aplikasi jadi over-privileged. User juga cenderung menolak consent scope besar.
• Tidak menangani refresh token rotation — banyak provider modern menerbitkan refresh token baru setiap refresh; refresh token lama harus dianggap invalid.
• Menganggap OAuth = login — jangan bangun sistem login hanya dari OAuth tanpa OIDC / verifikasi identitas yang benar.

11. Kapan sebaiknya pakai / tidak pakai OAuth?

Pakai OAuth / OIDC kalau:

• Butuh "Sign in with Google/GitHub/Apple" di aplikasi.
• Aplikasi kamu perlu mengakses API pihak ketiga atas nama user.
• Perlu single sign-on (SSO) antar aplikasi dalam organisasi.
• Bangun sistem multi-app dan ingin memisahkan identity provider.

Tidak perlu OAuth kalau:

• Aplikasi kamu monolit sederhana dengan login email/password sendiri, tanpa integrasi pihak ketiga — cukup pakai session cookie + hashing password (bcrypt/argon2).
• Butuh API internal service-to-service — bisa pakai token statis atau mTLS.

12. Rekomendasi belajar lebih lanjut

• Baca RFC 6749 (OAuth 2.0 core) dan RFC 6750 (Bearer tokens) — versi ringkasnya di oauth.net.
• Draft OAuth 2.1 merangkum best practice (PKCE wajib, implicit flow dihapus).
• Coba playground interaktif seperti oauth.tools atau oauthdebugger.com.
• Pelajari JWT dan JWKS — struktur id_token dan cara memverifikasinya.
• Untuk implementasi cepat, gunakan managed auth: Supabase Auth, Clerk, Auth0, Firebase Auth, atau NextAuth/Auth.js.

Kesimpulan

OAuth 2.0 terlihat rumit di awal karena banyak istilah (grant, scope, PKCE, JWT, dll.), tapi ide intinya sederhana: kasih aplikasi token terbatas, bukan password.

Yang perlu kamu ingat:

1. OAuth = otorisasi, OIDC = otentikasi (login). Keduanya sering dipakai bersamaan.
2. Ada 4 pemain: Resource Owner, Client, Authorization Server, Resource Server.
3. Untuk hampir semua kasus modern, pakai Authorization Code Flow + PKCE.
4. Jaga client_secret di backend, jangan pernah di frontend.
5. Selalu validasi state, redirect_uri, dan signature id_token.
6. Minta scope sekecil mungkin — hormati privasi user.

Kalau kamu bangun aplikasi baru dan ingin fitur login sosial atau integrasi API pihak ketiga, OAuth 2.0 + OIDC adalah standar yang wajib kamu kuasai. Selamat mengoprek! 🔐