Beranda jwt keamanan oauth pemrograman

Begini Cara Pahami Perbedaan JWT & OAuth Biar Nggak Bingung Lagi

Updated: • 0 • min read
Table of Contents

Sering dengar istilah JWT dan OAuth di dunia pengembangan web atau aplikasi? Mungkin kamu berpikir keduanya adalah hal yang sama, atau minimal fungsinya mirip banget. Eits, tunggu dulu! Meskipun sering muncul berbarengan, JWT (JSON Web Token) dan OAuth sebenarnya adalah dua konsep yang fundamentalnya beda lho. Memahaminya bikin kamu nggak bingung lagi saat ngoprek otentikasi dan otorisasi.

Secara sederhana, bayangkan gini: OAuth itu kayak proses kamu minta izin ke seseorang (atau sebuah layanan) buat ngambil sesuatu (data kamu di layanan itu) tanpa harus ngasih kunci rumahmu (passwordmu). Nah, JWT itu kayak kunci (atau kartu identitas) yang kamu dapat setelah proses izin itu selesai, yang membuktikan kalau kamu memang sudah dapat izin dan apa saja yang boleh kamu akses. Jauh kan bedanya? Satunya mekanisme, satunya representasi data.

Apa Sih JWT Itu?

JWT, singkatan dari JSON Web Token, adalah sebuah standar terbuka (RFC 7519) untuk menciptakan token yang isinya berupa informasi yang terenkripsi dan bisa diverifikasi secara digital. Token ini biasanya digunakan untuk mewakilkan “klaim” (claims) antar dua pihak, misalnya antara server dan klien, atau antar dua server. Klaim ini bisa macam-macam, mulai dari identitas pengguna, hak akses, sampai informasi spesifik lainnya.

What is JWT
Image just for illustration

Salah satu keunggulan utama JWT adalah sifatnya yang “stateless”. Artinya, server yang menerima JWT nggak perlu menyimpan state atau informasi tentang pengguna yang mengirim token tersebut. Semua informasi yang diperlukan (seperti siapa penggunanya, apa saja hak aksesnya) sudah ada di dalam token itu sendiri, yang ditandatangani oleh server pengirim. Ini bikin aplikasi lebih scalable, apalagi kalau arsitektur microservices.

Struktur JWT: Tiga Bagian Ajaib

Sebuah JWT itu bentuknya string yang terdiri dari tiga bagian, dipisahkan oleh titik (.). Ketiga bagian ini adalah:

  1. Header: Bagian ini biasanya berisi metadata tentang token itu sendiri, seperti jenis token (pasti “JWT”) dan algoritma hashing yang digunakan untuk tanda tangan (signature), misalnya HS256 atau RS256.
  2. Payload (atau Claims): Ini adalah inti dari token. Berisi klaim-klaim tentang entitas (biasanya pengguna) dan metadata tambahan. Klaim ini ada tiga jenis: Registered Claims (klaim standar seperti iss untuk issuer, exp untuk waktu kadaluarsa, sub untuk subjek/pengguna), Public Claims (klaim yang didefinisikan publik), dan Private Claims (klaim kustom antar pihak yang menyepakati).
  3. Signature: Bagian terakhir ini adalah tanda tangan digital dari header dan payload. Tanda tangan ini dibuat menggunakan algoritma yang ditentukan di header dan sebuah kunci rahasia (secret key) yang hanya diketahui oleh pihak yang mengeluarkan token (atau kedua belah pihak jika menggunakan kunci simetris). Bagian inilah yang memastikan integritas token, bahwa isinya belum dimodifikasi di tengah jalan.

header.payload.signature

Semua bagian ini, kecuali signature, biasanya di-encode menggunakan Base64 URL Encoding sebelum digabung menjadi satu string token. Proses encoding ini bukan enkripsi ya, jadi isi header dan payload itu bisa dibaca oleh siapa saja yang punya tokennya. Makanya, jangan pernah menyimpan informasi sensitif seperti password di dalam payload JWT.

Bagaimana JWT Bekerja?

