Orientacja kluczy dostępu

Funkcje internetowe: Uwierzytelnianie internetowe

Ten przewodnik zawiera szczegółowe, praktyczne wskazówki dotyczące wdrażania bezpiecznego, niezależnego od platformy uwierzytelniania za pomocą klucza dostępu i zarządzania danymi logowania w nowoczesnych aplikacjach internetowych.

1. Podstawowe wymagania dotyczące kluczy dostępu

Klucze dostępu korzystają z interfejsu Web Authentication API (WebAuthn), który nakłada rygorystyczne, przekrojowe ograniczenia bezpieczeństwa, które muszą zostać spełnione przed każdą próbą wdrożenia:

  • Bezpieczne konteksty: metody WebAuthn (navigator.credentials.create i navigator.credentials.get) są ściśle ograniczone do bezpiecznych kontekstów. Aplikacje MUSZĄ działać na platformie https:// w środowisku produkcyjnym lub http://localhost w środowisku programistycznym.
  • Identyfikator strony zależnej (RP ID): każde dane logowania są powiązane z identyfikatorem RP ID (zasadniczo jest to nazwa domeny aplikacji). Identyfikator RP przekazany w opcjach po stronie serwera MUSI być zgodny z nazwą domeny bieżącego źródła lub być jej prawidłowym sufiksem (np. example.com jest prawidłowy dla login.example.com). Niezgodności powodują wyjątki SecurityError po stronie klienta.

2. Ostrzeżenie dotyczące UX związane z AAGUID

Globalnie unikalny identyfikator atestu uwierzytelniającego (AAGUID) to 128-bitowy identyfikator zwracany w danych atestu rejestracji, który reprezentuje model/dostawcę uwierzytelniacza (np. Menedżer haseł Google, pęk kluczy w iCloud, 1Password).

  • Tylko podpowiedzi dotyczące UX: strony uzyskujące dostęp MUSZĄ używać identyfikatora AAGUID wyłącznie do podpowiedzi dotyczących UX (np. renderowania nazwy i ikony dostawcy klucza dostępu na liście zarządzania, aby pomóc użytkownikowi).
  • Brak zależności związanych z bezpieczeństwem: aplikacje NIE MOGĄ używać identyfikatora AAGUID do podejmowania decyzji dotyczących zabezpieczeń kryptograficznych ani dostępu. Klucze dostępu platformy nie zapewniają obecnie kryptograficznego atestu dla identyfikatorów AAGUID, co oznacza, że mogą być one zmieniane lub symulowane przez klientów użytkownika.

3. Rekomendacje dotyczące bibliotek odłączonych

W przypadku generowania opcji FIDO2/WebAuthn i weryfikacji podpisu po stronie backendu deweloperzy MUSZĄ korzystać ze sprawdzonych bibliotek open source dla danego języka, a nie z ręcznie tworzonej kryptografii:

  • JavaScript/TypeScript: SimpleWebAuthn (github.com/MasterKale/SimpleWebAuthn)
  • Python: py_webauthn (github.com/duo-labs/py_webauthn)
  • Java: Java WebAuthn Server (github.com/Yubico/java-webauthn-server), WebAuthn4J (github.com/webauthn4j/webauthn4j)
  • .NET: biblioteka .NET dla FIDO2 (github.com/abergs/fido2-net-lib)
  • Go: biblioteka WebAuthn Go (github.com/go-webauthn/webauthn)
  • Ruby: WebAuthn Ruby (github.com/cedarcode/webauthn-ruby)
  • PHP WebAuthn Framework (github.com/web-auth/webauthn-framework)

4. Tabela referencyjna przypadków użycia

Znajdź poniżej odpowiedni przypadek użycia i pobierz pełny przewodnik po implementacji. Każdy przypadek użycia ma kluczowe interfejsy API (PublicKeyCredential.parseCreationOptionsFromJSON, parseRequestOptionsFromJSON, signalAllAcceptedCredentials, signalCurrentUserDetails, signalUnknownCredential, zapośredniczenie warunkowe, obsługa AAGUID itp.), które są udokumentowane tylko w przewodniku dotyczącym danego przypadku użycia. NIE pomijaj tego kroku pobierania i NIE zastępuj kodu klienta kodem bibliotek innych firm (takich jak startAuthentication/startRegistration SimpleWebAuthn) – wywołuj bezpośrednio interfejsy API natywnej przeglądarki WebAuthn. Zalecenia dotyczące bibliotek w sekcji 3 dotyczą tylko po stronie serwera (weryfikacja FIDO2 po stronie backendu).

Szczegółowe informacje o implementacji kluczy dostępu i WebAuthn znajdziesz w tych przewodnikach: