Belajar Keycloak - Overview Protokol Identitas: OAuth2, OIDC, SAML, SCIM

#Pendahuluan

Episode 1 menjelaskan mengapa SSO dibutuhkan: memusatkan autentikasi untuk menyelesaikan password fatigue dan memperkuat kontrol akses. Episode 2 ini memperkenalkan empat protokol yang menjadi mesin di balik SSO: OAuth 2.0, OpenID Connect (OIDC), SAML 2.0, dan SCIM 2.0. Kalian tidak perlu menghafal detail semuanya sekarang — cukup pahami peran masing-masing, karena episode-episode berikutnya akan membedahnya satu per satu.

#OAuth 2.0 — Kerangka Authorisasi

OAuth 2.0 (RFC 6749) adalah kerangka authorisasi, bukan protokol autentikasi. Ia menjawab pertanyaan "apa yang boleh diakses" — bukan "siapa kamu".

• Delegated authorization — pengguna memberikan izin kepada aplikasi untuk mengakses resource miliknya tanpa menyerahkan password.
• Access tokens — bukti izin yang dibawa klien saat meminta resource ke API.
• Scopes dan permissions — membatasi cakupan izin, misalnya hanya baca atau hanya email.
• Grant types (flows) — mekanisme berbeda untuk mendapatkan token sesuai konteks: web app, aplikasi mobile, service-to-service, dan lainnya.

#Grant Types Secara Ringkas

Grant type adalah "cara" OAuth 2.0 menerbitkan token, dan pilihannya bergantung pada tipe aplikasi:

• Authorization Code — untuk web app dengan backend; paling aman, menjadi standar.
• Implicit — untuk SPA lama; sudah deprecated karena token terekspos di URL.
• Client Credentials — untuk service-to-service; tanpa keterlibatan pengguna.
• Device Code — untuk perangkat tanpa browser seperti smart TV.

Setiap grant type akan dibedah satu per satu di episode-episode fase 2.

Intuisi terbaik: OAuth 2.0 seperti kunci valet. Kalian tidak menyerahkan kunci rumah, melainkan kunci khusus yang hanya bisa membuka mobil, hanya hari ini, dan hanya oleh orang yang kalian tunjuk.

#OpenID Connect — Lapisan Autentikasi di Atas OAuth 2.0

OpenID Connect (OIDC) dibangun di atas OAuth 2.0 dan menambahkan lapisan autentikasi. Jika OAuth 2.0 menjawab "apa yang boleh diakses", OIDC menjawab "siapa yang login dan bagaimana identitasnya diverifikasi".

• ID tokens (JWT) — klaim identitas pengguna yang ditandatangani; ini tambahan utama OIDC di atas OAuth 2.0.
• UserInfo endpoint — endpoint tambahan untuk mengambil profil pengguna.
• Identity federation — identitas pengguna dibawa dari IdP ke aplikasi secara terstandar.
• Modern web SSO — inilah protokol yang paling direkomendasikan untuk aplikasi baru.

Contoh payload ID token yang biasanya kalian temukan:

{
  "sub": "f8a9c1e2-4b3d-4f6a-9c2e-1d5b8a7c3e2f",
  "iss": "http://localhost:8080/realms/belajar",
  "aud": "portal-app",
  "email": "budi@example.com",
  "email_verified": true,
  "preferred_username": "budi",
  "exp": 1770000000,
  "iat": 1769999700
}

Klaim sub adalah identitas unik pengguna, iss menunjukkan issuer, dan aud menunjukkan audiens yang dituju. Klaim ini akan dibedah mendalam di episode tentang OIDC fundamentals.

#SAML 2.0 — Standar SSO Enterprise

SAML 2.0 adalah protokol berbasis XML yang menjadi standar SSO enterprise sejak awal 2000-an.

• XML-based protocol — pesan dan assertion direpresentasikan sebagai dokumen XML.
• Enterprise SSO standard — banyak aplikasi enterprise besar masih berbicara SAML.
• Service Provider (SP) dan Identity Provider (IdP) — SP adalah aplikasi, IdP adalah pusat autentikasi (Keycloak).
• Assertions — pernyataan XML tentang autentikasi, atribut, dan keputusan authorisasi.
• Legacy tapi tetap luas dipakai — jangan diabaikan; banyak aplikasi lama dan SaaS masih memakai SAML.

