---
url: 'https://www.corbado.com/id/blog/webauthn-related-origins-passkey-lintas-domain'
title: 'WebAuthn Related Origins: Panduan Passkey Lintas Domain'
description: 'Pelajari cara kerja WebAuthn Related Origin Requests untuk mengaktifkan passkey di banyak domain. Panduan implementasi lengkap dengan contoh nyata.'
lang: 'id'
author: 'Vincent Delitz'
date: '2025-10-31T14:41:16.283Z'
lastModified: '2026-03-25T10:06:52.931Z'
keywords: 'related origins, webauthn related origin, related origin request, passkey lintas domain, .well-known/webauthn, ROR'
category: 'WebAuthn Know-How'
---

# WebAuthn Related Origins: Panduan Passkey Lintas Domain

## 1. Pendahuluan: Membongkar Batasan Digital untuk Passkey

Passkey adalah standar baru untuk
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang aman dan
user-friendly. Dibangun di atas standar FIDO/WebAuthn, passkey memanfaatkan
[kriptografi kunci publik](https://www.corbado.com/id/blog/webauthn-pubkeycredparams-credentialpublickey) untuk
menawarkan ketahanan bawaan terhadap [phishing](https://www.corbado.com/glossary/phishing) dan
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing), yang secara dramatis meningkatkan
postur [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) 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](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) 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](https://www.corbado.com/glossary/phishing). Meskipun ini adalah fitur
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) 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](https://www.corbado.com/blog/x-twitter-passkeys)
menjadi X. Pengguna yang membuat passkey di [twitter](https://www.corbado.com/blog/x-twitter-passkeys).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](https://developer.chrome.com/blog/passkeys-updates-chrome-129)
bagi sekelompok domain tepercaya untuk berbagi satu passkey, menciptakan pengalaman
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang terpadu dan mulus di
seluruh ekosistem digital suatu merek. Pembahasan mendalam ini akan mengeksplorasi
dasar-dasar teknis [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys), memberikan
panduan praktis untuk implementasinya, dan menganalisis implikasi strategisnya bagi
arsitektur [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) modern.

Pengenalan [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) menandai pematangan
signifikan dari standar WebAuthn. Spesifikasi awal memprioritaskan penetapan
[prinsip-prinsip kriptografi dan keamanan inti](https://www.w3.org/TR/webauthn-3/), dengan
pengikatan ketat kredensial ke ID [Relying Party](https://www.corbado.com/glossary/relying-party) (rpID) sebagai
landasan desain anti-[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests).

## 2. Akar Masalah: ID Relying Party WebAuthn dan Cakupan Origin

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](https://www.corbado.com/glossary/relying-party) (rpID) WebAuthn.
Mekanisme ini merupakan dasar keamanan web tetapi menciptakan gesekan yang dirancang untuk
diatasi oleh ROR.

### 2.1 Web Origin dan Same-Origin Policy

"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**](https://developer.mozilla.org/en-US/docs/Web/Security/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.

### 2.2 Relying Party ID (rpID)

Dalam ekosistem WebAuthn, "[Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/id/faq/bagaimana-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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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.

## 3. Solusi: Cara Kerja Related Origin Requests

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](https://www.corbado.com/blog/webauthn-errors).
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](https://www.corbado.com/blog/how-to-enable-passkeys-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.

## 4. Panduan Implementasi Praktis untuk Related Origins

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.

### 4.1 Sisi Server: Mengotorisasi Origin dengan .well-known/webauthn

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

#### 4.1.1 Lokasi dan Format File

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`.

#### 4.1.2 Struktur 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.

```json
{
    "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`).

### 4.2 Sisi Klien: Memanggil rpID bersama

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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/clientdatajson) untuk setiap permintaan, memastikan itu cocok
dengan salah satu origin terkait yang diotorisasi. Verifikasi origin ini adalah mekanisme
perlindungan phishing utama.

## 5. Rekomendasi: Pilih ROR untuk Pengalaman Merek Terpadu, OIDC untuk SSO Sejati

**Related Origin Requests (ROR) dan protokol identitas terfederasi (OIDC/SAML)
menyelesaikan masalah yang berbeda.** ROR bukanlah pengganti untuk
[Single Sign-On](https://www.corbado.com/blog/passkeys-single-sign-on-sso)—ini adalah pelengkap yang menangani
kasus penggunaan spesifik yang sempit.

### 5.1 Kapan menggunakan Related Origin Requests

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.

### 5.2 Kapan menggunakan Federated Login (OIDC/SAML)

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](https://www.corbado.com/blog/passkeys-single-sign-on-sso)
terfederasi, atau menggunakan ROR untuk satu aplikasi multi-domain. Pilih berdasarkan
arsitektur Anda, bukan metode autentikasi Anda.

## 6. Pertimbangan Strategis untuk Arsitektur Passkey 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.

### 6.1 Memahami Batas 5 Label

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".

### 6.2 Strategi Penerapan: Greenfield vs. Sistem yang Sudah Ada

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.

## 7. Contoh Nyata: Bagaimana Merek Besar Mengimplementasikan Related Origins

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):

### 7.1 Implementasi Microsoft

Microsoft menggunakan ROR untuk [infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure)
autentikasi mereka. Konfigurasi aktual di `login.microsoftonline.com` meliputi:

```json
// 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.

### 7.2 Implementasi Shopify

[Shopify](https://www.corbado.com/blog/shopify-passkeys) mengimplementasikan ROR untuk menyatukan autentikasi di
beberapa domain pilihan:

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

Konfigurasi ini memungkinkan [Shopify](https://www.corbado.com/blog/shopify-passkeys) menghubungkan platform
utama mereka dengan aplikasi Shop mereka, menunjukkan pendekatan yang terfokus pada origin
terkait.

### 7.3 Implementasi Amazon

Amazon memiliki file yang cukup besar:

```json
// 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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) terpadu di seluruh domain
regional sambil menggunakan domain `.com` utama sebagai rpID.

### 7.4 Pola Implementasi dan Praktik Terbaik

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.

## 8. Dukungan Browser dan Postur Keamanan

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

### 8.1 Model Keamanan

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](https://www.corbado.com/passkeys-for-critical-infrastructure) yang menyajikan file ini sangat
  penting.

### 8.2 Dukungan Browser dan Platform

Related Origin Requests adalah fitur dari spesifikasi
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn). Dukungan browser mulai diluncurkan pada
akhir tahun 2024:

| **Sistem Operasi** | **Browser / Platform** | **Dukungan Versi**    | **Status**          |
| ------------------ | ---------------------- | --------------------- | ------------------- |
| Android            | Chrome, Edge           | 128+                  | ✅ Didukung         |
| Chrome OS          | Chrome, Edge           | 128+                  | ✅ Didukung         |
| iOS / iPadOS       | Semua Browser (Safari) | iOS 18+               | ✅ Didukung         |
| macOS              | Chrome, Edge           | 128+                  | ✅ Didukung         |
| macOS              | Safari                 | Safari 18 (macOS 15+) | ✅ Didukung         |
| Ubuntu             | Chrome, Edge           | 128+                  | ✅ Didukung         |
| Windows            | Chrome, Edge           | 128+                  | ✅ Didukung         |
| Semua Platform     | Firefox                | Tidak didukung        | ⚠️ Gunakan fallback |

**Fakta kunci:**

- **Chrome dan Edge:** Menambahkan dukungan ROR di versi 128 (Agustus 2024)
- **Safari:** Menambahkan dukungan ROR di
  [Safari 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades), tersedia di macOS 15 dan
  [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) (September 2024)
- **Firefox:** Saat ini tidak ada dukungan untuk ROR; deteksi fitur dan implementasikan
  alur fallback

### Deteksi Fitur dan 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.

## 9. Bagaimana Corbado dapat membantu

Mengimplementasikan Related Origin Requests memerlukan koordinasi yang cermat antara
beberapa tim teknis dan keahlian mendalam dalam protokol WebAuthn. Platform
[adopsi passkey](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey) Corbado menghilangkan kompleksitas
ini dengan menyediakan solusi siap pakai untuk penerapan passkey multi-domain di tingkat
perusahaan.

### 9.1 Implementasi ROR yang Disederhanakan

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.

### 9.2 Keamanan dan Kepatuhan Tingkat Perusahaan

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.

### 9.3 Dukungan Migrasi dan Integrasi

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](https://www.corbado.com/passkeys-for-critical-infrastructure) autentikasi Anda yang sudah ada.

### 9.4 Memulai

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](https://www.corbado.com/contact) untuk
mendiskusikan kebutuhan spesifik dan jadwal Anda.

## 10. Kesimpulan: Masa Depan yang Mulus untuk Passkey Multi-Domain

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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) 18+, dengan strategi fallback tersedia untuk
   browser lama melalui alur identifier-first.

### Poin-Poin Penting

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](https://www.corbado.com/blog/passkeys-single-sign-on-sso) sejati di seluruh
  aplikasi yang berbeda.

Fitur seperti Related Origin Requests sangat penting untuk momentum berkelanjutan dari
gerakan [tanpa kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android). 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.