RP ID WebAuthn Membatasi Penggunaan Kredensial

Kredensial WebAuthn bukan key yang dapat diminta oleh situs mana pun dari authenticator. Registrasi dan autentikasi terikat pada relying party identifier, atau RP ID, sementara browser juga memeriksa origin pemanggil. Pasangan ini membentuk batas domain untuk kredensial public-key.

Pada deployment umum di https://login.example.com, RP dapat memakai host tersebut sebagai RP ID:

origin: https://login.example.com
RP ID:  login.example.com

RP juga dapat memakai suffix registrable domain seperti example.com jika deployment memerlukan kredensial untuk subdomain yang memenuhi syarat:

origin: https://login.example.com
RP ID:  example.com

Browser memvalidasi hubungan ini sebelum meneruskan operasi WebAuthn ke authenticator.

RP ID menjadi bagian dari identitas kredensial

Saat kredensial dibuat, authenticator mengaitkannya dengan RP ID. WebAuthn merepresentasikan ikatan tersebut melalui hash RP ID yang disimpan bersama authenticator data.

Pada ceremony autentikasi, authenticator menerima RP ID yang dipilih untuk request lalu menghasilkan authenticator data yang memuat hash SHA-256 dari nilai tersebut. Server memverifikasi field itu terhadap RP ID yang diharapkan.

rpIdHash = SHA-256(RP ID)

Pemeriksaan ini penting karena signature yang valid saja tidak membuktikan bahwa assertion ditujukan untuk relying party yang benar. Verifikasi server menggabungkan signature dengan konteks ceremony, termasuk challenge, origin, hash RP ID, dan field lain yang diwajibkan.

Browser membatasi pemilihan RP ID

Sebuah halaman tidak dapat memilih domain lain yang tidak terkait sebagai RP ID. WebAuthn mensyaratkan hubungan domain efektif pemanggil dengan RP ID sesuai aturan suffix registrable domain dalam spesifikasi.

Halaman di login.example.com umumnya dapat memakai login.example.com atau example.com. Halaman tersebut tidak dapat mengklaim bank.example.net hanya dengan menaruh nilai itu pada request WebAuthn.

login.example.com -> login.example.com   scope valid
login.example.com -> example.com         scope parent domain
login.example.com -> example.net         ditolak

Validasi di sisi browser ini mencegah situs berbahaya meminta authenticator secara langsung untuk memakai kredensial yang berada dalam scope relying party yang tidak terkait.

Origin dan RP ID diperiksa secara terpisah

RP ID dan origin saling terkait, tetapi keduanya tidak dapat dipertukarkan. RP ID menentukan scope kredensial yang dipakai authenticator. Origin menunjukkan web security origin yang memulai ceremony dan dibawa di dalam clientDataJSON.

Server perlu membandingkan origin yang dikembalikan dengan origin atau kumpulan origin yang diizinkan secara eksplisit. Server juga perlu memverifikasi bahwa rpIdHash cocok dengan RP ID yang dikonfigurasi.

clientDataJSON.origin -> origin yang diharapkan
authenticatorData.rpIdHash -> SHA-256(RP ID yang diharapkan)

Memeriksa hanya satu sisi menyisakan sebagian konteks ceremony tanpa verifikasi.

Scope parent domain memperluas batas kepercayaan

Pemilihan example.com sebagai RP ID dapat mendukung autentikasi dari beberapa subdomain yang memenuhi syarat. Pola ini dapat berguna untuk arsitektur sign-in yang memang dibagi, tetapi batas domainnya lebih luas dibandingkan login.example.com.

Pemilihan sebaiknya mengikuti model deployment, bukan sekadar kemudahan. Jika autentikasi hanya dilakukan oleh satu host, RP ID khusus host menjaga scope kredensial tetap sempit. Jika beberapa subdomain harus berbagi scope kredensial yang sama, pemakaian parent domain perlu diperlakukan sebagai keputusan batas keamanan yang eksplisit.

Kepemilikan domain tidak otomatis membuat setiap aplikasi di bawah domain tersebut memiliki tingkat kepercayaan yang sama. Siklus hidup subdomain, hosting yang didelegasikan, dan isolasi aplikasi tetap relevan saat RP ID parent domain dipakai.

Challenge tetap mengikat setiap ceremony

Scope RP ID tidak menggantikan challenge. Server membuat challenge baru untuk ceremony registrasi atau autentikasi, lalu memverifikasi bahwa clientDataJSON yang dikembalikan memuat nilai yang diharapkan.

Challenge mengikat response ke ceremony yang dimulai server. RP ID membatasi scope relying party dari kredensial. Verifikasi origin mengidentifikasi web origin pemanggil. Kontrol ini menangani bagian protokol yang berbeda dan tidak seharusnya dilebur menjadi satu pemeriksaan.

Server juga memvalidasi tipe ceremony, seperti webauthn.create atau webauthn.get, beserta field lain yang diwajibkan oleh prosedur verifikasi WebAuthn yang diterapkan.

Konfigurasi harus konsisten antara registrasi dan sign-in

Mengubah RP ID setelah kredensial dibuat dapat membuat kredensial tersebut tidak tersedia untuk autentikasi berikutnya di scope baru. Migrasi dari RP ID khusus host ke RP ID parent domain karena itu bukan sekadar perubahan label tampilan.

Endpoint registrasi dan autentikasi sebaiknya memperoleh RP ID yang diharapkan dari konfigurasi yang stabil. Reverse proxy dan framework aplikasi dapat memengaruhi host yang terlihat pada request, tetapi verifikasi server tidak seharusnya mengubah data host masuk yang arbitrer menjadi RP ID tepercaya secara otomatis.

Disiplin yang sama berlaku untuk allowlist origin. Deployment dengan beberapa origin sah perlu mencantumkan kumpulan yang diterima sesuai arsitekturnya, bukan menerima setiap origin yang hanya tampak serupa dengan host request.

Verifikasi berada di batas server

Browser menegakkan prasyarat penting sebelum menjalankan WebAuthn, tetapi relying party tetap memiliki pekerjaan verifikasi. Untuk autentikasi, pemeriksaan itu mencakup challenge, origin, hash RP ID, signature, serta authenticator data dan status kredensial yang relevan.

Scope RP ID paling efektif ketika diperlakukan sebagai bagian tetap dari model keamanan relying party. Scope yang sempit membatasi tempat kredensial dapat berpartisipasi, sedangkan pemeriksaan server yang eksplisit memastikan signed assertion hanya diterima dalam konteks ceremony yang sesuai.

Referensi

Cybersecurity WebAuthn Autentikasi Passkeys