Belajar Authelia - OpenID Connect Provider

#Pendahuluan

Selama empat episode terakhir, kalian menempatkan Authelia di gerbang: proxy bertanya, Authelia menjawab izin, dan aplikasi menerima header Remote-User. Pola ini luar biasa untuk aplikasi yang bisa berdiri di belakang proxy. Tapi ada kategori aplikasi yang tidak bisa begitu saja dilindungi pola itu — aplikasi modern yang justru menjalankan login mereka sendiri dan berharap login itu bisa disatukan dengan sistem lain. Jawabannya adalah standar yang hampir pasti pernah kalian dengar: OpenID Connect (OIDC).

Episode ini membuka fase baru dan kemampuan Authelia yang paling sering diremehkan: Authelia sebagai OIDC provider. Selain menjaga pintu lewat forward authentication, Authelia bisa menjadi identity provider — otoritas yang membuktikan identitas user kepada aplikasi lain lewat protokol standar OAuth2/OIDC.

Analogi: forward auth itu seperti satpam di pintu. OIDC itu seperti kartu identitas berstandar nasional — diterbitkan sekali oleh instansi resmi (Authelia), dan diterima oleh semua kantor (aplikasi) yang mau memeriksa kartu itu. Kalian login sekali, dan setiap aplikasi memercayai bukti yang sama.

#Apa itu OIDC dalam Konteks Authelia

OpenID Connect adalah lapisan identitas di atas OAuth 2.0. OAuth 2.0 mengatur otorisasi — "aplikasi ini boleh mengakses sumber daya itu". OIDC menambahkan autentikasi — "user yang sedang login ini bernama siapa" — lewat ID token yang berisi klaim (claims).

Ketika Authelia menjadi provider OIDC, perannya berubah dari menerima permintaan verifikasi menjadi menerbitkan bukti identitas:

• Authorization server — Authelia memvalidasi login dan MFA, lalu menerbitkan token.
• Client — aplikasi yang meminta login kepada Authelia (Grafana, Nextcloud, Proxmox, dan banyak lagi).
• Resource server — aplikasi tujuan yang memverifikasi token untuk membuktikan identitas user.

Konsekuensi besarnya: aplikasi tidak perlu tahu apa pun tentang format header Remote-User. Mereka hanya perlu mengikuti standar OIDC — dan standar ini dipahami oleh hampir semua aplikasi modern.

#Mengaktifkan OIDC di configuration.yml

OIDC tidak menyala dengan sendirinya; kalian mengaktifkannya dengan mendefinisikan blok identity_providers.oidc di configuration.yml:

identity_providers:
  oidc:
    hmac_secret: "random-hmac-secret-yang-sangat-panjang"
    issuer_private_key: |
      -----BEGIN RSA PRIVATE KEY-----
      ...kunci privat RSA untuk menandatangani token...
      -----END RSA PRIVATE KEY-----

Dua rahasia ini menentukan keamanan seluruh sistem:

• hmac_secret — kunci yang dipakai untuk menandatangani dan memvalidasi kode otorisasi serta token. Tanpa nilai ini Authelia menolak mengaktifkan OIDC.
• issuer_private_key — kunci privat RSA yang menandatangani ID token. Kunci publiknya dipublikasikan lewat endpoint JWKS sehingga aplikasi bisa memverifikasi tanda tangan. Pada versi modern, Authelia bisa membuat kunci ini secara otomatis jika tidak disediakan, tetapi menyediakannya sendiri memberikan kendali penuh atas rotasi kunci.

#Mendaftarkan Client

Inti konfigurasi OIDC adalah daftar clients — aplikasi yang diizinkan meminta login. Contoh untuk Grafana:

identity_providers:
  oidc:
    hmac_secret: "random-hmac-secret-yang-sangat-panjang"
    clients:
      - id: grafana
        client_name: "Grafana"
        client_secret: "$pbkdf2-sha512$..."
        authorization_policy: two_factor
        redirect_uris:
          - "https://grafana.example.com/login/generic_oauth"
        scopes:
          - openid
          - profile
          - email
          - groups
        grant_types:
          - authorization_code
        response_types:
          - code

Mari bedah setiap field:

• id — identitas unik client. Aplikasi menyebut nilai ini saat memulai alur login; nilai inilah yang di aplikasi disebut client_id.
• client_name — nama tampilan yang ditampilkan di layar persetujuan (consent) kepada user.
• client_secret — "password" client, yang juga disimpan sebagai hash (PBKDF2-SHA512), bukan plaintext. Generate hashing dengan authelia crypto hash generate pbkdf2 --variant sha512 --password 'rahasia-client'.
• authorization_policy — menentukan kekuatan autentikasi yang diminta: one_factor cukup password, two_factor mewajibkan MFA. Untuk aplikasi sensitif, two_factor adalah pilihan yang benar.
• redirect_uris — daftar URL yang boleh menerima redirect setelah login. Ini salah satu mekanisme anti-hijack: jika URL redirect tidak ada di daftar, Authelia menolak alur login.
• scopes — lingkup klaim yang boleh diminta. openid wajib (menandakan ini alur OIDC); profile, email, dan groups membawa identitas serta keanggotaan grup.
• grant_types dan response_types — alur protokol yang diizinkan. authorization_code + code adalah kombinasi standar dan paling aman untuk aplikasi web.

#Alur Token: Dari Redirect ke Session

Ketika user menekan tombol login dengan Authelia di Grafana, inilah yang terjadi:

1. Authorization request — Grafana mengarahkan browser user ke endpoint Authelia /api/oidc/authorization dengan client_id, redirect_uri, scope, dan response_type=code.
2. Autentikasi — Authelia menampilkan portal. User login (dan menyelesaikan MFA jika authorization_policy: two_factor). Authelia meminta persetujuan (consent) jika diperlukan.
3. Authorization code — Authelia mengalihkan browser kembali ke redirect_uri dengan kode otorisasi sekali pakai.
4. Token exchange — Grafana (di sisi server) menukar kode itu ke endpoint /api/oidc/token, menyertakan client_secret. Authelia membalas dengan access token, ID token, dan refresh token.
5. UserInfo — Grafana bisa mengambil klaim tambahan dari /api/oidc/userinfo, atau membaca ID token langsung.
6. Session — sejak saat itu, login Grafana dan Authelia terhubung. Logout di salah satunya bisa menyebar ke yang lain.

Endpoint lain yang didukung Authelia: /api/oidc/jwks (kunci publik untuk memverifikasi token), /api/oidc/introspection (validasi token secara server-side), dan /api/oidc/revocation (mencabut token).

#OIDC Discovery

Salah satu hal yang membuat integrasi begitu mudah adalah discovery: aplikasi tidak perlu dikonfigurasi dengan detail endpoint satu per satu. Authelia mempublikasikan metadata di:

curl https://auth.example.com/.well-known/openid-configuration

Dokumen JSON ini berisi issuer, lokasi endpoint authorization, token, userinfo, jwks, dan daftar scope yang didukung. Pada kebanyakan aplikasi modern, kalian cukup mengisi discovery URL (misalnya https://auth.example.com/.well-known/openid-configuration) beserta client_id dan client_secret — aplikasi akan menemukan semua endpoint lainnya sendiri.

#Mengatur Masa Berlaku Token

Authelia memungkinkan kontrol masa berlaku setiap jenis token — keputusan keamanan yang penting:

identity_providers:
  oidc:
    access_token_lifespan: "1h"
    authorize_code_lifespan: "1m"
    id_token_lifespan: "1h"
    refresh_token_lifespan: "90m"

Prinsipnya sama seperti sesi di episode 7: semakin pendek, semakin kecil jendela penyalahgunaan jika token bocor. Kode otorisasi sengaja sangat pendek (satu menit) karena hanya hidup antara redirect dan pertukaran token. Refresh token boleh lebih panjang, tapi ingat: refresh token adalah kuasa untuk mendapatkan access token baru — jangan dibiarkan hidup lebih lama dari yang dibutuhkan.

#Penutup

Episode ini mengubah Authelia dari sekadar gerbang menjadi identity provider: memahami konsep authorization server dan client dalam OIDC, mengaktifkan blok identity_providers.oidc dengan hmac_secret dan issuer_private_key, mendaftarkan client dengan authorization_policy, redirect_uris, scopes, grant_types, dan response_types, mengikuti alur dari authorization code hingga token exchange, serta memanfaatkan OIDC discovery untuk integrasi yang cepat.

Kemampuan ini melengkapi dua wajah Authelia: di depan pintu via forward authentication, dan di balik layar via OIDC. Di episode 18, kita memperdalam klaim yang dibawa token: OIDC scopes dan claims — bagaimana identitas user, email, dan keanggotaan grup diterjemahkan ke klaim yang dibaca aplikasi. Sampai jumpa!