WebAuthn Related Origins: Panduan Passkey Lintas Domain

Passkey adalah standar baru untuk autentikasi yang aman dan user-friendly. Dibangun di atas standar FIDO/WebAuthn, passkey memanfaatkan kriptografi kunci publik untuk menawarkan ketahanan bawaan terhadap phishing dan credential stuffing, yang secara dramatis meningkatkan postur keamanan sekaligus menyederhanakan pengalaman login bagi pengguna. Bagi organisasi, hal ini diterjemahkan menjadi manfaat bisnis yang nyata: pengurangan biaya operasional dari reset kata sandi dan SMS OTP, mitigasi risiko finansial dari penipuan pengambilalihan akun, dan peningkatan pendapatan melalui tingkat konversi yang lebih tinggi.

Namun, salah satu kekuatan keamanan terbesar WebAuthn—sifatnya yang terikat ketat pada origin— menciptakan tantangan nyata yang signifikan bagi merek global dan perusahaan dengan jejak digital yang beragam. Secara desain, passkey yang dibuat untuk domain web tertentu terkunci secara kriptografis ke domain tersebut, sebuah prinsip fundamental yang mencegah serangan phishing. Meskipun ini adalah fitur keamanan yang kuat, hal ini menyebabkan pengalaman pengguna yang terfragmentasi dan membingungkan ketika satu merek beroperasi di beberapa domain.

Contoh nyata dari tantangan ini adalah rebranding Twitter menjadi X. Pengguna yang membuat passkey di twitter.com akan merasa passkey tersebut tidak dapat digunakan di x.com, memaksa perusahaan untuk menerapkan pengalihan yang merepotkan atau meminta pengguna mendaftar ulang, yang menciptakan gesekan yang secara langsung menghambat adopsi. Ini bukan masalah yang terisolasi. Perusahaan besar seperti Amazon beroperasi di berbagai domain level atas kode negara (ccTLD) seperti amazon.com, amazon.de, dan amazon.co.uk, yang semuanya berbagi sistem akun pengguna yang sama. Di dunia sebelum passkey, pengelola kata sandi dengan cekatan menangani kompleksitas ini, tetapi perilaku default WebAuthn akan memerlukan passkey terpisah untuk setiap domain, yang membuat pengguna frustrasi dan merusak janji login yang mulus.

Untuk mengatasi penghambat adopsi yang krusial ini, W3C telah memperkenalkan fitur baru dalam standar WebAuthn: Related Origin Requests (ROR). Mekanisme yang kuat ini menyediakan cara yang terstandarisasi dan aman bagi sekelompok domain tepercaya untuk berbagi satu passkey, menciptakan pengalaman autentikasi yang terpadu dan mulus di seluruh ekosistem digital suatu merek. Pembahasan mendalam ini akan mengeksplorasi dasar-dasar teknis ROR, memberikan panduan praktis untuk implementasinya, dan menganalisis implikasi strategisnya bagi arsitektur autentikasi modern.

Pengenalan ROR menandai pematangan signifikan dari standar WebAuthn. Spesifikasi awal memprioritaskan penetapan prinsip-prinsip kriptografi dan keamanan inti, dengan pengikatan ketat kredensial ke ID Relying Party (rpID) sebagai landasan desain anti-phishing-nya. Seiring dengan implementasi perusahaan skala besar oleh perusahaan seperti Amazon dan Google menjadi kenyataan, gesekan praktis yang disebabkan oleh kekakuan ini menjadi jelas. Gesekan ini merupakan hambatan langsung untuk mencapai adopsi pengguna yang tinggi, yang merupakan ukuran keberhasilan utama untuk setiap proyek passkey. Pengembangan ROR adalah respons langsung terhadap masukan dari perusahaan ini, yang menunjukkan evolusi pragmatis dari standar tersebut. Hal ini mengakui bahwa agar sebuah protokol keamanan mencapai keberhasilan yang luas, kegunaannya harus dapat disesuaikan untuk mengakomodasi realitas bisnis yang kompleks dan strategi branding dari organisasi yang menerapkannya.

