Belajar Keycloak - Social Login & Identity Brokering

#Pendahuluan

Di episode 15 kalian menghubungkan Keycloak dengan direktori eksternal seperti LDAP dan Active Directory. Episode 16 ini menambahkan pintu masuk yang berbeda: social login lewat identity brokering. Kalian akan mengizinkan user masuk dengan akun Google, GitHub, Facebook, dan lainnya — sementara Keycloak tetap menjadi pusat yang memegang sesi, menyambungkan akun eksternal ke identitas internal, dan memperkaya profil user dari claims penyedia.

#Apa Itu Identity Brokering

Identity brokering adalah pola di mana Keycloak berperan sebagai perantara: ia tidak memegang kredensial user, tetapi menerima identitas dari penyedia eksternal (broker) dan meneruskannya ke aplikasi. Berbeda dengan user federation yang membaca langsung dari direktori, di sini autentikasi terjadi di sisi penyedia, lalu hasilnya diserahkan ke Keycloak.

Secara teknis, tiap penyedia eksternal adalah sebuah identity provider yang terdaftar di realm lewat tab Identity Providers di admin console. Keycloak menjadi brokered IdP bagi aplikasi-aplikasinya: aplikasi tetap berbicara dengan Keycloak (OIDC atau SAML), tidak pernah tahu bahwa user sebenarnya login di Google.

#Penyedia Social Identity yang Umum

Redirect URI di kolom terakhir adalah alamat yang harus kalian daftarkan di setiap portal developer penyedia. Tanpa daftar ini, penyedia akan menolak callback dengan error redirect_uri_mismatch.

#Menyiapkan OAuth App di Sisi Penyedia

Langkahnya selalu dimulai dari portal developer penyedia:

1. Buka portal developer penyedia (Google Cloud, GitHub, dan lain-lain)
2. Buat aplikasi atau OAuth client baru
3. Catat client ID dan client secret yang diberikan
4. Daftarkan redirect URI Keycloak untuk broker tersebut
5. Pilih scope yang ingin diminta (email, profile)
6. Simpan dan catat kredensialnya

Contoh daftar redirect URI yang didaftarkan di portal developer:

https://keycloak.example.com/realms/demo/broker/google/endpoint
https://keycloak.example.com/realms/demo/broker/github/endpoint
https://keycloak.example.com/realms/demo/broker/facebook/endpoint

client_id dan client_secret lalu dimasukkan ke Keycloak pada tab Identity Providers untuk provider yang bersangkutan.

#Scope dan Attribute Mapping

Scope menentukan data apa yang diminta dari penyedia — paling dasar adalah email dan profile. Di Keycloak, claims yang diterima bisa dipetakan ke atribut profil user lewat mapper. Misalnya claim email dari Google dijadikan nilai email user Keycloak, dan nama dari profile dipakai mengisi nama depan serta nama belakang.

Aturan praktisnya: minta scope sesedikit mungkin. Setiap data yang tidak diminta tidak akan diterima, dan setiap data yang diterima adalah tanggung jawab kalian untuk melindunginya.

#Alur First Broker Login

Saat user pertama kali login lewat penyedia eksternal, Keycloak menjalankan first broker login flow — alur khusus untuk menghubungkan identitas eksternal ke akun internal:

1. User memilih tombol login Google atau GitHub.
2. User diautentikasi di penyedia dan diarahkan kembali ke Keycloak.
3. Keycloak mencari apakah ada akun lokal yang cocok (misalnya lewat email).
4. Bila tidak ada, Keycloak bisa membuat akun baru atau meminta user memilih alur lanjutan.
5. Bila ada, user diarahkan untuk menghubungkan (link) akun eksternal dengan akun lokalnya.

#Account Linking

Account linking adalah proses menggabungkan identitas eksternal dengan akun Keycloak. Ada dua pendekatan:

