OAuth dan SSO

credit: Deepseek

Daftar Isi

Penjelasan Singkat OAuth dan SSO

OAuth 2.0

OAuth 2.0 adalah kerangka otorisasi yang memungkinkan aplikasi pihak ketiga memperoleh akses terbatas ke sumber daya pengguna di server lain tanpa harus membagikan kredensial pengguna. OAuth berfokus pada otorisasi, bukan autentikasi. Komponen utama:

Single Sign-On (SSO)

SSO adalah mekanisme autentikasi yang memungkinkan pengguna masuk ke beberapa aplikasi/sistem dengan satu set kredensial. Pengguna hanya perlu login sekali pada Identity Provider (IdP) dan kemudian dapat mengakses berbagai Service Provider (SP) tanpa login ulang. SSO sering dibangun di atas protokol seperti OpenID Connect (OIDC) (lapisan identitas di atas OAuth 2.0) atau SAML 2.0.

Perbedaan utama: OAuth 2.0 adalah tentang otorisasi terdelegasi, sedangkan SSO adalah tentang autentikasi terpusat.

Cara Kerja Singkat

Cara Kerja OAuth 2.0 (Authorization Code Grant)

  1. Pengguna mengklik “Login dengan X” di aplikasi client.
  2. Client mengarahkan browser pengguna ke Authorization Server dengan parameter seperti client_id, redirect_uri, scope, state.
  3. Pengguna login dan menyetujui permintaan akses di Authorization Server.
  4. Authorization Server mengembalikan authorization code ke browser pengguna yang kemudian dikirim ke redirect_uri client.
  5. Client menukar authorization code dengan access token (dan opsional refresh token) melalui permintaan back-channel ke Authorization Server, disertai client_secret.
  6. Client menggunakan access token untuk mengakses resource di Resource Server.

Cara Kerja SSO (menggunakan OIDC / SAML)

OIDC (OpenID Connect):

SAML 2.0:

Analisis Potensi Kerentanan dan Cara Eksploitasi

