Sprawdzanie funkcji wykrywania funkcji interfejsu Credential Management API

Eiji Kitamura

Podsumowanie

Uwierzytelnianie WebAuthn zwiększa bezpieczeństwo przez udostępnianie w internecie uwierzytelniania za pomocą klucza publicznego. Wkrótce będzie obsługiwane w Chrome, Firefoksie i Edge (ze zaktualizowaną specyfikacją). Dodaje nowy rodzaj obiektu Credential, który może jednak zakłócać działanie witryn korzystających z interfejsu Credential Management API bez wykrywania określonych typów danych logowania, z których korzystają.

Jeśli obecnie robisz to na potrzeby wykrywania funkcji

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

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 zmiany wprowadzone w przykładowym kodzie.

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

Uwaga: jeśli korzystasz z tożsamości Google jako głównego sposobu logowania się użytkowników, rozważ skorzystanie z biblioteki JavaScriptu rejestracji jednym dotknięciem i automatycznego logowania wbudowanej w interfejs Credential Management API. Łączy logowanie w Google i logowanie na podstawie hasła w jedno wywołanie interfejsu API, a także umożliwia tworzenie konta jednym dotknięciem.

Co to jest interfejs Credential Management API

Interfejs Credential Management API (interfejs API CM) zapewnia witrynom programowy dostęp do magazynu danych logowania klienta użytkownika w celu przechowywania lub pobierania danych logowania użytkownika w źródle wywołującym.

Podstawowe interfejsy API to:

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

Pierwotna specyfikacja interfejsu API CM definiuje 2 typy danych logowania:

• PasswordCredential
• FederatedCredential

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

Te 2 zestawy danych logowania umożliwiają witrynom:

• Pozwól użytkownikowi na logowanie się przy użyciu zapisanych wcześniej danych uwierzytelniających opartych na haśle lub sfederowanych, gdy tylko się włączy (logowanie automatyczne).
• przechowywać dane uwierzytelniające oparte na haśle lub sfederowane, za pomocą których użytkownik zalogował się;
• Pilnuj, by dane logowania użytkownika były aktualne (np.po zmianie hasła).

Co to jest WebAuthn

WebAuthn (Uwierzytelnianie internetowe) dodaje dane logowania klucza publicznego do interfejsu CM API. Zapewnia on na przykład ustandaryzowany sposób wdrażania uwierzytelniania dwuskładnikowego w witrynach przy użyciu urządzeń uwierzytelniających zgodnych ze standardem FIDO 2.0.

Na poziomie technicznym WebAuthn rozszerza interfejs CM API o interfejs PublicKeyCredential.

Na czym polega problem?

Poprzednio podpowiadaliśmy deweloperom, jak wykryć interfejs CM API 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 browsers**
<table class="properties with-heading-tint"><tbody><tr>
<th></th>
<th>PasswordCredential / FederatedCredential</th>
<th>PublicKeyCredential</th>
</tr><tr><th>Chrome
</th><td>Available
</td><td>In development
</td></tr><tr><th>Firefox
</th><td>N/A
</td><td>Aiming to ship on 60
</td></tr><tr><th>Edge
</th><td>N/A
</td><td>Implemented with <a href="https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello-in-microsoft-edge/">older API</a>. New API (navigator.credentials) coming 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.

Oto jak wykryć adres PublicKeyCredential dodany w WebAuthn:

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

Oś czasu

Najwcześniejszą dostępną implementacją WebAuthn jest przeglądarka Firefox. Planujemy wprowadzić ją na początku maja 2018 r. w wersji stabilnej.

Na koniec

Jeśli masz pytania, prześlij je na adres @agektmr lub [e-mail].