Sprawdzanie funkcji wykrywania funkcji interfejsu Credential Management API

Eiji Kitamura

Podsumowanie

WebAuthn pomaga zwiększyć bezpieczeństwo, wprowadzając w internecie uwierzytelnianie oparte na kluczu publicznym. Wkrótce będzie obsługiwane w Chrome, Firefoksie i Edge (ze zaktualizowaną specyfikacją). Dodaje nowy rodzaj obiektu Credential, który może jednak uszkodzić witryny korzystające z interfejsu Credential Management API bez wykrywania przez nie określonych typów danych logowania.

Jeśli robisz to obecnie w celu 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.

Aby dowiedzieć się więcej, czytaj dalej.

Uwaga: jeśli używasz tożsamości Google jako głównego sposobu logowania się użytkowników, rozważ użycie biblioteki JavaScript Zarejestruj się jednym kliknięciem i logowanie automatyczne opartej na interfejsie Credential Management API. Łączy logowanie z Google i logowanie z hasłem w jednym wywołaniu interfejsu API oraz dodaje obsługę tworzenia konta jednym kliknięciem.

Czym jest interfejs Credential Management API

Interfejs Credential Management API (CM API) zapewnia witrynom dostęp programowy do magazynu danych logowania użytkownika w celu przechowywania i pobierania 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 CM API definiuje 2 typy danych logowania:

• PasswordCredential
• FederatedCredential

PasswordCredential to dane logowania zawierające 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 zestawom danych logowania witryny mogą:

• zezwalanie użytkownikowi na logowanie się za pomocą wcześniej zapisanych danych logowania (hasła lub poświadczeń federacyjnych) od razu po zalogowaniu (automatyczne logowanie);
• przechowywać danych logowania opartych na hasłach lub danych logowania federacyjnych, których użył użytkownik,
• Aktualizowanie danych logowania użytkownika (np. po zmianie hasła)

Co to jest WebAuthn

WebAuthn (autoryzacja internetowa) dodaje do interfejsu CM API klucz publiczny. Na przykład daje witrynom możliwość korzystania ze standardowego sposobu implementowania uwierzytelniania dwuskładnikowego 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?

Wcześniej zalecaliśmy deweloperom, aby używali funkcji wykrywania interfejsu 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ć PublicKeyCredential dodany 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 [e-mail].