Kerentanan pada OAuth 2.0

  1. Validasi redirect_uri yang Lemah / Tidak Ketat
    • Deskripsi: Authorization Server menerima redirect_uri yang tidak persis sama dengan yang didaftarkan, misalnya subdomain liar, path traversal, atau parameter tambahan yang dapat dimanipulasi.
    • Eksploitasi: Penyerang mengelabui korban mengakses link OAuth dengan redirect_uri yang dikontrol penyerang. Setelah korban login, authorization code dikirim ke penyerang. Penyerang menukarnya dengan token dan mengambil alih akun korban.
    • Cara menemukan:
      • Ubah nilai redirect_uri ke domain penyerang atau domain mirip (misal https://legitimate.com.attacker.com).
      • Coba tambahkan path traversal (/../malicious) atau parameter terbuka di akhir (https://app.com/callback?url=https://evil.com).
      • Cek apakah Authorization Server melakukan pencocokan eksak atau hanya prefix/suffix.
  2. CSRF pada Aliran OAuth (State Parameter Missing/Weak)
    • Deskripsi: Tidak ada atau lemahnya parameter state yang mengikat permintaan OAuth dengan sesi pengguna asli.
    • Eksploitasi: Penyerang memulai aliran OAuth menggunakan akunnya sendiri, mendapatkan authorization code, lalu menghentikan aliran. Penyerang memaksa korban untuk mengunjungi link callback yang berisi authorization code penyerang. Jika aplikasi client tidak memvalidasi state, sesi korban akan terikat dengan akun penyerang. Penyerang bisa melihat data sensitif korban yang disimpan di akun penyerang (account hijacking via forced linking).
    • Cara menemukan: Hapus parameter state dari request; jika masih berhasil, rentan. Buat dua sesi browser berbeda, tukar nilai state, lihat apakah client mendeteksi ketidakcocokan.
  3. Insufficient PKCE Protection (Authorization Code Injection)
    • Deskripsi: Pada public clients (SPA, mobile), jika PKCE tidak diterapkan, authorization code dapat disadap dan digunakan oleh penyerang.
    • Eksploitasi: Penyerang menangkap authorization code dari korban melalui malicious app, log, atau referer header. Karena tidak ada code_verifier, penyerang dapat langsung menukar code dengan token.
    • Cara menemukan: Periksa apakah aliran Authorization Code memerlukan code_challenge/code_verifier. Coba tukar code tanpa mengirimkan code_verifier.
  4. Kebocoran Token melalui URL Fragment, Referer, atau Log
    • Deskripsi: Token yang dikembalikan di URL fragment (Implicit grant) atau URL query string dapat terekspos di log server, riwayat browser, atau header Referer.
    • Eksploitasi: Jika aplikasi menggunakan Implicit Flow, token di fragment bisa disadap oleh skrip jahat melalui Referer ke situs eksternal. Cukup cek apakah token muncul di request menuju third-party.
    • Cara menemukan: Pantau lalu lintas jaringan, lihat apakah access token dikirim ke domain pihak ketiga melalui Referer. Gunakan skrip yang mengakses window.location.hash.
  5. Client Secret pada Public Clients
    • Deskripsi: Aplikasi client-side (SPA, mobile) tidak dapat menyimpan client_secret dengan aman, namun masih digunakan.
    • Eksploitasi: Penyerang mengekstrak client_secret dari kode aplikasi, lalu menyamar sebagai aplikasi resmi untuk mendapatkan token dengan hak akses lebih.
    • Cara menemukan: Dekompilasi APK/IPA, cari di source JavaScript, atau strings.
  6. Token Scope yang Tidak Dibatasi / Privilege Escalation
    • Deskripsi: Client meminta scope yang terlalu luas, atau server tidak memvalidasi scope yang diminta.
    • Eksploitasi: Ubah parameter scope pada request OAuth untuk mencakup akses ke resource sensitif. Jika server mengeluarkan token dengan scope tersebut, penyerang dapat mengakses data lain.
    • Cara menemukan: Modifikasi nilai scope (tambah/ubah) dan periksa apakah token yang dihasilkan memberikan akses lebih.

Kerentanan pada SSO

  1. SAML Signature Bypass / XML Signature Wrapping (XSW)
    • Deskripsi: Implementasi validasi SAML assertion hanya memeriksa elemen yang salah akibat manipulasi struktur XML, sehingga penyerang bisa menyisipkan assertion palsu yang lolos verifikasi.
    • Eksploitasi: Penyerang mencegat SAML Response, mengubah struktur XML (memindahkan signature ke elemen yang tidak divalidasi), dan memasukkan elemen Assertion buatan dengan identitas korban. Jika SP hanya mengambil assertion pertama tanpa memvalidasi keseluruhan pohon, penyerang bisa masuk sebagai korban.
    • Cara menemukan: Kirim SAML Response yang telah dimodifikasi dengan berbagai teknik XSW. Gunakan tools seperti SAML Raider.
  2. SAML Replay Attack
    • Deskripsi: SAML Response tidak memiliki batasan waktu atau mekanisme anti-replay yang kuat, sehingga response yang sah bisa digunakan kembali.
    • Eksploitasi: Penyerang mendapatkan SAML Response yang masih valid, lalu mengirimkannya kembali ke SP untuk mendapatkan sesi.
    • Cara menemukan: Simpan SAML Response yang dikeluarkan untuk sesi Anda, logout, lalu replay response tersebut. Jika berhasil, tidak ada pemeriksaan NotOnOrAfter atau ID unik yang dicegah pengulangan.
  3. Penerbitan Token untuk Identity Provider yang Tidak Terpercaya (IdP Confusion)
    • Deskripsi: SP tidak membatasi IdP mana yang dapat menerbitkan assertion. Penyerang bisa mendirikan IdP sendiri dan mengarahkan korban untuk login di sana, lalu assertion dari IdP jahat diterima oleh SP.
    • Eksploitasi: Jika SP memungkinkan pengguna memilih IdP, penyerang mengirim link SSO yang mengarahkan ke IdP penyerang. SP memvalidasi assertion dari IdP itu dan mengizinkan akses.
    • Cara menemukan: Coba daftarkan IdP Anda sendiri di SP, atau modifikasi parameter Issuer/entityID pada SAML AuthnRequest menuju IdP arbitrer.
  4. Session Fixation pada SSO
    • Deskripsi: SP menerima ID sesi dari luar sebelum autentikasi selesai, dan setelah SSO berhasil sesi itu tidak diregenerasi.
    • Eksploitasi: Penyerang menetapkan ID sesi tertentu pada korban (misal lewat URL), korban login via SSO, sesi tetap sama, penyerang menggunakan ID sesi tersebut untuk mengakses akun korban.
    • Cara menemukan: Sebelum login, catat cookie sesi. Lakukan login SSO, periksa apakah cookie sesi berubah. Jika tidak, mungkin rentan session fixation.
  5. Kebocoran Klaim / Informasi Sensitif pada ID Token / SAML Assertion
    • Deskripsi: ID Token atau assertion berisi informasi pribadi yang tidak seharusnya dibagikan ke client, atau client meneruskannya tanpa perlu.
    • Eksploitasi: Tidak langsung, tapi penyerang bisa mencuri token dan membaca informasi pengguna (PII disclosure).
    • Cara menemukan: Decode ID Token (JWT) atau bongkar SAML assertion, periksa atribut yang dikirim. Terlalu banyak informasi.
  6. Tidak Validasi Audience / Recipient
    • Deskripsi: OIDC/SAML tidak memeriksa bahwa token/assertion ditujukan untuk client/SP ini, sehingga token yang dikeluarkan untuk aplikasi lain bisa digunakan.
    • Eksploitasi: Dapatkan ID Token yang valid untuk aplikasi A, gunakan sebagai kredensial di aplikasi B yang memiliki IdP sama. Jika aplikasi B tidak memvalidasi aud (audience) dengan benar, token diterima.
    • Cara menemukan: Ambil token/assertion dari aplikasi lain yang menggunakan IdP sama, kirim ke endpoint aplikasi target.

Langkah Mitigasi

Mitigasi OAuth 2.0

Mitigasi SSO

Checklist Pengujian Keamanan

OAuth 2.0 / OIDC

SSO (SAML)

Seluruh checklist di atas dapat digunakan sebagai dasar pengujian penetrasi atau audit keamanan. Pastikan setiap poin diuji secara manual menggunakan burp suite, SAML Raider, atau tools sejenis, serta disesuaikan dengan konteks aplikasi.