Mekanisme kerja JWT itu cukup simpel tapi powerful. Begini kira-kira alurnya:

  1. Pengguna login ke server (dengan username dan password, misalnya).
  2. Server memverifikasi kredensial pengguna. Jika valid, server akan membuat sebuah JWT. Server akan mengisi payload dengan klaim tentang pengguna (misalnya ID pengguna, peran, dll.) dan menambahkan header.
  3. Server kemudian menandatangani header dan payload menggunakan kunci rahasia. Hasilnya adalah token JWT yang utuh.
  4. Token ini dikirim kembali ke klien (browser atau aplikasi mobile) biasanya dalam respons login.
  5. Klien menyimpan token ini (misalnya di local storage atau cookies).
  6. Setiap kali klien ingin mengakses sumber daya yang dilindungi di server (misalnya data profil, daftar postingan), klien akan menyertakan token JWT ini dalam header permintaan HTTP (biasanya di header Authorization: Bearer <token>).
  7. Server yang menerima permintaan akan mengambil token dari header. Tanpa perlu query database untuk cek sesi, server langsung memverifikasi tanda tangan (signature) token menggunakan kunci rahasia yang sama.
  8. Jika tanda tangan valid, server yakin bahwa token itu asli dan belum diubah. Server kemudian bisa membaca klaim di payload untuk mengetahui siapa pengguna ini dan hak akses apa yang dia miliki. Berdasarkan klaim tersebut, server memutuskan apakah pengguna diizinkan mengakses sumber daya yang diminta.
  9. Jika tanda tangan tidak valid atau token sudah kadaluarsa (klaim exp), server akan menolak permintaan.

How JWT Works
Image just for illustration

Kasus Penggunaan JWT

JWT sangat populer untuk beberapa kasus:

  • Otentikasi (Authentication): Setelah pengguna login, JWT diberikan dan digunakan untuk mengidentifikasi pengguna di setiap permintaan berikutnya. Ini adalah implementasi otentikasi stateless.
  • Pertukaran Informasi (Information Exchange): JWT bisa digunakan untuk mengirim informasi antar pihak secara aman karena isinya ditandatangani. Misalnya, mengirim data pengguna dari satu microservice ke microservice lain tanpa perlu query database lagi.
  • Otorisasi (Authorization): Klaim dalam payload bisa berisi informasi tentang hak akses pengguna, memungkinkan server sumber daya untuk memverifikasi apakah pengguna diizinkan melakukan tindakan tertentu.

Plus Minus JWT

Keunggulan:

  • Stateless: Server nggak perlu menyimpan informasi sesi, bikin aplikasi lebih skalabel.
  • Ringkas: JWT ukurannya relatif kecil.
  • Cepat: Verifikasi tanda tangan lebih cepat daripada query database untuk sesi.
  • Portabel: Bisa digunakan di berbagai platform (web, mobile, API).

Kelemahan:

  • Tidak Bisa Dibatalkan (Revocation): JWT, begitu dikeluarkan, sulit untuk dibatalkan sebelum masa kadaluarsanya berakhir, kecuali ada mekanisme tambahan (seperti blacklist token di server, yang ironically membuat server jadi stateful lagi).
  • Payload Terbaca: Isi payload tidak terenkripsi, hanya di-encode. Jangan taruh info sensitif.
  • Ukuran Token: Bisa membesar jika klaim terlalu banyak, mempengaruhi ukuran header permintaan.

Apa Sih OAuth Itu?

Sekarang kita pindah ke OAuth. OAuth, singkatan dari Open Authorization, adalah sebuah framework otorisasi terbuka (RFC 6749). Intinya, OAuth memungkinkan pengguna memberikan akses ke aplikasi pihak ketiga untuk mengakses data mereka di aplikasi lain (biasanya aplikasi utama) tanpa harus membagikan username dan password mereka.

What is OAuth
Image just for illustration

Pikirkan saat kamu login ke sebuah website menggunakan akun Google atau Facebook. Nah, itu adalah contoh paling umum dari OAuth. Website yang kamu kunjungi (aplikasi pihak ketiga) minta izin ke Google atau Facebook (aplikasi utama/Authorization Server) untuk mengakses data profilmu (data pengguna). Kamu sebagai pengguna (Resource Owner) memberikan izin tersebut melalui Google/Facebook, dan Google/Facebook kemudian memberikan sebuah token akses (Access Token) kepada website tersebut. Website itu lalu menggunakan token ini untuk mengambil data profilmu dari Google/Facebook (Resource Server).

OAuth mendefinisikan peran-peran yang terlibat dalam proses ini:

  1. Resource Owner: Pengguna akhir yang memiliki data (kamu).
  2. Client: Aplikasi pihak ketiga yang ingin mengakses data pengguna (website yang kamu kunjungi).
  3. Authorization Server: Server yang memverifikasi identitas Resource Owner dan mengeluarkan Access Token (Google, Facebook, Twitter, dll.).
  4. Resource Server: Server yang menyimpan data pengguna dan bisa diakses menggunakan Access Token (server API Google, server API Facebook, dll.).

Bagaimana OAuth Bekerja? (Secara Sederhana)

