Episode ini mengintegrasikan client nyata dengan Authelia sebagai OIDC provider: Grafana, Gitea atau Forgejo, Nextcloud, dan Portainer. Mulai dari registrasi client dengan redirect URI, scope, dan grant type, alur login OIDC dari sisi aplikasi, hingga cara memverifikasi token.

Di episode 18 kalian memahami scope dan claim — bahasa yang dipakai client untuk meminta data identitas. Sekarang saatnya berbicara dengan aplikasi sungguhan. Episode 19 ini memandu integrasi empat client nyata — Grafana, Gitea atau Forgejo, Nextcloud, dan Portainer — dengan Authelia sebagai penyedia identitas.
Alur yang kita pakai selalu sama, terlepas dari aplikasinya: client mengarahkan pengguna ke endpoint authorization Authelia, pengguna login dan menyetujui consent, Authelia mengembalikan kode, client menukarnya dengan token, lalu memakai token itu untuk mengambil identitas pengguna.
Semua integrasi dimulai dari satu tempat: mendaftarkan client di identity_providers.oidc.clients. Empat hal yang paling sering menjadi biang masalah:
redirect_uris — harus cocok persis dengan yang diminta aplikasi, termasuk skema, host, path, dan trailing slash.scopes — scope yang didaftarkan harus mencakup semua yang diminta aplikasi.grant_types — untuk aplikasi web interaktif, authorization_code adalah standarnya; tambahkan refresh_token jika aplikasi butuh sesi panjang.secret — disarankan memakai hash alih-alih plaintext; prefix $plaintext$ memudahkan pengembangan.Grafana mendukung OAuth lewat auth.generic_oauth. Daftarkan client di Authelia, lalu set konfigurasi di grafana.ini:
[auth.generic_oauth]
enabled = true
name = Authelia
client_id = grafana
client_secret = rahasia-client
scopes = openid profile email groups
auth_url = https://auth.example.com/api/oidc/authorization
token_url = https://auth.example.com/api/oidc/token
api_url = https://auth.example.com/api/oidc/userinfo
allowed_groups = grafana-admin grafana-editorallowed_groups mencocokkan claim groups dari token. Dengan ini, hanya pengguna yang masuk grup grafana-admin atau grafana-editor yang boleh login — kontrol akses terpusat di Authelia, bukan tersebar di tiap aplikasi.
Gitea dan Forgejo memakai pola yang sama: aktifkan dukungan OAuth2, lalu daftarkan Authelia sebagai authentication source melalui admin panel, bukan file konfigurasi.
[oauth2_client]
ENABLE = trueDi admin panel Gitea atau Forgejo, buat Authentication Source baru dengan tipe OAuth2 dan provider OpenID Connect. Isi OpenID Connect Auto Discovery URL dengan https://auth.example.com/.well-known/openid-configuration, lalu masukkan client_id, client_secret, dan scope openid profile email groups. Kedua aplikasi ini memakai discovery untuk menemukan semua endpoint Authelia secara otomatis, jadi tidak perlu mengisi URL authorization dan token secara manual.
Tip
Kolom OpenID Connect Auto Discovery memakai endpoint discovery Authelia. Jika kolom itu diisi dengan benar, semuanya mengalir otomatis — inilah alasan mengapa OIDC lebih nyaman daripada OAuth 2.0 biasa.
Nextcloud memakai aplikasi oidc_login. Konfigurasinya diletakkan di config/config.php:
'oidc_login_provider_url' => 'https://auth.example.com/.well-known/openid-configuration',
'oidc_login_client_id' => 'nextcloud',
'oidc_login_client_secret' => 'rahasia-client',
'oidc_login_auto_redirect' => false,
'oidc_login_disable_registration' => true,
'oidc_login_scope' => 'openid profile email',
'oidc_login_default_claim' => 'preferred_username',oidc_login_default_claim menentukan claim yang dipakai untuk membuat akun lokal. Ingat pelajaran episode 18: preferred_username dan email hanya untuk provisioning akun, sedangkan relasi akun yang stabil tetap mengacu ke sub di sisi Authelia.
Portainer dikonfigurasi lewat menu Settings → Authentication → OAuth. Karena tidak punya discovery otomatis, semua endpoint diisi manual. Client di Authelia:
identity_providers:
oidc:
clients:
- id: portainer
description: Portainer management
secret: '$plaintext$rahasia-client'
redirect_uris:
- https://portainer.example.com
scopes:
- openid
- profile
- email
- groups
grant_types:
- authorization_code
response_types:
- codeDi sisi Portainer, isi field berikut:
portainer.https://auth.example.com/api/oidc/authorization.https://auth.example.com/api/oidc/token.https://auth.example.com/api/oidc/userinfo.https://portainer.example.com — harus sama persis dengan redirect_uris.sub.openid profile email groups.Perhatikan bahwa redirect URL Portainer hanya berupa host tanpa path. Ketidakcocokan satu karakter saja akan membuat flow gagal di langkah callback.
Ketika semuanya terpasang, alur di belakang layar berjalan seperti ini:
https://auth.example.com/api/oidc/authorization beserta client_id, redirect_uri, scope, dan state.redirect_uri.https://auth.example.com/api/oidc/token.Seluruh langkah ini otomatis — kalian hanya perlu memastikan konfigurasi di kedua sisi cocok.
Verifikasi dasar yang bisa dilakukan:
curl -s https://auth.example.com/.well-known/openid-configuration | jq .
curl -s https://auth.example.com/jwks.json | jq .keys[0].algEndpoint pertama harus mengembalikan metadata OIDC lengkap; endpoint kedua memuat kunci RSA publik untuk memvalidasi tanda tangan token. Setelah login pertama berhasil, dekode token yang dihasilkan — misalnya lewat panel developer browser — dan periksa claim sub, name, serta groups.
Warning
Jika login selalu gagal di tengah jalan, urutan diagnosis dimulai dari yang paling sering salah: redirect URI tidak cocok, client secret salah ketik, scope yang diminta belum terdaftar, atau X-Forwarded-Proto tidak diteruskan sehingga Authelia memaksa HTTPS.
Di episode ini kalian mengintegrasikan empat client nyata:
auth.generic_oauth dengan endpoint authorization, token, dan userinfo Authelia..well-known/openid-configuration.sub menjadi kunci relasi akun yang stabil.Satu komponen yang belum kita bahas tuntas adalah layar consent yang muncul saat login. Di episode 20, kita membahas Consent Management — cara mengatur mode consent per client, pre-configured consent, hingga mencabut izin yang sudah diberikan. Sampai jumpa!