Blogging & Web Terbuka

WebFinger untuk Website Personal — Membiarkan Domain Menunjuk ke Profil

Ditulis oleh Adam Muiz Diperbarui: 13 Nov 2026 7 menit baca
WebFinger untuk Website Personal — Membiarkan Domain Menunjuk ke Profil

WebFinger untuk Website Personal — Membiarkan Domain Menunjuk ke Profil

Sebuah website personal bisa memiliki halaman profil, URL penulis, feed, dan mungkin akun di layanan lain. Manusia biasanya dapat menemukan tautan itu dengan membaca halaman. Software tidak punya kemewahan yang sama. Jika seseorang memberinya acct:[email protected], URL mana yang harus diminta?

WebFinger adalah salah satu jawaban untuk masalah discovery tersebut. WebFinger memberi client tempat standar untuk menanyakan informasi tentang entitas yang diidentifikasi oleh URI. Protokolnya cukup kecil untuk dijelaskan dalam satu artikel, tetapi juga mudah disalahpahami: WebFinger adalah protokol discovery mirip direktori, bukan bukti bahwa seseorang menguasai identitas tertentu.

Masalahnya Discovery, Bukan Login

Manusia nyaman dengan nama yang bermakna tetapi belum lengkap. “Alice di example.com” mudah dibaca, tetapi tidak memberi tahu apakah profilnya berada di /alice, /users/alice, atau host terpisah. Client yang menebak path URL akan terikat pada desain internal satu situs.

RFC 7033 mendefinisikan WebFinger sebagai cara menemukan informasi tentang orang atau entitas lain menggunakan metode HTTP standar. Objek yang ditanyakan direpresentasikan sebagai URI. Responsnya adalah JSON Resource Descriptor, biasanya disebut JRD, yang dapat berisi subject, aliases, properties, dan links.

RFC 7033 juga mencatat bahwa format JRD pertama kali diperkenalkan oleh RFC 6415. Sejarah ini berguna untuk dipahami, tetapi protokol WebFinger-lah yang mendefinisikan cara descriptor tersebut diminta dan ditafsirkan untuk aplikasinya sendiri.

Pembedaan ini penting. Client bertanya, “Tautan dan metadata apa yang dipublikasikan layanan ini untuk identifier tersebut?” Client tidak bertanya, “Bisakah kamu membuktikan secara kriptografis bahwa orang ini benar-benar pemilik identitasnya?” Authentication dan authorization membutuhkan mekanisme terpisah.

Cara Kerja Request WebFinger

WebFinger menggunakan path well-known /.well-known/webfinger. RFC 8615 menjelaskan /.well-known/ sebagai prefix path yang dicadangkan untuk lokasi metadata yang ditentukan aplikasi. RFC 7033 kemudian mendefinisikan resource WebFinger di bawah prefix tersebut.

Client mengirim request GET dengan parameter query resource. Contoh ilustratifnya seperti ini:

GET /.well-known/webfinger?resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
Accept: application/jrd+json

Percent encoding di sini bukan hiasan. Nilai parameter tersebut adalah URI acct:[email protected], sementara titik dua dan tanda at dikodekan di dalam query string. Dalam client sungguhan, gunakan library pembuat URI atau query, bukan merangkai string ini secara manual.

Host juga penting. Dalam situasi normal, query dikirim ke host yang terdapat dalam URI target. Layanan dapat menggunakan infrastruktur WebFinger ter-host, tetapi redirect tetap harus menuju HTTPS dan client harus memvalidasi sertifikat. RFC 7033 secara eksplisit menyatakan bahwa request aman yang gagal tidak boleh dicoba ulang melalui HTTP biasa.

Membaca Respons JRD

Respons minimal bisa terlihat seperti ini:

{
  "subject": "acct:[email protected]",
  "aliases": [
    "https://example.com/about/alice"
  ],
  "links": [
    {
      "rel": "profile-page",
      "type": "text/html",
      "href": "https://example.com/about/alice"
    },
    {
      "rel": "author",
      "type": "application/atom+xml",
      "href": "https://example.com/feed.xml"
    }
  ]
}

Ini adalah respons ilustratif, bukan klaim tentang endpoint yang sedang aktif. Bagian pentingnya adalah strukturnya:

  • subject mengidentifikasi entitas yang dijelaskan JRD. Nilainya dapat memakai bentuk canonical yang berbeda dari nilai yang diminta.
  • aliases mencantumkan URI lain yang mengidentifikasi entitas sama, bila aplikasi memang mendefinisikan hubungan itu.
  • links berisi objek relasi tautan. rel menjelaskan hubungan, sedangkan href menunjuk target dan type menjelaskan media type-nya.

Arti sebuah link tidak diciptakan oleh WebFinger sendiri. Aplikasi harus menentukan URI scheme, tipe relasi, dan properties yang diharapkan. Karena itu, client sebaiknya memilih link berdasarkan semantik yang dipahaminya, bukan sekadar mengambil URL pertama dalam array.

Mengapa ActivityPub Menggunakannya?

ActivityPub memberi actor identifier global yang dapat diambil, biasanya berupa URL HTTPS. Itu berguna setelah client mengetahui URL actor, tetapi mention seperti @[email protected] dimulai dari handle, bukan selalu dari URL actor.

ActivityPub mendefinisikan protokol sosial dan representasi actor. WebFinger dapat menjadi tahap discovery yang memetakan handle bergaya akun ke URL actor. Dokumentasi Mastodon memberi contoh implementasi nyata: Mastodon menanyakan endpoint WebFinger domain untuk URI acct:, kemudian mencari link dengan relasi self dan tipe representasi JSON ActivityPub.

Kedua lapisan ini tidak boleh dicampur. RFC 7033 bersifat netral terhadap aplikasi. Implementasi ActivityPub menambahkan aturan sendiri tentang JRD link mana yang dianggap sebagai actor. Website personal dapat menerapkan WebFinger tanpa menjadi server ActivityPub, sama seperti website dapat menerbitkan RSS tanpa menerapkan setiap protokol yang bisa mengonsumsi RSS.

Apa yang Bisa Dipublikasikan Website Personal?

Situs publishing kecil dapat memakai WebFinger untuk membuka beberapa hubungan publik secara sengaja:

  • Link profile-page menuju halaman penulis canonical.
  • Link author atau feed menuju feed publik, jika berguna bagi client.
  • Link khusus aplikasi hanya jika semantik dan kebijakan data publiknya sudah jelas.

Kata pentingnya adalah publik. RFC 7033 memperingatkan bahwa WebFinger dapat membuat informasi personal lebih mudah ditemukan dan menyatakan bahwa data personal tidak boleh dipublikasikan melalui WebFinger tanpa otorisasi eksplisit. Respons tidak perlu berisi alamat email, nomor telepon, lokasi, atau semua profil sosial hanya karena formatnya dapat membawa link.

Untuk situs PHP custom, batas implementasinya bisa sederhana: route path well-known, validasi URI resource, cari hanya hubungan publik, keluarkan JRD dengan media type yang benar, lalu tetapkan kebijakan CORS secara sengaja. Ini adalah sketsa arsitektur, bukan implementasi siap tempel. Aturan lookup, model penyimpanan, cache headers, dan error handling tetap perlu dirancang.

Batas Keamanan dan Operasional

WebFinger adalah metadata yang dapat dibaca mesin, sehingga menciptakan permukaan discovery yang stabil. Batas berikut lebih penting daripada membuat endpoint yang terlalu pintar:

  • Gunakan HTTPS. Protokol ini mewajibkan request aman dan penanganan sertifikat yang valid. Jangan diam-diam turun ke HTTP ketika HTTPS gagal.
  • Kontrol path well-known. RFC 8615 mencatat bahwa lokasi well-known mewakili origin secara luas. Deployment harus mencegah aplikasi yang tidak terkait atau direktori yang dapat ditulis mengambil alih respons.
  • Batasi scope link. Link dalam respons adalah pointer, bukan pernyataan keamanan universal tentang setiap hostname yang berkaitan.
  • Atur CORS dengan sengaja. RFC 7033 membahas akses browser dan memungkinkan CORS luas untuk data publik, tetapi deployment sensitif mungkin membutuhkan policy origin yang lebih ketat.
  • Hadapi penyalahgunaan biasa. Endpoint discovery publik tetap dapat menerima request berlebihan. Caching dan batas yang wajar adalah keputusan operasional, bukan jaminan protokol.
  • Jangan menyebut discovery sebagai authentication. Server yang jahat atau telah disusupi dapat mempublikasikan metadata menyesatkan. Client yang membutuhkan bukti penguasaan memerlukan metode verifikasi terpisah.

Kapan Layak Ditambahkan?

WebFinger cocok ketika situs memiliki identifier bergaya akun yang perlu di-resolve software eksternal, atau ketika situs mengikuti protokol yang mengharapkan WebFinger. Ia juga bisa menjadi dasar eksperimen open-web identity, asalkan data yang dipublikasikan sengaja dibuat kecil.

WebFinger kemungkinan tidak diperlukan bila situs tidak memiliki identifier bergaya akun, tidak memiliki client eksternal, dan tidak mengikuti protokol yang mengonsumsi hasilnya. Menambahkan endpoint yang tidak pernah ditanyakan akan menambah permukaan sistem tanpa otomatis membuat website lebih terbuka. Halaman penulis HTML dengan link yang jelas bisa menjadi solusi yang lebih jujur.

Ada juga pertanyaan pemeliharaan. Respons WebFinger tidak seharusnya menunjuk ke URL profil yang sudah mati, feed lama, atau identitas yang diam-diam telah berpindah pemilik. Jika situs tidak dapat menjaga hubungan itu tetap akurat, endpoint machine-readable bisa lebih buruk daripada tidak memilikinya.

Kesimpulan

WebFinger menyelesaikan masalah yang sempit tetapi nyata: menerjemahkan identifier berbentuk URI menjadi metadata dan link yang dapat dipahami software. Endpoint-nya dapat diprediksi, format responsnya terstruktur, dan aplikasi seperti ActivityPub menunjukkan manfaat memisahkan handle dari URL profil.

Namun protokol ini tidak menciptakan kepercayaan dengan sendirinya. WebFinger tidak mengonfirmasi identitas seseorang, tidak mengotorisasi client, dan tidak mengubah website personal menjadi jaringan federasi. Untuk situs kecil, langkah yang masuk akal adalah mulai dari pertanyaan “siapa perlu menemukan apa?” lalu mempublikasikan hanya hubungan yang memiliki jawaban jelas.

References