Ada beberapa “Grant Type” atau alur pemberian izin dalam OAuth, tapi yang paling umum dan mudah dipahami adalah Authorization Code Grant. Begini alurnya:

  1. Kamu mengklik tombol “Login with Google” di sebuah website (Client).
  2. Website (Client) mengarahkanmu ke halaman login dan permintaan izin di Google (Authorization Server). Permintaan ini menyertakan informasi tentang Client (Client ID), URL callback, dan scope (izin apa saja yang diminta, misalnya “baca profil”).
  3. Di halaman Google, kamu login (jika belum) dan Google menampilkan permintaan izin yang diminta oleh website tersebut (misalnya, “Website X meminta izin untuk melihat nama dan email Anda”).
  4. Kamu, sebagai Resource Owner, menyetujui permintaan izin tersebut.
  5. Google (Authorization Server) kemudian mengarahkan kembali browser-mu ke URL callback yang disediakan oleh Client, sambil menyertakan sebuah “Authorization Code” dalam parameter URL.
  6. Browser-mu sampai di URL callback di website (Client). Website ini mengambil Authorization Code dari URL.
  7. Secara backend, website (Client) menukarkan Authorization Code ini dengan Access Token ke Google (Authorization Server). Penukaran ini dilakukan langsung antara server website dan server Google, bukan melalui browser. Ini penting untuk keamanan. Website juga menyertakan Client ID dan Client Secret (kunci rahasia website itu) untuk verifikasi identitasnya.
  8. Jika Authorization Code dan kredensial Client valid, Google (Authorization Server) mengeluarkan Access Token (dan kadang Refresh Token) dan mengirimkannya kembali ke server website (Client).
  9. Server website (Client) menyimpan Access Token ini.
  10. Setiap kali website ingin mengakses data profilmu di Google (Resource Server), website menggunakan Access Token ini dalam header permintaan API ke Google.
  11. Google (Resource Server) memverifikasi Access Token. Jika valid, ia mengizinkan website mengakses data profilmu.

How OAuth Works
Image just for illustration

Perhatikan bahwa username dan password Google-mu tidak pernah dibagikan kepada website pihak ketiga tersebut. Kamu hanya memberikan izin kepada Google untuk memberikan token akses kepada website tersebut. Ini jauh lebih aman daripada kamu memberikan kredensialmu langsung ke website.

Kasus Penggunaan OAuth

OAuth paling sering digunakan untuk:

  • Delegasi Otorisasi: Memungkinkan aplikasi pihak ketiga bertindak atas nama pengguna tanpa mengetahui kredensial pengguna.
  • Single Sign-On (SSO): Memungkinkan pengguna login ke beberapa aplikasi berbeda menggunakan satu set kredensial (misalnya, login dengan Google/Facebook).
  • Akses API Terlindungi: Mengatur akses ke API di mana pengguna memberikan izin terbatas kepada aplikasi lain.

Plus Minus OAuth

Keunggulan:

  • Keamanan Tinggi: Pengguna tidak perlu membagikan kredensial utama mereka ke aplikasi pihak ketiga.
  • Kontrol Izin: Pengguna bisa melihat dan mencabut izin yang diberikan kepada aplikasi pihak ketiga kapan saja.
  • Fleksibel: Mendukung berbagai alur (Grant Type) untuk skenario yang berbeda.

Kelemahan:

  • Kompleksitas: Implementasinya lebih kompleks dibandingkan sekadar otentikasi username/password sederhana. Melibatkan banyak pihak dan langkah.
  • Butuh Interaksi Pengguna: Untuk alur seperti Authorization Code Grant, pengguna harus berinteraksi langsung untuk memberikan izin (kecuali untuk kasus tertentu seperti Client Credentials).

Jadi, Apa Perbedaan Fundamentalnya?

Setelah membahas JWT dan OAuth secara terpisah, sekarang makin jelas kan bedanya?

  • JWT adalah sebuah TOKEN. Ini adalah format untuk mentransmisikan informasi secara aman sebagai objek JSON yang ditandatangani. JWT itu mewakili sesuatu, biasanya identitas atau hak akses.
  • OAuth adalah sebuah FRAMEWORK. Ini adalah protokol atau mekanisme untuk mendelegasikan otorisasi, yaitu memberikan izin kepada aplikasi pihak ketiga untuk mengakses sumber daya yang dimiliki pengguna di aplikasi lain, tanpa membagikan kredensial.

JWT vs OAuth Analogy
Image just for illustration

Kita bisa pakai analogi lain:

Bayangkan kamu mau masuk ke sebuah gedung kantor yang butuh kartu akses.

  • OAuth itu seperti proses kamu mengurus pembuatan kartu akses itu. Kamu datang ke bagian keamanan, menunjukkan KTP (identitas), mengisi formulir, dan meminta izin untuk mengakses area tertentu (misalnya lantai 5). Setelah proses verifikasi dan persetujuan, bagian keamanan mengeluarkan sebuah kartu akses untukmu.
  • JWT itu seperti kartu aksesnya itu sendiri. Kartu itu berisi informasi tentang siapa kamu dan area mana saja yang boleh kamu masuki (informasi ini ditandatangani oleh bagian keamanan, sehingga tidak bisa dipalsukan). Saat kamu mau masuk ke lantai 5, kamu tinggal menempelkan kartu itu ke sensor. Sensor (server sumber daya) membaca informasi di kartu (memverifikasi tanda tangan JWT) dan jika valid, pintu terbuka.

