SAML vs. OAuth 2.0: Kapan Harus Menggunakan XML atau JSON?

Dalam ekosistem keamanan digital modern, memilih protokol yang tepat untuk Identity & Access Management (IAM) adalah keputusan arsitektur yang krusial. Dua standar yang paling sering dibandingkan adalah Security Assertion Markup Language (SAML) dan OAuth 2.0 (Open Authorization).

Meskipun sering disebut dalam konteks yang sama, keduanya memiliki tujuan yang berbeda secara fundamental. SAML dirancang terutama untuk federasi identitas dan Single Sign-On berbasis browser, sedangkan OAuth 2.0 dirancang untuk delegasi otorisasi akses ke API atau layanan.

Perbedaan antara pendekatan berbasis XML pada SAML dan token yang sering digunakan dalam ekosistem OAuth bukan sekadar preferensi teknis, tetapi menentukan bagaimana identitas diverifikasi dan bagaimana akses diberikan.

Baca juga : SSO Protocols: Definisi, Jenis, dan Standar Modern Bagi Bisnis Anda

Apa Itu SAML (Security Assertion Markup Language)?

SAML adalah standar terbuka berbasis XML yang digunakan untuk pertukaran data autentikasi dan atribut identitas antara pihak yang berbeda, biasanya antara Identity Provider (IdP) dan Service Provider (SP). Standar ini telah lama menjadi fondasi keamanan enterprise, khususnya untuk implementasi Single Sign-On berbasis web.

Dengan SAML, pengguna dapat masuk ke berbagai aplikasi menggunakan satu set kredensial saja. Hal ini mengurangi kebutuhan untuk mengelola banyak password sekaligus menurunkan risiko keamanan akibat penggunaan ulang kredensial.

Dalam praktik organisasi, SAML berfungsi seperti paspor digital: IdP memverifikasi identitas pengguna, lalu mengirimkan bukti verifikasi tersebut ke aplikasi tujuan tanpa pernah mengirimkan password pengguna ke aplikasi tersebut.

Bagaimana Cara Kerja SAML?

Mekanisme SAML bergantung pada hubungan kepercayaan antara Identity Provider yang mengautentikasi pengguna dan Service Provider yang memberikan akses aplikasi.

Berikut alur kerja standar SAML:

1. User Access
   Pengguna mencoba membuka aplikasi bisnis melalui browser, misalnya CRM atau portal internal perusahaan.
2. Redirect ke Identity Provider
   Jika belum login, aplikasi membuat permintaan autentikasi SAML (AuthnRequest) lalu mengarahkan browser pengguna ke Identity Provider.
3. Authentication di IdP
   Pengguna memasukkan kredensial atau melakukan MFA. Jika sudah memiliki sesi aktif di IdP, proses ini bisa terjadi otomatis tanpa login ulang.
4. SAML Assertion Dibuat
   Setelah berhasil diverifikasi, IdP membuat SAML Assertion, yaitu dokumen XML bertanda tangan digital yang berisi identitas pengguna, waktu autentikasi, serta atribut akses.
5. Grant Access ke Aplikasi
   Browser mengirimkan assertion tersebut kembali ke aplikasi. Service Provider memvalidasi tanda tangan digital dan masa berlaku assertion. Jika valid, aplikasi membuat sesi login dan pengguna langsung masuk tanpa membuat akun baru atau memasukkan password lagi.

Baca juga : Apa Itu LDAP? Pengertian, Cara Kerja, dan Perannya dalam Manajemen Identitas

Apa Itu OAuth 2.0 (Open Authorization)?

Jika SAML berfokus pada autentikasi identitas pengguna, OAuth 2.0 berfokus pada delegasi otorisasi akses. OAuth adalah kerangka kerja standar terbuka yang memungkinkan aplikasi mendapatkan akses terbatas ke data atau layanan milik pengguna tanpa mengetahui password pengguna.

Sebagai contoh, ketika Anda menekan tombol “Login with Google”, atau memberi izin aplikasi untuk membaca kalender atau kontak, biasanya proses tersebut menggunakan OAuth.

Berbeda dengan SAML yang berbasis XML dan banyak digunakan di lingkungan enterprise berbasis browser, OAuth 2.0 menggunakan access token yang lebih ringan untuk komunikasi API. Token ini sering berupa JSON Web Token (JWT), meskipun spesifikasi OAuth sendiri tidak mewajibkan JWT atau JSON tertentu format token bisa bervariasi tergantung implementasi.

OAuth melibatkan empat komponen utama:

