Izinkan penggunaan ulang kunci sandi di seluruh situs Anda dengan Permintaan Asal Terkait

Maud Nalpas
Maud Nalpas

Kunci sandi terikat dengan situs tertentu dan hanya dapat digunakan untuk login di situs tempatnya dibuat.

Hal ini ditentukan dalam ID pihak tepercaya (ID RP), yang untuk kunci sandi yang dibuat untuk domain example.com dapat berupa www.example.com atau example.com.

Meskipun ID RP mencegah kunci sandi digunakan sebagai kredensial tunggal untuk autentikasi di mana saja, ID RP akan menimbulkan masalah untuk:

  • Situs dengan beberapa domain: Pengguna tidak dapat menggunakan kunci sandi yang sama untuk login di berbagai domain khusus negara (misalnya example.com, dan example.co.uk) yang dikelola oleh perusahaan yang sama.
  • Domain bermerek: Pengguna tidak dapat menggunakan kredensial yang sama di berbagai domain yang digunakan oleh satu merek (misalnya acme.com dan acmerewards.com).
  • Aplikasi seluler: Aplikasi seluler sering kali tidak memiliki domainnya sendiri, sehingga pengelolaan kredensial menjadi sulit.

Ada solusi berdasarkan federasi identitas, dan solusi lainnya berdasarkan iframe, tetapi solusi tersebut tidak praktis dalam beberapa kasus. Permintaan Asal Terkait menawarkan solusi.

Solusi

Dengan Permintaan Asal Terkait, situs dapat menentukan asal yang diizinkan untuk menggunakan ID RP-nya.

Hal ini membuka kemungkinan bagi pengguna untuk menggunakan kembali kunci sandi yang sama di beberapa situs yang Anda operasikan.

Untuk menggunakan Permintaan Asal Terkait, Anda harus menayangkan file JSON khusus di https://{RP ID}/.well-known/webauthn URL tertentu. Jika example.com ingin mengizinkan origin tambahan menggunakannya sebagai ID RP, origin tersebut harus menayangkan file berikut di https://example.com/.well-known/webauthn:

{
   
"origins": [
       
"https://example.co.uk",
       
"https://example.de",
       
"https://example-rewards.com"
   
]
}

Saat berikutnya salah satu situs ini melakukan panggilan untuk pembuatan kunci sandi (navigator.credentials.create) atau autentikasi (navigator.credentials.get) yang menggunakan example.com sebagai ID RP, browser akan melihat ID RP yang tidak cocok dengan origin yang meminta. Jika mendukung Permintaan Origen Related, browser akan terlebih dahulu mencari file webauthn di https://{RP ID}/.well-known/webauthn. Jika file ada, browser akan memeriksa apakah origin yang membuat permintaan diizinkan dalam file tersebut. Jika ya, Anda akan melanjutkan ke langkah-langkah pembuatan kunci sandi atau autentikasi. Jika tidak mendukung Permintaan Origin Terkait, browser akan menampilkan SecurityError.

Dukungan browser

  • Chrome: Didukung mulai dari Chrome 128.
  • Safari: Didukung mulai dari macOS 15 beta 3, dan di perangkat seluler iOS 18 beta 3.
  • Firefox: Menunggu posisi.

Demo berikut menggunakan contoh dua situs, https://ror-1.glitch.me dan https://ror-2.glitch.me.
Untuk memungkinkan pengguna login dengan kunci sandi yang sama di kedua situs tersebut, situs tersebut menggunakan Permintaan Asal Terkait untuk mengizinkan ror-2.glitch.me menggunakan ror-1.glitch.me sebagai ID RP-nya.

Demo

https://ror-2.glitch.me menerapkan Permintaan Asal Terkait untuk menggunakan ror-1.glitch.me sebagai ID RP, sehingga ror-1 dan ror-2 menggunakan ror-1.glitch.me sebagai ID RP saat membuat kunci sandi atau mengautentikasi dengan kunci sandi tersebut.
Kami juga telah menerapkan database kunci sandi bersama di seluruh situs ini.

Amati pengalaman pengguna berikut:

  • Anda berhasil membuat kunci sandi, dan mengautentikasi dengan kunci sandi tersebut, di ror-2—meskipun ID RP-nya adalah ror-1 (dan bukan ror-2).
  • Setelah membuat kunci sandi di ror-1 atau ror-2, Anda dapat melakukan autentikasi dengan kunci sandi tersebut di ror-1 dan ror-2. Karena ror-2 menentukan ror-1 sebagai ID RP, membuat permintaan pembuatan kunci sandi atau autentikasi dari situs mana pun di sini sama dengan membuat permintaan di ror-1. ID RP adalah satu-satunya hal yang mengaitkan permintaan ke origin.
  • Setelah Anda membuat kunci sandi di ror-1 atau ror-2, kunci sandi tersebut dapat diisi otomatis oleh Chrome di ror-1 dan ror-2.
  • Kredensial yang dibuat di salah satu situs ini akan memiliki ID RP ror-1.
