Sprawdzanie wykrywania funkcji interfejsu Credential Management API

Eiji Kitamura

Podsumowanie

WebAuthn pomaga zwiększyć bezpieczeństwo, wprowadzając do sieci uwierzytelnianie oparte na danych logowania z kluczem publicznym. Wkrótce będzie obsługiwany w Chrome, Firefoksie i Edge (ze zaktualizowaną specyfikacją). Dodaje nowy rodzaj obiektu Credential, który może jednak powodować błędy na stronach korzystających z interfejsu Credential Management API bez wykrywania funkcji określonych typów danych logowania, których używają.

Jeśli obecnie robisz to w celu wykrywania funkcji,

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
    // use CM API
}

Zamiast tego wykonaj te czynności

if (window.PasswordCredential || window.FederatedCredential) {
    // Call navigator.credentials.get() to retrieve stored
    // PasswordCredentials or FederatedCredentials.
}

if (window.PasswordCredential) {
    // Get/Store PasswordCredential
}

if (window.FederatedCredential) {
    // Get/Store FederatedCredential
}

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
    // Call navigator.credentials.preventSilentAccess()
}

Zobacz przykładowe zmiany wprowadzone w przykładowym kodzie.

Czytaj dalej, aby dowiedzieć się więcej.

Czym jest interfejs Credential Management API

Interfejs Credential Management API (CM API) zapewnia witrynom zautomatyzowany dostęp do magazynu danych logowania klienta użytkownika, co umożliwia przechowywanie i pobieranie danych logowania użytkownika dla wywołującego źródła.

Podstawowe interfejsy API:

  • navigator.credentials.get()
  • navigator.credentials.store()
  • navigator.credentials.create()
  • navigator.credentials.preventSilentAccess()

Pierwotna specyfikacja interfejsu API do implementacji systemu zarządzania treścią definiuje 2 typy danych logowania:

  • PasswordCredential
  • FederatedCredential

PasswordCredential to dane logowania, które zawierają identyfikator i hasło użytkownika. FederatedCredential to dane logowania, które zawierają identyfikator użytkownika i ciąg znaków reprezentujący dostawcę tożsamości.

Dzięki tym 2 rodzajom danych logowania witryny mogą:

  • umożliwienie użytkownikowi zalogowania się przy użyciu wcześniej zapisanych danych logowania opartych na haśle lub danych sfederowanych, gdy tylko wejdzie na stronę (automatyczne logowanie);
  • przechowywać dane logowania oparte na haśle lub dane logowania sfederowanego, których użytkownik użył do zalogowania się;
  • aktualizować dane logowania użytkownika (np. po zmianie hasła);

Czym jest WebAuthn

WebAuthn (Web Authentication) dodaje do interfejsu API do implementacji systemu zarządzania treścią dane logowania z kluczem publicznym. Dzięki temu witryny mogą na przykład w ujednolicony sposób wdrażać uwierzytelnianie dwuskładnikowe przy użyciu urządzeń uwierzytelniających zgodnych ze standardem FIDO 2.0.

Na poziomie technicznym WebAuthn rozszerza interfejs API do implementacji systemu zarządzania treścią o interfejs PublicKeyCredential.

Na czym polega problem?

Wcześniej zalecaliśmy deweloperom wykrywanie funkcji interfejsu API do implementacji systemu zarządzania treścią za pomocą tego kodu:

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
  // Use CM API
}

But as you can see from the descriptions above, the `navigator.credentials` is
now expanded to support public-key credentials in addition to password
credentials and federated credentials.

The problem is that user agents don't necessarily support all kinds of
credentials. If you continue feature detect using `navigator.credentials`, your
website may break when you are using a certain credential type not supported by
the browser.

**Supported credential types by browser<s**
table class="properties with-head><ing-t><in>t<&q><uot>;<tb>odytr
th/th
thPasswordCredential / Feder<ate>d<Cr>edential/th
thPubli<cKe>y<Cre><de><nt>ial/th
</tr><tr>thChrome
/<tht><dA>vailable
/tdtdI<n d><eve><lo><pm>ent
/td/<trt><rt>hFir<efo><x<>/span>
/thtdN/A
/tdtdAiming <to ><shi><p ><on> 60
/<td/><tr>trth<Edg><e<>/span>
/thtdN/A
/tdtdImp<lemented with a href="https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello->in-micros<of>t-edge/"older API/a. New API (navigator.cr<ede><nti><als) c><oming >soon.
/td/tr/tbody/table


## The solution
You can avoid this by modifying feature detection code as follows to explicitly
test for the credential type that you intend to use.

```js
if (window.PasswordCredential || window.FederatedCredential) {
    // Call navigator.credentials.get() to retrieve stored
    // PasswordCredentials or FederatedCredentials.
}

if (window.PasswordCredential) {
    // Get/Store PasswordCredential
}

if (window.FederatedCredential) {
    // Get/Store FederatedCredential
}

if&& (navigator.credentials  navigator.credentials.preventSilentAccess) {
    // Call navigator.credentials.preventSilentAccess()
}

Zobacz rzeczywiste zmiany wprowadzone w przykładowym kodzie.

Dla porównania, oto jak wykryć dodanie PublicKeyCredential w WebAuthn:

if (window.PublicKeyCredential) {
    // use CM API with PublicKeyCredential added in the WebAuthn spec
}

Oś czasu

Najwcześniejsza dostępna implementacja WebAuthn to Firefox, która ma być stabilna na początku maja 2018 r.

Na koniec

Jeśli masz pytania, wyślij je na adres @agektmr lub agektmr@chromium.org.