• Resource Owner : pengguna yang memiliki data
• Client : aplikasi yang meminta akses
• Authorization Server : sistem yang mengautentikasi pengguna dan menerbitkan token
• Resource Server : server API tempat data disimpan

Memahami komponen ini penting untuk merancang sistem IAM yang aman dan skalabel, terutama dalam integrasi aplikasi modern dan microservices.

Baca juga : 10 Rekomendasi Solusi IAM Terbaik di Tahun 2026

Bagaimana Cara Kerja OAuth 2.0?

OAuth bekerja dengan prinsip delegasi akses yang aman. Artinya, pengguna tidak perlu membagikan kata sandi ke aplikasi pihak ketiga. Sebagai gantinya, pengguna memberikan izin terbatas dalam bentuk access token.

Token ini berfungsi seperti kartu akses sementara, yang hanya mengizinkan aplikasi mengakses fungsi atau data tertentu sesuai persetujuan pengguna, tanpa memberikan kendali penuh atas akun.

Berikut alur kerja umum OAuth 2.0 (Authorization Code Flow):

1. Authorization Request
   Aplikasi (Client) meminta izin akses kepada pengguna, misalnya untuk membaca profil atau data tertentu.
2. User Consent to Authorization Server
   Pengguna diarahkan ke Authorization Server untuk login dan melihat izin apa saja yang diminta (scope).
3. Authorization Code ke Access Token
   Jika disetujui, Authorization Server memberikan authorization code ke aplikasi. Aplikasi menukarkan kode ini dengan access token (dan kadang refresh token).
4. Resource Access melalui API
   Aplikasi menggunakan access token tersebut untuk meminta data dari Resource Server (API). Server memvalidasi token, lalu memberikan akses sesuai izin tanpa pernah menerima password pengguna.

Perbedaan Utama: SAML vs. OAuth

Memilih antara SAML dan OAuth sering kali membingungkan karena keduanya bisa digunakan untuk login. Namun, tabel berikut merinci perbedaan teknis mendasar yang memisahkan fungsi keduanya dalam arsitektur keamanan:

Kapan Harus Menggunakan SAML vs. OAuth?

Setelah memahami mekanisme teknisnya, pertanyaan strategis berikutnya adalah kapan waktu yang tepat menerapkan masing-masing protokol. Tidak ada satu solusi untuk semua kebutuhan. Pilihan harus disesuaikan dengan arsitektur aplikasi, model akses pengguna, serta pengalaman pengguna (UX) yang ingin dicapai.

Kapan Menggunakan SAML?

SAML sangat cocok untuk lingkungan korporat yang membutuhkan federasi identitas terpusat, integrasi SaaS enterprise, serta kompatibilitas dengan sistem lama. Protokol ini paling optimal ketika browser web menjadi klien utama dan organisasi memiliki Identity Provider terpusat.

Gunakan SAML jika kebutuhan bisnis mencakup:

• Enterprise Single Sign-On (SSO)
  Ketika karyawan perlu login sekali ke portal perusahaan lalu otomatis mendapat akses ke HRIS, ERP, CRM, email, dan aplikasi SaaS lainnya tanpa login ulang. SAML dirancang khusus untuk skenario SSO lintas domain berbasis browser.

• Lingkungan dengan regulasi ketat (pemerintahan, finansial, enterprise besar)
  SAML sering dipilih karena model trust yang jelas antara IdP dan Service Provider, dukungan tanda tangan digital XML, serta kematangan implementasinya dalam audit keamanan enterprise.
• Intranet & Legacy Systems
  Banyak aplikasi on-premise lama sudah mendukung SAML tetapi tidak mendukung OAuth modern. Dalam konteks modernisasi bertahap, SAML menjadi jembatan antara sistem lama dan layanan cloud.
• B2B Identity Federation
  Jika organisasi perlu memberikan akses ke mitra bisnis atau klien korporat menggunakan identitas dari perusahaan mereka sendiri (federated login), SAML menyediakan model federasi identitas yang stabil dan terstandarisasi.
• Integrasi SaaS berbasis browser
  Sebagian besar aplikasi enterprise seperti HR, ticketing, atau document management mendukung SAML sebagai metode SSO default.

Baca juga : Enterprise SSO: Fondasi Keamanan Identitas untuk Bisnis Skala Besar

Kapan Menggunakan OAuth 2.0?

OAuth 2.0 adalah pilihan utama untuk aplikasi modern yang membutuhkan delegasi akses berbasis token, integrasi API, serta dukungan lintas platform (web, mobile, backend, dan perangkat pintar). OAuth tidak dirancang khusus untuk autentikasi pengguna, tetapi untuk memberikan akses terbatas ke sumber daya.