• Otomatis — Keycloak mencocokkan claim seperti email dengan akun yang sudah ada, lalu menghubungkan keduanya langsung.
• Manual — user diminta login ke akun lokalnya terlebih dahulu sebelum kedua akun dihubungkan, mencegah pembajakan akun lewat alamat email yang dipalsukan.

Untuk keamanan, mekanisme manual lebih kuat: tanpa itu, siapa pun yang menguasai akun Google dengan alamat email milik user lain bisa membajak akun tersebut.

#User Profile Enrichment

Claims dari penyedia tidak hanya dipakai untuk masuk — bisa juga memperkaya profil user. Mapper mengisi atribut seperti lokasi, bahasa, atau avatar dari data penyedia. Namun perhatikan juga trust levels: data yang diklaim penyedia tidak selalu terverifikasi. Klaim email_verified dari penyedia harus diperlakukan berbeda dari email yang diverifikasi Keycloak sendiri.

#Custom Identity Providers

Selain penyedia sosial, Keycloak mendukung identity provider kustom:

• Generic OIDC provider — penyedia apa pun yang mengimplementasikan OpenID Connect; tinggal isi endpoint authorization, token, dan JWKS.
• Generic SAML provider — IdP SAML eksternal didaftarkan sebagai broker, membalik peran dari episode 13.
• Corporate IdP — portal identitas perusahaan yang hanya boleh diakses dari jaringan internal, dihubungkan sebagai sumber otorisasi.

Ini membuat Keycloak bisa menjadi hub federation: aplikasi berbicara ke satu Keycloak, sementara di belakangnya Keycloak berbicara ke Google, GitHub, IdP korporat, dan LDAP sekaligus.

#Alias dan Kunci Provider

Setiap identity provider memakai sebuah alias yang menjadi bagian dari redirect URI broker, misalnya google, github, atau corporate. Alias ini juga menjadi identitas yang dipakai Keycloak untuk menautkan akun: ketika seorang user terhubung ke lebih dari satu penyedia, Keycloak mencatat setiap kombinasi alias dan identitas eksternalnya.

Untuk keamanan, ada beberapa kebiasaan yang perlu dijaga:

• Simpan client_secret di tempat aman — ia adalah kredensial yang menautkan Keycloak dengan penyedia, setara dengan password.
• Rotasi kredensial di portal developer saat ada indikasi kebocoran.
• Aktifkan PKCE pada provider yang mendukungnya (misal OIDC) agar alur authorization code lebih kuat terhadap penyalahgunaan kode.
• Batasi penyedia yang boleh dipakai di lingkungan production sesuai kebutuhan bisnis — tidak semua realm butuh Twitter.

client_id dan client_secret yang masuk ke Keycloak sebaiknya diambil langsung dari portal developer, bukan disalin lewat email atau pesan yang bisa dicegat.

#Penutup

Pada episode 16 ini, kalian membuka social login lewat identity brokering: konsep broker dan tab Identity Providers; penyedia Google, GitHub, Facebook, Microsoft, LinkedIn, dan Twitter; pembuatan OAuth app dengan client ID, client secret, dan redirect URI; pemetaan scope serta atribut; alur first broker login, account linking, dan enrichmen profil; plus identity provider kustom berbasis OIDC dan SAML.

Inti yang harus dibawa pulang:

• Brokering menyerahkan autentikasi ke penyedia sementara Keycloak tetap memegang sesi dan profil.
• Redirect URI harus persis — perbedaan satu karakter saja memicu error redirect_uri_mismatch.
• Account linking otomatis perlu hati-hati — verifikasi kepemilikan email sebelum menghubungkan akun.
• Penyedia kustom OIDC dan SAML menjadikan Keycloak hub federation bagi semua sumber identitas.

Di episode 17 berikutnya, kita melengkapi manajemen identitas dari sisi provisioning: SCIM — protokol REST untuk membuat, mengubah, dan menghapus user lintas sistem secara otomatis.