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

Maud Nalpas

Masalah yang diselesaikan oleh Permintaan Asal Terkait

Kunci sandi dikaitkan ke situs tertentu dan hanya dapat digunakan untuk login di situs tempatnya dibuat.

Hal ini ditetapkan dalam kolom pihak tepercaya ID (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 melakukan otentikasi di mana-mana, mereka menimbulkan masalah untuk:

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

Terdapat solusi berdasarkan penggabungan identitas, dan solusi lainnya berdasarkan iframe, tetapi tidak praktis dalam beberapa kasus. Penawaran Permintaan Origin Terkait sebuah solusi.

Catatan: ID RP melakukan kredensial terpisah di antara berbagai situs, tetapi phishing perlindungan sebenarnya berasal dari verifikasi asal situs di kolom CollectedClientData.

Solusi

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

Dengan begitu, pengguna dapat menggunakan kembali kunci sandi yang sama di beberapa situs yang Anda operasikan.

Untuk menggunakan Permintaan Origin Terkait, Anda harus menyajikan file JSON khusus di URL spesifik https://{RP ID}/.well-known/webauthn. Jika example.com ingin memungkinkan origin tambahan menggunakannya sebagai ID RP, hal berikut harus file 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 browser mendukung Asal Terkait Permintaan, mula-mula akan mencari File webauthn di https://{RP ID}/.well-known/webauthn. Jika filenya ada, browser akan memeriksa apakah origin yang membuat permintaan diizinkan dalam . Jika demikian, Anda akan melanjutkan ke 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.

Peringatan: Mulai Agustus 2024, Permintaan Origin Terkait tidak didukung di Firefox, dan getClientCapabilities belum tersedia bagi Anda untuk mendeteksi fitur yang hilang dan menerapkan penggantian. Jika Anda menerapkan Permintaan Asal Terkait, pengguna Firefox tidak akan dapat membuat kunci sandi (atau login dengan kunci tersebut) di domain yang ingin menggunakan situs lain sebagai ID RP dan SecurityError akan ditampilkan.

Cara menyiapkan Permintaan Origin Terkait

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

Demo

Catatan: Buka demo di salah satu browser yang didukung.

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 setelah membuat kunci sandi atau mengautentikasi dengan kunci sandi tersebut.
Kami juga telah mengimplementasikan database kunci sandi bersama di seluruh situs ini.

Amati pengalaman pengguna berikut:

• Anda berhasil membuat kunci sandi, dan melakukan autentikasi dengan kunci tersebut, di ror-2—meskipun ID RP-nya adalah ror-1 (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 pembuatan kunci sandi atau permintaan autentikasi dari salah satu situs tersebut 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 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.

Berkat Permintaan Asal Terkait, pengguna dapat menggunakan kredensial kunci sandi yang sama di ror-1 dan ror-2. Chrome juga akan mengisi otomatis kredensial.

Lihat kode:

• Lihat file ./well-known/webauthn yang disiapkan di codebase ror-1.
• Lihat RP_ID_ROR kejadian di codebase ror-2.

Catatan: Dalam demo ini, agar lebih mudah, tidak ada pemeriksaan sandi yang sebenarnya dilakukan di balik layar. Demo ini berfokus pada kunci sandi.

Langkah 1: Implementasikan database akun bersama

Jika Anda ingin pengguna dapat login dengan kunci sandi yang sama di seluruh site-1 dan site-2, mengimplementasikan database akun yang dibagikan di seluruh di dua situs.

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

Pertama, konfigurasi site-1.com sedemikian rupa agar site-2.com dapat menggunakannya sebagai ID RP. Untuk melakukannya, buat file JSON webauthn Anda:

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

Objek JSON harus berisi kunci bernama origin yang nilainya adalah array satu atau lebih banyak string yang berisi asal web.

Batasan penting: Maksimum 5 label

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

Peringatan: Jika daftar Anda berisi terlalu banyak label (lebih dari 5), label yang ditampilkan elemen akan diabaikan.

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

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

Perhatian: File harus ditayangkan dengan jenis konten application/json dan berisi listingan objek JSON tunggal origin yang diizinkan. Format yang benar untuk file ini adalah: /.well-known/webauthn (jangan sertakan ekstensi .json).

Misalnya, secara ekspres:

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 sudah menetapkan content-type ('application/json') yang benar;

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

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

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

Catatan: Bagaimana dengan origin? Dan RP name? Di codebase situs-2 Anda, origin yang diharapkan tidak boleh berubah (https://site-2.com), karena menetapkan lokasi permintaan dari mana asalnya. Sesuai dengan nama RP (rp.name), nama ini tidak digunakan dalam praktiknya. Anda dapat mengosongkannya.

Pemecahan masalah

Pesan error di Chrome saat pembuatan kredensial. Error ini ditampilkan jika file `.well-known/webauthn` tidak dapat ditemukan di `https://{RP ID}/.well-known/webauthn`.

Pesan error di Chrome saat pembuatan kredensial. Error ini ditampilkan jika file `.well-known/webauthn` Anda dapat ditemukan, tetapi tidak mencantumkan asal kredensial yang Anda coba buat.

Pertimbangan lainnya

Bagikan kunci sandi ke seluruh situs dan aplikasi seluler

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

• Di Chrome: Digital Asset Link. Pelajari lebih lanjut di Menambahkan dukungan untuk Digital Asset Links.
• Di Safari: Domain terkait.

Membagikan sandi di seluruh situs

Permintaan Asal Terkait memungkinkan pengguna Anda menggunakan kembali kunci sandi di seluruh situs. Solusi untuk membagikan sandi di berbagai situs berbeda-beda untuk setiap 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 , 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 kredensial pengelola harus menunjukkan kepada pengguna tempat kredensial mereka digunakan. Perubahan ini akan membutuhkan waktu untuk diterapkan. Solusi sementaranya adalah menampilkan situs web saat ini dan situs pendaftaran asli.