Panduan komprehensif ini menjawab lima pertanyaan penting untuk mengimplementasikan WebAuthn Related Origin Requests:

1. Mengapa passkey gagal di beberapa domain? Memahami model keamanan WebAuthn yang terikat pada origin dan titik gesekan di dunia nyata.
2. Bagaimana cara kerja Related Origin Requests secara teknis? Penjelasan mendalam tentang alur validasi browser dan mekanisme URI .well-known.
3. Apa yang diperlukan untuk mengimplementasikan ROR? Konfigurasi langkah demi langkah di sisi server dan klien dengan contoh kode praktis.
4. Kapan sebaiknya memilih ROR daripada login terfederasi? Kerangka keputusan strategis yang membandingkan ROR dengan pendekatan OIDC/SAML.
5. Bagaimana cara menangani kompatibilitas browser dan pertimbangan keamanan? Matriks dukungan saat ini dan praktik terbaik keamanan.

Untuk detail teknis lebih lanjut, lihat Penjelasan Resmi WebAuthn Related Origin Requests.

Untuk sepenuhnya menghargai keanggunan solusi Related Origin Requests, penting untuk terlebih dahulu memahami konsep teknis yang mendasari keberadaannya: Same-Origin Policy web dan aturan cakupan ID Relying Party (rpID) WebAuthn. Mekanisme ini merupakan dasar keamanan web tetapi menciptakan gesekan yang dirancang untuk diatasi oleh ROR.

"Origin" web adalah konsep keamanan penting yang didefinisikan oleh kombinasi unik dari protokol (misalnya, https), domain (misalnya, app.example.com), dan port (misalnya, 443) dari mana konten disajikan. Same-Origin Policy adalah mekanisme keamanan yang diberlakukan oleh browser yang membatasi bagaimana skrip yang dimuat dari satu origin dapat berinteraksi dengan sumber daya dari origin lain. Ini adalah elemen penting dari keamanan web, yang secara efektif mengisolasi dokumen yang berpotensi berbahaya dan mencegah situs web penipuan, misalnya, membaca data sensitif dari sesi webmail pengguna yang terautentikasi di tab lain.

Dalam ekosistem WebAuthn, "Relying Party" (RP) adalah situs web atau aplikasi tempat pengguna mencoba melakukan autentikasi. Setiap passkey terikat secara kriptografis ke Relying Party ID (rpID) pada saat pembuatannya. rpID adalah nama domain yang mendefinisikan cakupan dan batasan untuk kredensial tersebut.

Secara default, rpID adalah domain efektif dari origin tempat passkey dibuat. Aturan cakupan WebAuthn memungkinkan sebuah origin untuk menetapkan rpID yang sama dengan domainnya sendiri atau akhiran domain yang dapat didaftarkan. Misalnya, skrip yang berjalan di https://www.accounts.example.co.uk dapat membuat passkey dengan rpID:

• www.accounts.example.co.uk (domain lengkap)
• accounts.example.co.uk
• example.co.uk

Fleksibilitas ini memungkinkan passkey yang dibuat di satu subdomain untuk digunakan di subdomain lain dari domain induk yang sama, yang merupakan pola umum dan diperlukan. Namun, aturan tersebut secara ketat melarang pengaturan rpID yang bukan merupakan akhiran. Skrip yang sama di www.accounts.example.co.uk tidak bisa membuat passkey dengan rpID example.com, karena .com adalah domain level atas yang berbeda.

Pengikatan ketat ini memiliki tujuan penting: memisahkan kredensial berdasarkan cakupan domain. Passkey yang dibuat untuk mybank.com tidak dapat digunakan di phishing-site.com karena situs berbahaya tidak dapat mengklaim rpID sah dari mybank.com. Browser bahkan tidak akan menampilkan passkey tersebut sebagai opsi.

Namun, rpID itu sendiri bukanlah kontrol anti-phishing utama. Perlindungan phishing WebAuthn sebenarnya berasal dari verifikasi origin dalam objek clientDataJSON. Selama setiap seremoni WebAuthn, browser membuat objek JSON yang berisi konteks penting, termasuk origin yang tepat yang memulai permintaan. Seluruh objek ini kemudian ditandatangani secara kriptografis oleh kunci privat authenticator. Server (Relying Party) HARUS memverifikasi tanda tangan ini dan, yang terpenting, memvalidasi bahwa bidang origin dalam clientDataJSON yang ditandatangani cocok dengan nilai yang diharapkan dan tepercaya. Verifikasi origin inilah yang mencegah serangan phishing.

Dengan Related Origin Requests, cakupan rpID dilonggarkan—memungkinkan bar.com untuk secara sah mengklaim rpID dari foo.com setelah browser memvalidasi file .well-known/webauthn—tetapi persyaratan verifikasi origin tetap tidak berubah. clientDataJSON akan tetap melaporkan origin sebagai bar.com dengan jujur. Server di foo.com menerima data yang ditandatangani ini, memverifikasinya, dan melihat bahwa permintaan tersebut berasal dari bar.com. Server kemudian harus memeriksa bahwa bar.com adalah origin terkait yang diharapkan sebelum menerima autentikasi. Ini menunjukkan pendekatan berlapis yang memungkinkan fleksibilitas lebih besar tanpa mengorbankan prinsip inti verifikasi origin.

Mekanisme Related Origin Requests memperkenalkan cara yang elegan dan terstandarisasi bagi domain untuk secara publik menyatakan hubungan kepercayaan dengan tujuan berbagi passkey. Ini memanfaatkan pola web yang sudah mapan—URI /.well-known/ untuk membuat "daftar izin" yang dapat diverifikasi dan dapat dibaca mesin yang dapat dikonsultasikan oleh browser.

Konsep intinya sederhana: domain yang berfungsi sebagai rpID utama dan kanonis untuk sekumpulan situs terkait dapat menghosting file JSON khusus di URL standar yang "terkenal": https://{rpID}/.well-known/webauthn. File ini bertindak sebagai manifes publik, secara eksplisit mencantumkan semua origin lain yang secara resmi diizinkan untuk membuat dan menggunakan passkey di bawah rpID utama tersebut.

Alur validasi browser dipicu setiap kali menemukan ketidakcocokan antara origin saat ini dan rpID yang diminta:

1. Seorang pengguna di situs "terkait", seperti https://example.co.uk, memulai operasi passkey (pembuatan atau autentikasi) di mana kode sisi klien menentukan domain yang berbeda sebagai rpID, misalnya, example.com.
2. Browser mendeteksi ketidakcocokan ini. Berdasarkan aturan lama, ini akan segera mengakibatkan SecurityError.
3. Dengan dukungan ROR, browser, sebelum gagal, membuat permintaan HTTPS GET yang aman ke URL well-known dari rpID yang diklaim: https://example.com/.well-known/webauthn. Permintaan ini dibuat tanpa kredensial pengguna (seperti cookie) dan tanpa header referrer untuk melindungi privasi pengguna dan mencegah pelacakan.
4. Browser menerima respons JSON dari server. Browser mengurai file tersebut dan memeriksa apakah origin saat ini (https://example.co.uk) ada di dalam array origins di dalam objek JSON.
5. Jika origin ditemukan di daftar izin, operasi WebAuthn diizinkan untuk dilanjutkan menggunakan example.com sebagai rpID yang valid. Jika origin tidak ditemukan, atau jika file hilang atau formatnya salah, operasi gagal seperti yang akan terjadi sebelumnya.

Pilihan untuk menggunakan URI /.well-known/ adalah disengaja dan menyelaraskan ROR dengan standar web yang sudah ada untuk penemuan layanan dan validasi kontrol domain. Jalur URI ini, yang didefinisikan oleh RFC 8615, sudah digunakan oleh banyak protokol penting, termasuk acme-challenge untuk penerbitan sertifikat SSL Let's Encrypt dan assetlinks.json untuk menghubungkan situs web ke aplikasi Android. Dengan mengadopsi konvensi ini, W3C memanfaatkan pola yang secara inheren menyiratkan kepemilikan domain. Untuk menempatkan file di jalur standar yang spesifik ini, seseorang harus memiliki kontrol administratif atas server web untuk domain tersebut. Ini memberikan bukti kontrol yang sederhana namun efektif, membuat deklarasi kepercayaan dapat diverifikasi. Ketika pemilik example.com menyajikan file yang mencantumkan example.co.uk sebagai origin terkait, itu adalah klaim yang dapat diverifikasi. Pendekatan web-native ini jauh lebih sederhana dan lebih kuat daripada alternatif yang dipertimbangkan dan ditolak selama proses standardisasi, seperti menggunakan kunci kriptografis untuk menandatangani otorisasi (RP Keys) atau pengidentifikasi acak non-domain (RP UUIDs). ROR mendasarkan hubungan kepercayaan pada model kontrol domain web yang sudah ada dan dipahami dengan baik.

Mengimplementasikan Related Origin Requests memerlukan perubahan terkoordinasi baik di sisi server, untuk mengotorisasi origin, maupun di sisi klien, untuk memanggil rpID bersama. Bagian ini menyediakan kode praktis dan detail konfigurasi yang diperlukan untuk mengaktifkan pengalaman passkey yang terpadu di seluruh domain Anda.

Server yang menghosting rpID utama bertanggung jawab untuk mempublikasikan daftar izin dari origin terkait.

File otorisasi harus ditempatkan di jalur yang tepat /.well-known/webauthn relatif terhadap root domain rpID utama. Sangat penting bahwa file ini disajikan di bawah kondisi berikut:

• Protokol: Harus disajikan melalui HTTPS.
• Content-Type: Header respons HTTP Content-Type harus diatur ke application/json.
• Ekstensi File: URL tidak boleh menyertakan ekstensi .json. Jalur yang benar adalah /webauthn, bukan /webauthn.json.

File harus berisi satu objek JSON dengan satu kunci, origins, yang nilainya adalah array string. Setiap string dalam array adalah origin lengkap (protokol, domain, dan port opsional) yang diotorisasi.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Contoh: Untuk rpID example.com, file harus disajikan di https://example.com/.well-known/webauthn (catatan: tidak ada ekstensi .json).

Setelah server dikonfigurasi dengan file .well-known/webauthn, semua domain terkait harus secara konsisten menggunakan rpID bersama yang sama dalam panggilan API WebAuthn mereka. Koordinasi ini sangat penting agar ROR berfungsi dengan benar.

Persyaratan koordinasi utama:

1. Tanggung jawab backend: Server menghasilkan cryptographic challenge dan menentukan rpID bersama baik dalam permintaan pembuatan kredensial maupun autentikasi.
2. Tanggung jawab frontend: Semua aplikasi klien (example.com, example.co.uk, example.de) harus meneruskan rpID bersama yang sama ke API navigator.credentials browser.
3. Manajemen konfigurasi: rpID bersama harus diperlakukan sebagai nilai konfigurasi global yang penting dan diterapkan secara konsisten di semua situs terkait.

Kesalahan konfigurasi bahkan di satu situs—di mana ia kembali ke originnya sendiri sebagai rpID alih-alih nilai bersama—akan merusak pengalaman passkey terpadu bagi pengguna di domain tersebut.

Penting: Server HARUS memverifikasi bidang origin di clientDataJSON untuk setiap permintaan, memastikan itu cocok dengan salah satu origin terkait yang diotorisasi. Verifikasi origin ini adalah mekanisme perlindungan phishing utama.

Related Origin Requests (ROR) dan protokol identitas terfederasi (OIDC/SAML) menyelesaikan masalah yang berbeda. ROR bukanlah pengganti untuk Single Sign-On—ini adalah pelengkap yang menangani kasus penggunaan spesifik yang sempit.

ROR cocok untuk satu aplikasi logis yang didistribusikan di beberapa domain terkait yang berbagi basis data pengguna yang sama:

• Satu merek yang mengoperasikan beberapa TLD kode negara (misalnya, amazon.com, amazon.de, amazon.co.uk)
• Semua domain berbagi sistem autentikasi backend dan basis data pengguna yang sama
• Anda ingin menghindari alur berbasis pengalihan dan menjaga autentikasi tetap kontekstual untuk setiap domain
• Domain Anda berada dalam batas 5 label
• Pengguna harus merasakan semua domain sebagai satu layanan yang kohesif

Apa yang disediakan ROR: Passkey yang sama berfungsi di semua domain terkait, menghilangkan kebutuhan pengguna untuk membuat passkey terpisah untuk setiap situs regional.

Gunakan protokol identitas terfederasi untuk Single Sign-On sejati di seluruh aplikasi yang berbeda:

• Beberapa layanan dengan basis data pengguna atau sistem identitas yang terpisah
• Skenario perusahaan di mana pengguna memerlukan akses ke banyak aplikasi berbeda (Salesforce, Office 365, alat internal)
• Integrasi aplikasi pihak ketiga
• Anda memerlukan kontrol akses terpusat, jejak audit, dan tata kelola identitas
• Anda melebihi batas 5 label untuk origin terkait

Apa yang disediakan OIDC/SAML: Autentikasi terpusat di mana pengguna masuk sekali di Identity Provider (IdP) dan mendapatkan akses ke beberapa Service Provider (SP) melalui token yang aman.

Penting: Passkey dapat digunakan dengan kedua pendekatan tersebut. Anda dapat mengimplementasikan passkey di IdP terpusat untuk SSO terfederasi, atau menggunakan ROR untuk satu aplikasi multi-domain. Pilih berdasarkan arsitektur Anda, bukan metode autentikasi Anda.

Meskipun ROR adalah solusi teknis yang kuat, implementasinya harus menjadi keputusan strategis yang disengaja. Arsitek dan manajer produk harus menimbang manfaatnya terhadap pola alternatif dan memahami keterbatasannya untuk membangun sistem autentikasi yang kuat dan siap untuk masa depan.

Batasan utama ROR adalah "batas label". "Label" dalam konteks ini mengacu pada domain level atas efektif plus satu level (eTLD+1), yang merupakan bagian yang dapat didaftarkan dari sebuah nama domain. Sebagai contoh:

• shopping.com, shopping.co.uk, dan shopping.ca semuanya berbagi satu label "shopping"
• myshoppingrewards.com memperkenalkan label baru yang berbeda: "myshoppingrewards"
• travel.shopping.com masih termasuk dalam label "shopping"

Spesifikasi WebAuthn Level 3 mengharuskan implementasi browser untuk mendukung minimal lima label unik dalam daftar origins. Hingga tahun 2025, tidak ada browser yang diketahui mendukung lebih dari minimal lima label ini. Oleh karena itu, organisasi harus merancang penerapan ROR mereka dengan mempertimbangkan batas keras ini—anggap lima sebagai maksimum yang efektif.

Batas ini adalah mekanisme anti-penyalahgunaan yang disengaja yang dirancang untuk mencegah penyalahgunaan. Ini menghentikan entitas seperti penyedia hosting bersama (misalnya, wordpress.com) dari membuat passkey universal yang dapat berfungsi di ribuan subdomain pelanggan yang tidak terkait, yang akan merusak model keamanan.

Bagi sebagian besar organisasi, bahkan merek multinasional besar, batas lima label ini cukup. Misalnya, berbagai TLD kode negara Amazon (amazon.com, amazon.de, amazon.co.uk, dll.) semuanya berbagi label "amazon", menyisakan empat slot label tambahan yang tersedia untuk merek lain dalam portofolio mereka seperti "audible" atau "zappos".

Kompleksitas penerapan ROR sangat bergantung pada apakah ia diperkenalkan ke dalam sistem baru atau dipasang pada sistem yang sudah ada.

• Penerapan Greenfield: Untuk proyek baru, strateginya sederhana. Satu domain kanonis harus dipilih sebagai rpID bersama sejak awal (misalnya, domain .com utama). rpID ini kemudian harus digunakan secara konsisten dalam konfigurasi semua situs web dan aplikasi terkait sejak hari pertama.
• Penerapan yang Sudah Ada: Memasang ROR pada sistem yang sudah memiliki passkey yang diterapkan dengan rpID yang berbeda di seluruh domainnya secara signifikan lebih kompleks. Migrasi langsung tidak mungkin dilakukan, karena passkey yang ada terikat secara permanen ke rpID aslinya. Pendekatan yang direkomendasikan dalam skenario ini adalah mengimplementasikan alur login "identifier-first". Pengguna pertama kali diminta untuk memasukkan nama pengguna atau email mereka. Backend kemudian melakukan pencarian untuk menentukan rpID mana yang terkait dengan passkey mereka. Akhirnya, pengguna diarahkan ke origin yang benar yang sesuai dengan rpID tersebut untuk menyelesaikan seremoni autentikasi. Setelah login berhasil, mereka dapat diarahkan kembali ke situs asli mereka. Ini adalah pekerjaan arsitektural yang cukup besar yang memerlukan perencanaan dan implementasi yang cermat.

Memahami bagaimana perusahaan-perusahaan mapan mengimplementasikan Related Origin Requests memberikan wawasan berharga untuk strategi penerapan Anda sendiri. Di bawah ini adalah contoh berdasarkan implementasi aktual (per Oktober 2025):

Microsoft menggunakan ROR untuk infrastruktur autentikasi mereka. Konfigurasi aktual di login.microsoftonline.com meliputi:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Pendekatan konservatif ini memungkinkan berbagi passkey antara portal login perusahaan dan konsumen Microsoft sambil mempertahankan perimeter keamanan yang terfokus.

Shopify mengimplementasikan ROR untuk menyatukan autentikasi di beberapa domain pilihan:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Konfigurasi ini memungkinkan Shopify menghubungkan platform utama mereka dengan aplikasi Shop mereka, menunjukkan pendekatan yang terfokus pada origin terkait.

Amazon memiliki file yang cukup besar:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Pola ini akan memungkinkan sebuah merek untuk menyediakan autentikasi passkey terpadu di seluruh domain regional sambil menggunakan domain .com utama sebagai rpID.

Contoh-contoh nyata ini mengungkapkan beberapa pola kunci:

1. Domain Utama sebagai rpID: Semua perusahaan menggunakan domain .com utama mereka sebagai rpID kanonis.
2. Pengelompokan Logis: Origin dikelompokkan berdasarkan fungsi bisnis daripada arsitektur teknis.
3. Cakupan Konservatif: Sebagian besar implementasi tetap berada jauh di bawah batas 5 label, biasanya menggunakan 3-4 origin.
4. Strategi Subdomain: Banyak yang menggunakan subdomain dari domain utama untuk menjaga konsistensi merek.

Sebagai standar web modern, ROR telah dirancang dengan keamanan sebagai pertimbangan utama dan sedang diadopsi secara aktif di seluruh browser utama.

Related Origin Requests tidak mengkompromikan jaminan anti-phishing inti WebAuthn. Mekanisme ini dirancang dengan cermat untuk mempertahankan postur keamanan yang kuat:

• Verifikasi Origin: Seperti yang telah dibahas, browser masih menyertakan origin sebenarnya dari permintaan dalam clientDataJSON yang ditandatangani. Server Relying Party HARUS memverifikasi origin ini untuk memastikan permintaan berasal dari sumber yang diharapkan, mencegah origin terkait yang disusupi meniru yang lain.
• Fetch Aman: Permintaan browser ke file .well-known/webauthn dibuat melalui HTTPS. Selain itu, spesifikasi mengamanatkan bahwa fetch ini dilakukan tanpa kredensial (misalnya, cookie) dan tanpa header Referer. Ini mencegah permintaan digunakan untuk membocorkan informasi pengguna atau untuk tujuan pelacakan lintas situs.
• Keamanan Server: File .well-known/webauthn itu sendiri menjadi aset keamanan yang penting. Penyerang yang mendapatkan kontrol atas server web yang menghosting rpID utama berpotensi memodifikasi file ini untuk menambahkan domain berbahaya mereka sendiri ke daftar izin. Oleh karena itu, mengamankan infrastruktur yang menyajikan file ini sangat penting.

Related Origin Requests adalah fitur dari spesifikasi WebAuthn Level 3. Dukungan browser mulai diluncurkan pada akhir tahun 2024:

Fakta kunci:

• Chrome dan Edge: Menambahkan dukungan ROR di versi 128 (Agustus 2024)
• Safari: Menambahkan dukungan ROR di Safari 18, tersedia di macOS 15 dan iOS 18 (September 2024)
• Firefox: Saat ini tidak ada dukungan untuk ROR; deteksi fitur dan implementasikan alur fallback

Untuk aplikasi yang perlu mendukung browser lama atau Firefox, terapkan strategi fallback:

1. Deteksi fitur: Periksa dukungan ROR menggunakan PublicKeyCredential.getClientCapabilities()
2. Alur identifier-first: Minta nama pengguna/email, cari rpID yang terkait dengan pengguna, lalu arahkan ke origin yang sesuai untuk autentikasi
3. Degradasi yang baik: Izinkan pengguna membuat passkey terpisah per domain jika ROR tidak tersedia

Data berdasarkan matriks dukungan saat ini per Oktober 2025.

Mengimplementasikan Related Origin Requests memerlukan koordinasi yang cermat antara beberapa tim teknis dan keahlian mendalam dalam protokol WebAuthn. Platform adopsi passkey Corbado menghilangkan kompleksitas ini dengan menyediakan solusi siap pakai untuk penerapan passkey multi-domain di tingkat perusahaan.

Corbado menangani kompleksitas teknis Related Origin Requests melalui:

• Konfigurasi Otomatis: Platform kami secara otomatis menghasilkan dan menghosting file .well-known/webauthn yang diperlukan dengan header keamanan dan format JSON yang tepat.
• Dasbor Multi-Domain: Antarmuka manajemen terpusat untuk mengonfigurasi origin terkait di seluruh portofolio domain Anda.
• Alat Validasi: Pengujian dan validasi bawaan untuk memastikan konfigurasi ROR Anda berfungsi dengan benar di semua browser dan platform.

Selain implementasi teknis, Corbado menyediakan kerangka keamanan yang dibutuhkan perusahaan:

• Verifikasi Origin: Validasi otomatis origin clientDataJSON untuk mencegah penyalahgunaan domain terkait.
• Pencatatan Audit: Pelacakan komprehensif penggunaan passkey di semua domain terkait untuk pemantauan kepatuhan dan keamanan.
• Respons Insiden: Peringatan real-time dan respons otomatis untuk upaya autentikasi lintas domain yang mencurigakan.

Untuk organisasi dengan penerapan passkey yang sudah ada, Corbado menawarkan:

• Alat Migrasi Legacy: Analisis otomatis konfigurasi rpID yang ada dan rekomendasi jalur migrasi.
• Alur Identifier-First: Komponen login siap pakai yang menangani skenario multi-rpID yang kompleks selama masa transisi.
• Integrasi API: API RESTful dan SDK yang terintegrasi secara mulus dengan infrastruktur autentikasi Anda yang sudah ada.

Siap mengimplementasikan Related Origin Requests untuk organisasi Anda? Tim ahli Corbado dapat membantu Anda merancang dan menerapkan pengalaman passkey terpadu di seluruh ekosistem digital Anda. Hubungi tim solusi kami untuk mendiskusikan kebutuhan spesifik dan jadwal Anda.

Janji passkey terletak pada kemampuannya untuk memberikan masa depan yang lebih aman dan lebih sederhana bagi pengguna. Namun, agar masa depan ini menjadi kenyataan dalam skala global, standar tersebut harus mengakomodasi kompleksitas arsitektural merek digital modern. Gesekan yang diciptakan oleh passkey yang terikat ketat pada domain telah menjadi penghambat adopsi yang signifikan bagi organisasi dengan kehadiran online yang beraneka ragam.

WebAuthn Related Origin Requests menyediakan solusi yang terstandarisasi, aman, dan elegan untuk masalah ini. Dengan memungkinkan satu passkey berfungsi secara mulus di seluruh sekumpulan domain terkait yang tepercaya, ROR menghilangkan titik kebingungan dan frustrasi utama bagi pengguna.

Panduan ini membahas lima pertanyaan penting untuk mengimplementasikan WebAuthn Related Origin Requests:

1. Mengapa passkey gagal di beberapa domain? Model keamanan WebAuthn yang terikat pada origin secara kriptografis mengunci passkey ke domain tertentu untuk mencegah phishing, tetapi ini menciptakan gesekan ketika merek beroperasi di beberapa domain seperti TLD negara yang berbeda.
2. Bagaimana cara kerja Related Origin Requests secara teknis? ROR menggunakan file .well-known/webauthn yang terstandarisasi untuk membuat daftar izin domain terkait yang dapat diverifikasi, memungkinkan browser memvalidasi penggunaan passkey lintas domain melalui proses fetch HTTPS yang aman.
3. Apa yang diperlukan untuk mengimplementasikan ROR? Implementasi memerlukan konfigurasi sisi server dari file manifes .well-known/webauthn dan koordinasi sisi klien untuk menggunakan rpID bersama secara konsisten di semua origin terkait.
4. Kapan sebaiknya memilih ROR daripada login terfederasi? Gunakan ROR untuk pengalaman merek terpadu di seluruh domain terkait dengan basis data pengguna bersama; gunakan OIDC/SAML untuk SSO sejati di seluruh aplikasi yang berbeda atau ketika melebihi batas 5 label.
5. Bagaimana cara menangani kompatibilitas browser dan pertimbangan keamanan? ROR didukung di browser utama mulai dari Chrome/Firefox 128+, Safari di macOS 15+, dan iOS 18+, dengan strategi fallback tersedia untuk browser lama melalui alur identifier-first.

Bagi tim teknis dan pemimpin produk, poin-poin pentingnya adalah:

• ROR memungkinkan pengalaman passkey terpadu untuk satu aplikasi logis yang tersebar di beberapa domain, seperti yang memiliki TLD kode negara yang berbeda atau branding alternatif.
• Implementasi memerlukan upaya terkoordinasi: file .well-known/webauthn di sisi server harus dipublikasikan di domain rpID utama, dan semua aplikasi sisi klien harus dikonfigurasi untuk menggunakan rpID bersama yang sama.
• Keputusan untuk menggunakan ROR adalah keputusan strategis. Ini adalah alat yang sangat baik untuk kasus penggunaan spesifiknya tetapi harus dipertimbangkan terhadap arsitektur login terfederasi yang lebih tradisional (OIDC/SAML), terutama dalam skenario yang melibatkan Single Sign-On sejati di seluruh aplikasi yang berbeda.

Fitur seperti Related Origin Requests sangat penting untuk momentum berkelanjutan dari gerakan tanpa kata sandi. Mereka menunjukkan komitmen dari badan standar untuk mengatasi tantangan implementasi di dunia nyata, memastikan bahwa manfaat passkey—keamanan tak tertandingi dan pengalaman pengguna yang mudah—dapat diakses bahkan oleh organisasi terbesar dan paling kompleks sekalipun. Seiring fitur ini mendapatkan dukungan browser universal, ia akan memainkan peran penting dalam meruntuhkan hambatan terakhir menuju internet yang benar-benar global dan tanpa kata sandi.