Belajar Authentik - OAuth Sources (Social Login)

#Pendahuluan

Selama fase 3 dan 5, Authentik berperan sebagai Identity Provider — ia menerbitkan token dan assertion untuk aplikasi. Di episode 16 peran ini dibalik: Authentik menjadi Relying Party yang mempercayai identity provider lain. Fasilitasnya disebut source, dan kasus paling umum adalah OAuth sources — login sosial dengan GitHub, Google, atau Discord.

Apa gunanya? Kalian tetap ingin Authentik menjadi satu pintu masuk (single source of truth), tetapi pengguna tidak perlu mendaftar akun baru — mereka login dengan akun GitHub atau Google yang sudah mereka miliki. Authentik memetakan profil mereka, membuat user internal, lalu semua aplikasi yang dilindungi Authentik tetap memakai sesi Authentik. Social login hanyalah jalan masuk, bukan pengganti Authentik.

Analogi: gedung kalian tidak lagi menerbitkan kartu identitas sendiri. Sebagai gantinya, kalian menerima kartu identitas nasional (akun Google/GitHub) sebagai bukti, lalu mencatatnya dalam buku tamu internal dan memberi akses berdasarkan catatan itu.

#Konsep Source

Source adalah koneksi dari identity provider eksternal ke Authentik. Tipe yang tersedia:

• OAuth source — Google, GitHub, Discord, GitLab, Microsoft, dan OAuth2 generik.
• SAML source — Authentik sebagai SP terhadap IdP SAML lain.
• LDAP source — sinkronisasi user dari OpenLDAP/Active Directory (episode 17).
• Plex source — memakai akun Plex.

Fokus episode ini: OAuth source. Konsepnya selalu sama: mendaftarkan aplikasi OAuth di provider eksternal untuk mendapat client_id dan client_secret, lalu memasangnya di Authentik.

#Membuat OAuth App di Provider Eksternal

Ambil contoh GitHub. Di GitHub, buka Developer settings → OAuth Apps → New OAuth App, lalu isi:

• Application name — nama aplikasi, misalnya Authentik.
• Homepage URL — URL portal Authentik.
• Authorization callback URL — alamat callback yang ditentukan Authentik:

Callback URL OAuth source

https://authentik.example.com/source/oauth/callback/github/

Ganti github dengan slug source. Setelah terdaftar, GitHub memberikan Client ID dan Client Secret — dua nilai ini yang menjadi kredensial koneksi.

#Membuat Source di Authentik

Di Admin interface, buka Directory → Federation and Social login → Create, pilih tipe source, lalu isi:

• Name — nama tampilan source.
• Slug — pengenal URL; harus sama dengan slug di callback URL GitHub.
• Consumer Key — Client ID dari provider eksternal.
• Consumer Secret — Client Secret dari provider eksternal.
• Scopes — scope tambahan yang diminta ke provider (opsional).

Untuk provider dengan tipe bawaan seperti GitHub, Google, dan Discord, URL authorization, token, dan profile diisi otomatis oleh Authentik — kalian hanya memasukkan key dan secret. Untuk Generic OAuth2, kalian mengisi Authorization URL, Access Token URL, dan Profile URL secara manual, atau cukup menempel OIDC well-known URL (.well-known/openid-configuration) jika provider mendukungnya.

Setelah source tersimpan, Authentik secara otomatis membuat flow autentikasi dan enrollment milik source tersebut, plus sebuah aplikasi untuk source itu.

#Mengikat Source ke Flow

Ini bagian yang menentukan perilaku login. Setiap source diikat ke dua flow:

• Authentication flow — dijalankan saat user yang sudah dikenal login lewat source.
• Enrollment flow — dijalankan saat user belum dikenal — di sinilah akun internal baru dibuat.

Flow ini bekerja dengan aturan pencocokan user. Authentik menyediakan mode:

• identifier — mencocokkan berdasarkan identifier unik dari provider.
• email_link — user baru dengan email yang cocok dengan user internal akan otomatis terhubung (link).
• email_deny — user baru yang emailnya sudah dipakai user lain akan ditolak.
• username_link / username_deny — sama, tetapi berdasarkan username.

User yang dibuat lewat source disimpan di path goauthentik.io/sources/<slug> — kalian bisa melihatnya di halaman user, dan membedakan user internal dari user hasil source.

#Memetakan Profil User

Profil dari provider eksternal dipetakan ke user internal lewat property mappings. Untuk GitHub, Authentik menyediakan mapping bawaan: username diambil dari field login, email dari daftar email GitHub, dan nama dari name.

Untuk kebutuhan khusus, buat mapping kustom. Contoh mapping yang menandai asal user:

Property mapping OAuth source — asal user

return context["source"].slug

Konteks yang tersedia di ekspresi source antara lain source (objek source), oauth_userinfo (data profil mentah dari provider), dan token (token OAuth). Selalu uji ekspresi dengan tester sebelum dipakai.

#Alur Login Sosial

Beginilah alur lengkapnya ketika user menekan "Login dengan GitHub":

1. User diarahkan ke halaman flow yang memuat source (misalnya pada authentication flow).
2. Browser di-redirect ke GitHub dengan client id dan scope.
3. GitHub meminta otorisasi user, lalu mengembalikan authorization code ke callback Authentik.
4. Authentik menukar code dengan access token, mengambil profil user, dan menentukan identitas.
5. Flow autentikasi atau enrollment dieksekusi berdasarkan apakah user dikenal.
6. User masuk ke sesi Authentik dan bisa membuka aplikasi yang dilindungi.

Seluruh proses ini memakai flow yang sudah kalian pelajari di fase 2 — source hanyalah pintu masuk, alur setelahnya tetap dikendalikan stages dan policies Authentik.

#Menangani User yang Sudah Ada

Skenario umum: organisasi sudah punya user internal (misalnya budi@example.com), lalu menambahkan social login. Tanpa aturan yang tepat, user yang sama bisa membuat akun ganda.

Solusinya lewat mode pencocokan: pilih email_link pada enrollment flow. Saat user login dengan GitHub yang emailnya cocok dengan user internal budi@example.com, Authentik menghubungkan akun internal tersebut dengan koneksi source — bukan membuat user baru. Setelah terhubung, login berikutnya lewat GitHub langsung memakai akun yang sama, lengkap dengan grup dan policy-nya.

Untuk memeriksa atau memperbaiki koneksi, buka halaman user → tab Synced users/sources dan lihat koneksi yang ada. Jika terjadi konflik identitas (dua user dengan email sama), putuskan sumber kebenarannya dan perbaiki lewat UI sebelum memaksa mode pencocokan yang lebih ketat.

#Penutup

Episode ini menggunakan Authentik sebagai Relying Party lewat OAuth sources: memahami konsep source, membuat OAuth app di provider eksternal (GitHub/Google/Discord), memasang client id dan secret, mengikat source ke flow autentikasi dan enrollment, memetakan profil user dengan property mappings, dan menangani user yang sudah ada lewat mode pencocokan.

Satu pintu masuk tetap milik Authentik — sumber login hanyalah alternatif bukti identitas. Di episode 17, kita membahas source lain yang tak kalah penting di dunia enterprise: LDAP source, yang menyinkronkan user dan grup dari OpenLDAP atau Active Directory ke dalam Authentik. Sampai jumpa!