SAML adalah pilihan kalian saat berhadapan dengan aplikasi enterprise legacy atau SaaS yang tidak mendukung OIDC.

#Bentuk Assertion

Assertion SAML adalah dokumen XML yang ditandatangani dan berisi tiga jenis pernyataan:

• Authentication statement — kapan dan bagaimana pengguna diautentikasi.
• Attribute statement — atribut pengguna seperti nama dan email.
• Authorization decision — keputusan apakah akses diizinkan.

Karena berbentuk XML dan memakai sertifikat, assertion SAML tetap dipercaya meski berjalan di masa transisi menuju OIDC.

#SCIM 2.0 — Provisioning Pengguna

SCIM (System for Cross-domain Identity Management) adalah standar untuk manajemen identitas lintas sistem — berbeda dari ketiga protokol sebelumnya yang fokus pada login.

• User provisioning dan deprovisioning — membuat, memperbarui, dan menonaktifkan akun pengguna secara otomatis.
• Standardized REST API — operasi CRUD standar seperti POST /Users dan DELETE /Users/{id}.
• Identity lifecycle management — memastikan akun dibuat saat karyawan bergabung dan dicabut saat keluar.

SCIM menjawab pertanyaan yang berbeda: bukan "bagaimana pengguna login", melainkan "bagaimana akun pengguna dikelola secara konsisten di semua sistem".

#Perbandingan Protokol

Rangkuman cepat untuk membedakan keempatnya:

Dua perbandingan yang paling sering menimbulkan kebingungan:

• OAuth 2.0 vs OIDC — OAuth 2.0 hanya authorisasi; OIDC menambahkan autentikasi lewat ID token. Gunakan OIDC ketika kalian perlu tahu identitas pengguna.
• OIDC vs SAML — keduanya protokol autentikasi SSO, tetapi OIDC modern (JSON, JWT) sedangkan SAML legacy (XML). Untuk aplikasi baru pilih OIDC; untuk enterprise legacy pilih SAML.

#Kapan Memakai Protokol Apa

Panduan praktis untuk memilih:

• Aplikasi web dan mobile baru — pakai OIDC; ekosistem dan library-nya paling matang.
• API dan service — pakai OAuth 2.0; fokus pada authorisasi dan access token.
• Aplikasi enterprise legacy dan SaaS lama — pakai SAML; itulah bahasa yang mereka mengerti.
• Sinkronisasi akun otomatis — pakai SCIM; untuk provisioning, bukan login.

Protokol-protokol ini tidak saling eksklusif dan sering hidup berdampingan dalam satu organisasi.

#Dukungan Keycloak

Keycloak dirancang untuk mendukung semuanya:

• Native OIDC/OAuth 2.0 — dukungan penuh termasuk semua grant type standar dan PKCE.
• SAML 2.0 — Keycloak bisa bertindak sebagai IdP maupun SP.
• SCIM via extensions — provisioning SCIM tersedia lewat ekstensi yang diinstal ke Keycloak.
• Protocol bridging — Keycloak bisa menjadi jembatan antar protokol, misalnya menerima SAML dari IdP lain lalu meneruskan identitas ke aplikasi OIDC.

Inilah alasan utama Keycloak populer sebagai platform identitas terpusat: satu server melayani beragam protokol.

#Penutup

Episode 2 memberi kalian peta empat protokol identitas: OAuth 2.0 untuk authorisasi, OIDC untuk autentikasi modern, SAML 2.0 untuk enterprise legacy, dan SCIM 2.0 untuk provisioning. Keycloak mendukung semuanya, sehingga bisa menjadi jembatan antar protokol.

Inti yang harus dibawa pulang:

• OAuth 2.0 = authorisasi, OIDC = autentikasi — OIDC membangun ID token di atas OAuth 2.0.
• SAML berbasis XML dan tetap hidup — pilih untuk aplikasi enterprise legacy.
• SCIM berbeda urusannya — mengelola lifecycle akun, bukan login.
• Keycloak adalah penyatu protokol — satu server, banyak protokol.

Di episode 3 berikutnya, kalian masuk ke bagian dalam Keycloak: arsitektur dan core concepts — realm, client, user, role, group, dan bagaimana semuanya tersusun.