Dalam analogi ini, OAuth adalah prosesnya, dan JWT adalah kartu fisik yang dihasilkan dari proses tersebut dan digunakan untuk membuktikan bahwa kamu sudah melewati proses izin.

JWT dan OAuth Sering Digunakan Bersama

Karena fungsinya yang berbeda tapi saling melengkapi, JWT dan OAuth sering banget dipakai barengan. Dalam skenario OAuth, Access Token yang diberikan oleh Authorization Server kepada Client (aplikasi pihak ketiga) itu seringkali berbentuk JWT.

Kenapa? Karena JWT itu stateless dan berisi klaim. Jadi, ketika Client menggunakan Access Token (yang berupa JWT) untuk mengakses Resource Server, Resource Server bisa langsung memverifikasi JWT itu (mengecek tanda tangan dan klaim di dalamnya) tanpa perlu lagi bertanya ke Authorization Server “eh, token ini valid nggak ya? token ini buat pengguna siapa?”. Semua informasi yang dibutuhkan sudah ada di dalam JWT itu sendiri (payloadnya bisa berisi ID pengguna, scope izin yang diberikan, dll.). Ini membuat Resource Server jadi lebih efisien.

Jadi, dalam alur OAuth:

  1. Authorization Server mengeluarkan Access Token (yang bisa berformat JWT) setelah pengguna memberikan izin.
  2. Client menggunakan Access Token (JWT) ini untuk mengakses Resource Server.
  3. Resource Server memverifikasi Access Token (JWT) untuk memastikan Client memiliki izin yang diperlukan.

Token JWT di sini berfungsi sebagai bukti otorisasi yang didapatkan melalui framework OAuth.

Fakta Menarik & Tips

  • JWT Populer di Microservices: Arsitektur microservices sangat diuntungkan dengan JWT karena sifatnya yang stateless. Layanan-layanan yang berbeda bisa memverifikasi token tanpa harus saling berkomunikasi untuk mengecek sesi pengguna.
  • JWA (JSON Web Algorithms): Algoritma hashing yang digunakan dalam JWT didefinisikan dalam spesifikasi terpisah bernama JWA. Ada banyak algoritma yang bisa dipakai, tapi pastikan menggunakan yang kuat dan sesuai kebutuhan. HS256 (HMAC + SHA-256) umum dipakai untuk kunci simetris, sedangkan RS256 (RSA + SHA-256) untuk kunci asimetris.
  • OAuth Versi: Ada OAuth 1.0 dan OAuth 2.0. Saat ini, OAuth 2.0 adalah standar yang umum digunakan karena lebih fleksibel dan menyederhanakan beberapa aspek dibandingkan 1.0.
  • Revocation Penting: Meskipun JWT sulit dibatalkan secara built-in, dalam skenario nyata, terutama yang sensitif, mekanisme revocation (misalnya menggunakan blacklist di server) tetap penting untuk menangani kasus token dicuri atau pengguna keluar (logout).
  • Scope di OAuth: Konsep scope di OAuth memungkinkan pengguna memberikan izin yang sangat spesifik kepada aplikasi pihak ketiga. Contoh: “Hanya baca profil” (read-only), “Posting ke feed” (write access), dsb. Ini meningkatkan keamanan karena aplikasi hanya mendapatkan akses seperlunya.

Kesimpulan

Jadi, bedanya JWT dan OAuth itu jelas banget:

  • JWT = Token (format data), bukti bahwa kamu punya “kunci” atau izin.
  • OAuth = Framework (protokol/mekanisme), proses untuk mendapatkan “kunci” atau izin itu secara aman, terutama untuk akses pihak ketiga.

Memahami perbedaan ini penting saat kamu berurusan dengan sistem otentikasi dan otorisasi modern. Keduanya sering bekerja sama, di mana OAuth menggunakan JWT sebagai format tokennya. OAuth menangani “bagaimana cara mendapatkan izin dengan aman?”, sementara JWT menangani “bagaimana cara mewakili izin itu dan memverifikasinya dengan efisien?”.

Sekarang kamu sudah tahu perbedaannya! Semoga penjelasan ini bikin kamu makin tercerahkan ya soal dunia backend dan keamanan aplikasi.

Gimana, sudah jelas kan perbedaan fundamental antara JWT dan OAuth? Atau mungkin kamu punya pengalaman menarik saat mengimplementasikan salah satunya? Yuk, share pendapat atau pertanyaanmu di kolom komentar di bawah!

Posting Komentar