Mengelola kunci sandi di beberapa domain dan aplikasi dengan ID RP

Eiji Kitamura

Di WebAuthn dan kunci sandi, ID pihak tepercaya (RP ID) menentukan cakupan kredensial berdasarkan nama domain. Saat Anda membuat kunci sandi, browser akan mengikatnya ke ID RP tertentu. Browser kemudian mencegah penggunaan kunci sandi tersebut di domain yang tidak cocok atau berada dalam cakupan ID tersebut. Menentukan RP ID dengan benar memastikan pengalaman kunci sandi yang lancar di seluruh subdomain, origin lintas situs, dan aplikasi seluler pihak pertama.

Dasar-dasar ID RP

ID Pihak Tepercaya (RP ID) adalah string unik yang mengidentifikasi layanan atau situs Anda. ID RP harus berupa string domain. Nilai ini dapat berupa nama host saat ini yang sama persis atau domain induk yang lebih luas, asalkan berupa eTLD+1 atau yang lebih tinggi. Anda tidak dapat menggunakan alamat IP dan Suffix Publik (eTLD) sebagai ID RP.

Misalnya, jika Anda menghosting server di https://www.example.com, Anda dapat menggunakan example.com atau www.example.com sebagai ID RP-nya, bergantung pada kebutuhan spesifik. Tabel berikut menunjukkan contoh ID RP yang diizinkan, bergantung pada host asal Anda:

Host asal ID RP yang diizinkan (eTLD+1)
https://login.example.com example.com atau login.example.com
https://example.com:8080 example.com (nomor port tidak disertakan)
https://mobile.example.co.jp example.co.jp atau mobile.example.co.jp
https://sub.project.org.uk project.org.uk atau sub.project.org.uk
https://user.github.io user.github.io (github.io adalah eTLD)
https://myapp.pages.dev myapp.pages.dev (pages.dev adalah eTLD)
http://localhost localhost (pengecualian terhadap persyaratan HTTPS)

Browser mengikat kunci sandi secara kriptografis ke ID RP saat Anda membuatnya. Untuk menggunakan kredensial, asal permintaan autentikasi harus cocok dengan RP ID tersebut.

Jika Anda menggunakan eTLD+1 sebagai ID RP, kunci sandi akan berfungsi di seluruh subdomain terkait. Misalnya, ID RP example.com berfungsi untuk https://login.example.com dan https://shop.example.com. RPID yang lebih spesifik seperti login.example.com berfungsi pada asal persisnya, tetapi tidak pada https://shop.example.com.

ID RP dalam konteks lintas situs

Jika layanan Anda mencakup beberapa eTLD+1 (misalnya, example.com dan example.co.jp), ini adalah konfigurasi lintas situs. ID RP standar tidak mendukung penyiapan lintas situs.

Untuk membagikan kunci sandi di antara situs yang berbeda, gunakan Permintaan Asal Terkait (ROR). ROR memungkinkan Anda membagikan kunci sandi antar-situs yang berbeda karena klien (browser) mengenali asal yang berbeda sebagai bagian dari layanan logis yang sama.

Persyaratan untuk ROR:

  • Pilih satu ID RP: Anda harus memilih satu ID RP dan menggunakannya di semua situs.
  • Menghosting file konfigurasi: Domain ID RP utama harus menghosting file konfigurasi di /.well-known/webauthn yang mencantumkan origin yang diizinkan.
  • Pertahankan konsistensi: Meskipun pengguna berada di https://www.example.co.jp, rpId dalam panggilan WebAuthn harus menjadi yang utama (misalnya, example.com) baik saat pembuatan maupun autentikasi.

Contoh ROR untuk ID RP example.com: https://example.com/.well-known/webauthn

{
  "origins": [
    "https://www.example.co.jp",
    "https://shop.example"
  ]
}

Untuk mengetahui informasi selengkapnya tentang detail penerapan Permintaan Asal Terkait, lihat Mengizinkan penggunaan ulang kunci sandi di seluruh situs Anda dengan Permintaan Asal Terkait

ID RP di aplikasi seluler

Aplikasi seluler dapat menggunakan kunci sandi dengan mengaitkan ke domain web. Anda harus menghosting file verifikasi di server Anda untuk membuat hubungan ini.

Credential Manager Android memerlukan file Digital Asset Link (DAL) di domain ID RP untuk dikaitkan dengan aplikasi.

  • Hosting: Hosting file di https://<RP ID>/.well-known/assetlinks.json.
  • Verifikasi: Verifikasi origin di clientDataJSON. Untuk Android, ini adalah string seperti android:apk-key-hash:<hash>.

Contoh DAL untuk ID RP example.com (dihosting di https://example.com/.well-known/assetlinks.json)

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.google.credentialmanager.sample",
      "sha256_cert_fingerprints": [
        "4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
      ]
    }
  }
]

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Digital Asset Links antara aplikasi dan situs Anda

iOS: Domain Terkait

Platform Apple memerlukan file apple-app-site-association (AASA) di domain ID RP untuk dikaitkan dengan aplikasi.

  • File AASA: Host https://<RP_ID>/.well-known/apple-app-site-association.
  • Hak: Tambahkan webcredentials:<app info> ke hak aplikasi.

Contoh AASA untuk ID RP example.com: https://example.com/.well-known/apple-app-site-association:

{
  "webcredentials":
    {
      "apps": ["EXAMPLE123.com.example.passkey"]
    }
}

Untuk mengetahui informasi selengkapnya, lihat Menghubungkan ke layanan dengan kunci sandi di Dokumentasi Apple Developer.

Ringkasan

ID RP menentukan tempat pengguna Anda mengakses kunci sandi mereka. Ingatlah poin-poin berikut saat Anda menerapkan:

  • Hierarki dan subdomain: ID RP harus berupa string domain (eTLD+1 atau lebih tinggi). Menggunakan domain yang lebih luas seperti example.com memungkinkan kunci sandi berfungsi di semua subdomain (misalnya, login.example.com dan shop.example.com).
  • Solusi lintas situs: Gunakan Permintaan Asal Terkait (ROR) untuk layanan yang mencakup beberapa eTLD+1. Hal ini memerlukan satu ID RP dan file konfigurasi di /.well-known/webauthn.
  • Integrasi seluler: Buat hubungan terverifikasi antara situs dan aplikasi seluler Anda menggunakan file Digital Asset Links (DAL) di /.well-known/assetlinks.json untuk Android dan file apple-app-site-association (AASA) di /.well-known/apple-app-site-association untuk iOS.

Pelajari lebih lanjut