Chrome akan mengisi otomatis di kedua situs tersebut.
Berkat Permintaan Origin Terkait, pengguna dapat menggunakan kredensial kunci sandi yang sama di ror-1 dan ror-2. Chrome juga akan mengisi otomatis kredensial.

Lihat kode:

Langkah 1: Terapkan database akun bersama

Jika Anda ingin pengguna dapat login dengan kunci sandi yang sama di site-1 dan site-2, terapkan database akun yang dibagikan di kedua situs ini.

Langkah 2: Siapkan file JSON .well-known/webauthn di situs-1

Pertama, konfigurasikan site-1.com sehingga memungkinkan site-2.com menggunakannya sebagai ID RP. Untuk melakukannya, buat file JSON webauthn:

{
   
"origins": [
       
"https://site-2.com"
   
]
}

Objek JSON harus berisi origin bernama kunci yang nilainya adalah array dari satu atau beberapa string yang berisi origin web.

Batasan penting: Maksimum 5 label

Setiap elemen dalam daftar ini akan diproses untuk mengekstrak label eTLD + 1. Misalnya, label eTLD + 1 dari example.co.uk dan example.de adalah example. Namun, label eTLD + 1 dari example-rewards.com adalah example-rewards. Di Chrome, jumlah label maksimum adalah 5.

Langkah 3: Tayangkan JSON .well-known/webauthn di situs-1

Kemudian, tayangkan file JSON Anda di site-1.com/.well-known/webauthn.

Misalnya, di express:

app.get("/.well-known/webauthn", (req, res) => {
 
const origins = {
    origins
: ["https://site-2.com"],
 
};
 
return res.json(origins);
});

Di sini, kita menggunakan res.json ekspres, yang telah menetapkan content-type yang benar ('application/json');

Langkah 4: Tentukan ID RP yang diinginkan di situs-2

Di codebase site-2, tetapkan site-1.com sebagai ID RP di mana pun diperlukan:

  • Setelah pembuatan kredensial:
    • Tetapkan site-1.com sebagai ID RP dalam pembuatan kredensial options yang diteruskan ke panggilan frontend navigator.credentials.create, dan biasanya dihasilkan di sisi server.
    • Tetapkan site-1.com sebagai ID RP yang diharapkan, saat Anda menjalankan verifikasi kredensial sebelum menyimpannya ke database.
  • Setelah autentikasi:
    • Tetapkan site-1.com sebagai ID RP dalam autentikasi options yang diteruskan ke panggilan frontend navigator.credentials.get, dan biasanya dibuat sisi server.
    • Tetapkan site-1.com sebagai ID RP yang diharapkan untuk diverifikasi di server, saat Anda menjalankan verifikasi kredensial sebelum mengautentikasi pengguna.

Pemecahan masalah

Pop-up pesan error di Chrome.
Pesan error di Chrome saat membuat kredensial. Error ini ditampilkan jika file `.well-known/webauthn` Anda tidak dapat ditemukan di `https://{ID RP}/.well-known/webauthn`.
Pop-up pesan error di Chrome.
Pesan error di Chrome saat membuat kredensial. Error ini ditampilkan jika file `.well-known/webauthn` dapat ditemukan, tetapi tidak mencantumkan asal yang Anda coba buat kredensialnya.

Pertimbangan lainnya

Membagikan kunci sandi di seluruh situs dan aplikasi seluler

Permintaan Origin Terkait memungkinkan pengguna menggunakan kembali kunci sandi di beberapa situs. Untuk mengizinkan pengguna menggunakan kembali kunci sandi di seluruh situs dan aplikasi seluler, gunakan teknik berikut:

Membagikan sandi di seluruh situs

Permintaan Origin Terkait memungkinkan pengguna Anda menggunakan kembali kunci sandi di seluruh situs. Solusi untuk berbagi sandi di seluruh situs bervariasi di antara pengelola sandi. Untuk Pengelola Sandi Google, gunakan Digital Asset Links . Safari memiliki sistem yang berbeda.

Peran pengelola kredensial dan agen pengguna

Hal ini melampaui cakupan Anda sebagai developer situs, tetapi perhatikan bahwa dalam jangka panjang, ID RP tidak boleh menjadi konsep yang terlihat oleh pengguna di agen pengguna atau pengelola kredensial yang digunakan pengguna Anda. Sebagai gantinya, agen pengguna dan pengelola kredensial harus menunjukkan kepada pengguna tempat kredensial mereka telah digunakan. Perubahan ini akan memerlukan waktu untuk diterapkan. Solusi sementaranya adalah menampilkan situs saat ini dan situs pendaftaran asli.