IndieAuth untuk Personal Website — Menjadikan URL Milikmu sebagai Login Ditulis oleh Adam Muiz 09 Aug 2026 Diperbarui: 09 Aug 2026 6 menit baca Login biasanya berarti kita meminjam identitas dari platform besar. Tombol “Continue with Google” memang praktis, tetapi diam-diam menjadikan domain milik orang lain sebagai pintu depan kehidupan digital kita. Setelah membangun personal website, susunan ini terasa terbalik: mengapa profil sewaan harus membuktikan siapa pemilik rumah yang benar-benar kita kendalikan? IndieAuth menawarkan jawaban berbeda. Protokol ini memungkinkan personal website berfungsi sebagai identitas sambil tetap memakai authorization service tepercaya di belakang layar. Gagasannya terdengar abstrak, tetapi praktiknya sederhana: URL milikmu menjadi nama yang kamu tunjukkan kepada aplikasi kompatibel, lalu kamu menentukan service mana yang boleh terhubung. Apa yang sebenarnya dilakukan IndieAuth IndieAuth adalah identity layer yang dibangun di atas OAuth 2.0. Alih-alih mengetik alamat email atau memilih social network, seseorang memasukkan URL website seperti https://example.com/. Aplikasi menemukan authorization endpoint yang diumumkan oleh website tersebut, mengarahkan browser ke sana, lalu menerima bukti bahwa orang itu mengendalikan URL tadi. Bayangkan kamu memakai alamat rumah sebagai identitas sambil memilih tukang kunci tertentu untuk memverifikasi kuncinya. Rumah tetap milikmu walaupun tukang kuncinya diganti. Begitu pula dengan identity URL dan authorization server: keduanya merupakan bagian terpisah. Kamu dapat berpindah provider atau melakukan self-hosting nanti tanpa meminta setiap aplikasi kompatibel mengenali identitas baru. IndieAuth bukan password manager, bukan pengganti universal untuk semua sistem login, dan bukan izin bagi aplikasi untuk menyisir seluruh website. Ia adalah protokol untuk authentication dan delegated authorization. Scope yang diminta menentukan apa yang boleh dilakukan aplikasi, sedangkan access token mewakili izin tersebut. Discovery link di homepage Sebuah client perlu tahu dari mana harus memulai. Homepage menyediakan informasi itu melalui elemen HTML <link>. Setup minimal mengarah ke authorization endpoint dan token endpoint. Endpoint tersebut dapat berada di domain sendiri atau dikelola provider yang kamu percaya. <link rel="authorization_endpoint" href="https://auth.example.net/auth"> <link rel="token_endpoint" href="https://auth.example.net/token"> Link ini ditempatkan di dalam <head> dokumen. Beberapa deployment juga mengirim HTTP Link header yang setara, tetapi discovery melalui HTML lebih mudah diperiksa saat belajar. Gunakan HTTPS di semua bagian, pastikan redirect bersifat deterministik, dan buat canonical URL tetap konsisten dengan atau tanpa trailing slash. Konfigurasi tepatnya bergantung pada authorization server. Hosted service mungkin memintamu memverifikasi domain melalui link atau metadata khusus provider. Server yang di-self-host mungkin membutuhkan aturan redirect URI dan client secara eksplisit. Spesifikasi terkini tersedia di https://indieauth.spec.indieweb.org/; baca spesifikasi dan dokumentasi provider, jangan menyalin contoh endpoint secara mentah. Mengikuti satu proses login dari awal sampai akhir Anggap kamu ingin login ke reader yang kompatibel dengan IndieAuth. Pertama, kamu memasukkan URL pribadi. Reader mengambil homepage dan menemukan authorization endpoint. Ia membuat authorization request yang berisi client identifier, redirect URI yang presisi, nilai state acak, code challenge, serta scope yang diminta. response_type=code client_id=https://reader.example/app redirect_uri=https://reader.example/callback state=random-per-request-value code_challenge=derived-pkce-value code_challenge_method=S256 scope=profile Browser menuju authorization server. Setelah kamu melakukan authentication dan menyetujui request, server mengarahkan browser kembali dengan authorization code berumur pendek. Reader memeriksa state, kemudian menukar code memakai PKCE verifier. Jika semuanya cocok, hasilnya mengonfirmasi URL yang terautentikasi dan dapat menyertakan access token untuk scope yang disetujui. Urutan ini mirip mengambil paket tercatat. Menunjukkan identitas di loket saja belum cukup; nomor paket, penerima, dan bukti pengambilan juga harus cocok. Parameter OAuth menjalankan pemeriksaan silang itu secara digital. Mengabaikan salah satunya karena “website ini kecil” justru membuang lapisan yang mencegah serangan nyata. Detail keamanan yang tidak boleh ditawar Selalu bandingkan state yang dikembalikan dengan nilai yang disimpan sebelum redirect. Langkah ini mengikat callback ke browser session dan membantu mencegah login CSRF. Gunakan PKCE dengan S256 agar authorization code yang disadap tidak dapat ditukar tanpa verifier. Redirect URI harus cocok secara presisi; wildcard yang terlalu longgar mengubah proses serah-terima aman menjadi pintu samping terbuka. Client juga wajib memvalidasi identitas yang dikembalikan authorization server, bukan sekadar menganggapnya sama dengan URL awal. Server sebaiknya menerbitkan code berumur pendek, mencegah pemakaian ulang, melindungi token saat disimpan, dan menampilkan consent screen yang jelas. Mintalah scope sekecil mungkin. Reader yang hanya perlu mengenali user tidak pantas meminta izin publishing. Kontrol domain sama pentingnya. Jika domain kedaluwarsa, DNS disusupi, atau website dapat diedit attacker, identitas tersebut ikut berisiko. Aktifkan MFA di registrar, jaga perpanjangan domain, lindungi hosting account, dan backup konfigurasi discovery. Memiliki pintu depan tetap berarti kita harus merawat engselnya. Jalur adopsi yang masuk akal Mulailah sebagai user, bukan langsung membangun authorization server. Pilih provider yang terawat, tambahkan discovery link, lalu uji dengan satu aplikasi kompatibel. Perhatikan authorization screen: apakah URL, client, tujuan redirect, dan scope yang tampil sudah benar? Coba tolak request sekali. Flow yang dapat dipercaya harus gagal dengan rapi, bukan hanya berhasil. Berikutnya, dokumentasikan setup di tempat yang sama dengan catatan DNS dan hosting. Catat provider aktif, cara domain ownership diverifikasi, serta cara mencabut session atau token. Siapkan recovery route yang tidak bergantung pada personal website sedang online. Jika outage membuatmu terkunci dari dashboard yang dibutuhkan untuk memperbaiki outage itu, desainnya membentuk circular dependency. Self-hosting bisa dilakukan nanti ketika manfaatnya sepadan dengan patching, monitoring, backup, dan security review. Memiliki protokol tidak mengharuskan kita menjalankan setiap komponen di rumah. Email juga demikian: memiliki alamat pada domain sendiri tetap bernilai walaupun mail server dioperasikan spesialis. Menguji tanpa menebak Mulailah dengan browser developer tools biasa. Pastikan homepage mengembalikan 200, discovery link muncul dalam HTML akhir, dan tidak ada cache yang menyajikan versi lama. Periksa setiap endpoint melalui HTTPS. Saat test login, teliti redirect URI dan scope yang diminta, jangan otomatis menekan approve. curl -sL https://example.com/ | grep -E \ 'authorization_endpoint|token_endpoint' Command ini hanya pemeriksaan discovery singkat, bukan protocol conformance test. Uji juga cancellation, browser kedua, session kedaluwarsa, dan akses yang sudah dicabut. Jika kamu mengoperasikan authorization server, monitor exchange yang gagal tanpa mencatat authorization code, token, atau secret lain. Log yang berguna menjelaskan error tanpa membawa credential ke dalamnya. Identitas yang dapat bertahan lebih lama daripada provider IndieAuth penting bukan karena menambah satu tombol login, melainkan karena menggeser pusat kendali. Identifier yang tahan lama adalah URL yang kamu kontrol, sementara provider dan aplikasi menjadi alat yang dapat diganti di sekelilingnya. Pilihan arsitektur yang kecil ini memberi hasil yang sangat manusiawi: identitas online bisa mempunyai alamatnya sendiri. Prosesnya tidak sepenuhnya tanpa friksi dan tidak boleh dianggap ajaib. Pengelolaan domain yang aman, validasi OAuth yang teliti, scope terbatas, dan recovery plan tetap penting. Namun, jika kamu sudah merawat personal website, menambahkan IndieAuth adalah eksperimen lanjutan yang bermakna. Cobalah dengan satu aplikasi, amati setiap redirect, lalu bagikan keberhasilan atau kegagalannya di kolom komentar agar orang lain dapat belajar dari detailnya.