Pertimbangkan OAuth 2.0 jika kebutuhan mencakup:

• Aplikasi Mobile (Android/iOS)
  OAuth dirancang untuk bekerja dengan baik pada aplikasi native melalui mekanisme token dan redirect aman. SAML masih bisa digunakan melalui browser login eksternal, tetapi OAuth biasanya jauh lebih sederhana dan ramah arsitektur mobile.
• Modern Web Apps / Single Page Applications (SPA)
  Aplikasi berbasis React, Angular, atau Vue lebih cocok menggunakan OAuth karena token ringan dan mudah digunakan untuk komunikasi API berulang tanpa reload halaman.
• Consumer “Social Login”
  Fitur seperti “Masuk dengan Google” atau “Masuk dengan LinkedIn” umumnya menggunakan OAuth 2.0 untuk otorisasi, sering dikombinasikan dengan OpenID Connect (OIDC) untuk autentikasi identitas pengguna.
• API Integrations & Microservices
  Untuk komunikasi antar layanan (machine-to-machine), proteksi endpoint API, atau akses pihak ketiga ke data pengguna, OAuth adalah standar industri karena mendukung scope, expiry token, dan kontrol akses granular.
• IoT dan perangkat dengan sumber daya terbatas
  Perangkat pintar atau sistem embedded lebih mudah menangani token ringan dibandingkan dengan dokumen XML besar, sehingga OAuth lebih praktis dalam ekosistem IoT.

Baca juga : CIAM: Kunci Meningkatkan Keamanan Data Konsumen

Bisakah SAML Digunakan Bersama OAuth?

Jawabannya adalah ya, dan ini merupakan praktik yang sangat umum dalam lingkungan hibrida modern. Banyak arsitektur keamanan saat ini memang sengaja menggabungkan kekuatan Security Assertion Markup Language (SAML) dan OAuth 2.0 untuk saling melengkapi kelemahan masing-masing. SAML unggul pada autentikasi identitas perusahaan, sementara OAuth unggul pada pemberian izin akses berbasis token.

Dalam implementasi gabungan, peran keduanya biasanya dibagi secara jelas:

SAML untuk Masuk (AuthN)

SAML digunakan sebagai lapisan otentikasi awal untuk memastikan identitas pengguna. Karyawan masuk menggunakan kredensial direktori perusahaan misalnya melalui sistem seperti Active Directory untuk membuktikan siapa mereka dan mendapatkan akses ke portal utama organisasi.

Proses ini memungkinkan perusahaan menerapkan Single Sign-On (SSO) yang aman dan terpusat, sehingga pengguna hanya perlu login sekali untuk mengakses berbagai layanan internal.

OAuth untuk Akses (AuthZ)

Setelah pengguna berhasil masuk melalui SAML, aplikasi portal kemudian menggunakan OAuth untuk mengelola izin akses ke sumber daya spesifik. Misalnya, portal internal dapat meminta token OAuth agar dapat menampilkan pratinjau dokumen dari Google Drive atau menarik data pelanggan dari Salesforce di dalam dasbor pengguna tanpa harus meminta password ulang.

Dengan pendekatan ini, akses diberikan secara terbatas, terukur, dan dapat dicabut kapan saja tanpa memengaruhi sesi login utama.

Penting untuk dicatat bahwa mengelola integrasi ganda seperti ini membutuhkan strategi manajemen identitas dan akses terpusat yang matang. Tanpa kontrol yang jelas terhadap alur autentikasi dan otorisasi, kombinasi dua protokol justru berpotensi menciptakan kompleksitas tambahan dan celah keamanan baru.

Kesimpulan

Perdebatan antara SAML dan OAuth 2.0 bukanlah tentang mana yang lebih baik, melainkan mana yang lebih tepat untuk kebutuhan spesifik organisasi. SAML tetap menjadi tulang punggung dalam manajemen identitas internal perusahaan dan implementasi SSO korporat, sementara OAuth mendominasi pengembangan aplikasi modern, integrasi API, serta ekosistem layanan berbasis cloud.

Bagi pemimpin IT, tantangan sebenarnya bukan memilih satu pemenang, melainkan mengorkestrasi keduanya agar bekerja harmonis dalam satu arsitektur keamanan terpadu. Kesalahan dalam penerapan protokol ini tidak hanya berdampak pada pengalaman pengguna yang buruk, tetapi juga dapat membuka risiko kebocoran data sensitif.

FAQ