Zarządzanie kluczami dostępu w wielu domenach i aplikacjach za pomocą identyfikatora RP

Eiji Kitamura

W przypadku WebAuthn i kluczy dostępu identyfikator podmiotu zależnego określa zakres danych logowania według nazwy domeny. Gdy tworzysz klucz dostępu, przeglądarka wiąże go z określonym identyfikatorem RP. Przeglądarka uniemożliwia następnie używanie klucza dostępu w domenie, która nie pasuje do tego identyfikatora lub nie mieści się w jego zakresie. Prawidłowe zdefiniowanie identyfikatora RP zapewnia bezproblemowe korzystanie z kluczy dostępu w przypadku subdomen, źródeł w różnych witrynach i aplikacji mobilnych własnych.

Podstawowe informacje o identyfikatorach RP

Identyfikator strony ufającej (RP ID) to unikalny ciąg znaków, który identyfikuje Twoją usługę lub witrynę. Identyfikator grupy objętej ograniczeniami musi być ciągiem znaków domeny. Może to być dokładna bieżąca nazwa hosta lub szersza domena nadrzędna, pod warunkiem że jest to eTLD+1 lub wyższa. Nie możesz używać adresów IP ani sufiksów publicznych (eTLD) jako identyfikatora RP.

Jeśli na przykład Twój serwer jest hostowany pod adresem https://www.example.com, możesz użyć jako identyfikatora RP adresu example.com lub www.example.com, w zależności od konkretnych potrzeb. W tabeli poniżej znajdziesz przykłady dozwolonych identyfikatorów RP w zależności od hosta źródłowego:

Host punktu początkowego Dozwolony identyfikator strony objętej ograniczeniami (eTLD+1)
https://login.example.com example.com lub login.example.com
https://example.com:8080 example.com (numery portów są wykluczone)
https://mobile.example.co.jp example.co.jp lub mobile.example.co.jp
https://sub.project.org.uk project.org.uk lub sub.project.org.uk
https://user.github.io user.github.io (github.io to eTLD)
https://myapp.pages.dev myapp.pages.dev (pages.dev to eTLD)
http://localhost localhost (wyjątek od wymagania dotyczącego protokołu HTTPS)

Podczas tworzenia kluczy dostępu przeglądarka kryptograficznie wiąże je z identyfikatorem RP. Aby użyć danych logowania, źródło żądania uwierzytelniania musi być zgodne z identyfikatorem RP.

Jeśli jako identyfikator RP użyjesz domeny eTLD+1, klucz dostępu będzie działać w powiązanych subdomenach. Na przykład identyfikator RP example.com działa w przypadku https://login.example.com i https://shop.example.com. Bardziej szczegółowy identyfikator RP, np. login.example.com, działa w przypadku dokładnego źródła, ale nie w przypadku https://shop.example.com.

Identyfikator RP w kontekstach między witrynami

Jeśli Twoja usługa obejmuje wiele domen eTLD+1 (np. example.com i example.co.jp), jest to konfiguracja obejmująca wiele witryn. Standardowe identyfikatory RP nie obsługują konfiguracji obejmujących wiele witryn.

Aby udostępniać klucze dostępu między różnymi witrynami, użyj powiązanych żądań dotyczących źródła. ROR umożliwia udostępnianie kluczy dostępu między różnymi witrynami, ponieważ klient (przeglądarka) rozpoznaje różne źródła jako część tej samej usługi logicznej.

Wymagania dotyczące ROR:

  • Wybierz 1 identyfikator RP: musisz wybrać 1 identyfikator RP i używać go we wszystkich witrynach.
  • Hostuj plik konfiguracji: domena głównego identyfikatora RP musi hostować plik konfiguracji w lokalizacji /.well-known/webauthn, który zawiera listę autoryzowanych źródeł.
  • Zachowaj spójność: nawet jeśli użytkownik korzysta z https://www.example.co.jp, w wywołaniu WebAuthn musi być używany główny klucz rpId (np. example.com) zarówno podczas tworzenia, jak i uwierzytelniania.

Przykładowy ROR dla identyfikatora RP example.com: https://example.com/.well-known/webauthn

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

Więcej informacji o szczegółach wdrożenia żądań dotyczących powiązanych domen znajdziesz w artykule Umożliwianie ponownego używania kluczy dostępu w witrynach za pomocą żądań dotyczących powiązanych domen.

Identyfikator strony objętej ograniczeniami w aplikacjach mobilnych

Aplikacje mobilne mogą używać kluczy dostępu, łącząc je z domeną internetową. Aby nawiązać tę relację, musisz umieścić plik weryfikacyjny na swoim serwerze.

Androidowy Credential Manager wymaga pliku Digital Asset Link (DAL) w domenie identyfikatora RP, aby powiązać go z aplikacją.

  • Hosting: hostuj plik na stronie https://<RP ID>/.well-known/assetlinks.json.
  • Weryfikacja: sprawdź origin w clientDataJSON. W przypadku Androida jest to ciąg znaków, np. android:apk-key-hash:<hash>.

Przykładowy DAL dla identyfikatora RP example.com (hostowany na stronie 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"
      ]
    }
  }
]

Więcej informacji znajdziesz w artykule Konfigurowanie połączeń Digital Asset Links między aplikacją a stroną internetową.

iOS: powiązane domeny

Platformy Apple wymagają pliku apple-app-site-association (AASA) w domenie identyfikatora RP, aby powiązać go z aplikacją.

  • Plik AASA: Host https://<RP_ID>/.well-known/apple-app-site-association
  • Uprawnienia: dodaj webcredentials:<app info> do uprawnień aplikacji.

Przykładowy plik AASA dla identyfikatora strony objętej ograniczeniami example.com:https://example.com/.well-known/apple-app-site-association

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

Więcej informacji znajdziesz w dokumentacji Apple dla deweloperów.

Podsumowanie

Identyfikator RP określa, gdzie użytkownicy uzyskują dostęp do swoich kluczy dostępu. Podczas wdrażania pamiętaj o tych kwestiach:

  • Hierarchia i subdomeny: identyfikator RP musi być ciągiem znaków domeny (eTLD+1 lub wyższy). Użycie szerszej domeny, np. example.com, umożliwia działanie kluczy dostępu we wszystkich subdomenach (np. login.example.com i shop.example.com).
  • Rozwiązania obejmujące wiele witryn: w przypadku usług obejmujących wiele domen eTLD+1 używaj żądań dotyczących powiązanych domen (ROR). Wymaga to 1 identyfikatora RP i pliku konfiguracji w /.well-known/webauthn.
  • Integracja z urządzeniami mobilnymi: nawiąż zweryfikowaną relację między witryną a aplikacjami mobilnymi, używając pliku Digital Asset Links (DAL) w lokalizacji /.well-known/assetlinks.json w przypadku Androida i pliku apple-app-site-association (AASA) w lokalizacji /.well-known/apple-app-site-association w przypadku iOS.

Więcej informacji