Ta strona została przetłumaczona przez Cloud Translation API.

Logowanie użytkownika za pomocą Menedżera danych logowania

Menedżer danych logowania to interfejs Jetpack API, który obsługuje wiele metod logowania, takich jak nazwa użytkownika i hasło, klucze dostępu oraz rozwiązania do logowania federacyjnego (np. Zaloguj się przez Google) w ramach jednego interfejsu API, co upraszcza integrację dla programistów.

Dla użytkowników Credential Manager ujednolica interfejs logowania niezależnie od metody uwierzytelniania, dzięki czemu logowanie się w aplikacjach przy użyciu każdej z tych metod jest bardziej przejrzyste.

Na tej stronie wyjaśniamy, czym są klucze dostępu, i opisujemy, jak wdrożyć obsługę po stronie klienta w przypadku rozwiązań do uwierzytelniania, w tym kluczy dostępu, za pomocą interfejsu Credential Manager API. Jest też osobna strona z najczęstszymi pytaniami, na której znajdziesz odpowiedzi na bardziej szczegółowe pytania.

Informacje o kluczach dostępu

Klucze dostępu to bezpieczniejsza i łatwiejsza w obsłudze alternatywa dla haseł. Dzięki kluczom dostępu użytkownicy mogą logować się w aplikacjach i na stronach internetowych za pomocą czujnika biometrycznego (np. czytnika odcisków palców lub rozpoznawania twarzy), kodu PIN lub wzoru. Zapewnia to płynne logowanie, dzięki czemu użytkownicy nie muszą pamiętać nazw użytkownika ani haseł.

Klucze dostępu korzystają z WebAuthn (Web Authentication), standardu opracowanego wspólnie przez FIDO Alliance i World Wide Web Consortium (W3C). WebAuthn używa kryptografii klucza publicznego do uwierzytelniania użytkownika. Witryna lub aplikacja, w której użytkownik się loguje, może zobaczyć i zapisać klucz publiczny, ale nigdy klucza prywatnego. Klucz prywatny jest utrzymywany w tajemnicy i bezpieczny. Klucz jest unikalny i powiązany ze stroną lub aplikacją, więc klucze dostępu są odporne na phishing, co zwiększa bezpieczeństwo.

Menedżer danych logowania umożliwia użytkownikom tworzenie kluczy dostępu i przechowywanie ich w Menedżerze haseł Google.

Więcej informacji o wdrażaniu płynnych przepływów uwierzytelniania za pomocą kluczy dostępu w Menedżerze danych logowania znajdziesz w artykule Uwierzytelnianie użytkowników za pomocą kluczy dostępu.

Wymagania wstępne

Aby używać Menedżera danych logowania, wykonaj czynności opisane w tej sekcji.

Używanie najnowszej wersji platformy

Menedżer danych logowania jest obsługiwany na Androidzie 4.4 (poziom interfejsu API 19) i nowszych wersjach.

Dodawanie zależności do aplikacji

Dodaj te zależności do skryptu kompilacji modułu aplikacji:

implementation(libs.androidx.credentials)

// optional - needed for credentials support from play services, for devices running
// Android 13 and below.
implementation(libs.androidx.credentials.play.services.auth)build.gradle.kts

, gdy są uruchamiane na Androidzie 14.

Dowiedz się więcej o zmniejszaniu, zaciemnianiu i optymalizowaniu aplikacji.

Dodanie obsługi Digital Asset Links

Aby włączyć obsługę kluczy dostępu w aplikacji na Androida, powiąż ją z witryną, której jesteś właścicielem. Aby zadeklarować to powiązanie, wykonaj te czynności:

Utwórz plik JSON protokołu Digital Asset Links. Aby na przykład zadeklarować, że witryna https://signin.example.com i aplikacja na Androida o nazwie pakietu com.example mogą udostępniać dane logowania, utwórz plik o nazwie assetlinks.json z tą treścią:

[
  {
    "relation" : [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target" : {
      "namespace" : "android_app",
      "package_name" : "com.example.android",
      "sha256_cert_fingerprints" : [
        SHA_HEX_VALUE
      ]
    }
  }
]assetlinks.json

Pole relation to tablica zawierająca co najmniej 1 ciąg znaków opisujący deklarowaną relację. Aby zadeklarować, że aplikacje i witryny współdzielą dane logowania, określ relacje jako delegate_permission/handle_all_urls i delegate_permission/common.get_login_creds.

Pole target to obiekt, który określa komponent, do którego odnosi się deklaracja. Te pola identyfikują witrynę:

namespace web

site

Adres URL witryny w formacie https://domain[:optional_port], np. https://www.example.com.

domain musi być w pełni kwalifikowany, a optional_port należy pominąć, gdy w przypadku protokołu HTTPS używany jest port 443.

site może być tylko domeną główną: nie możesz ograniczyć powiązania aplikacji do określonego podkatalogu. Nie uwzględniaj ścieżki w adresie URL, np. ukośnika na końcu.

Subdomeny nie są uznawane za dopasowane, co oznacza, że jeśli określisz domain jako www.example.com, domena www.counter.example.com nie będzie powiązana z Twoją aplikacją.

Te pola identyfikują aplikację na Androida:

`namespace`	`android_app`
`package_name`	Nazwa pakietu zadeklarowana w manifeście aplikacji. Na przykład:`com.example.android`
`sha256_cert_fingerprints`	Odciski cyfrowe SHA256 certyfikatu podpisywania aplikacji.

Umieść plik JSON protokołu Digital Asset Links w tej lokalizacji w domenie logowania:
```
https://domain[:optional_port]/.well-known/assetlinks.json
```
Jeśli na przykład Twoja domena logowania to signin.example.com, umieść plik JSON pod adresem https://signin.example.com/.well-known/assetlinks.json.

Typ MIME pliku Digital Assets Link musi być JSON. Sprawdź, czy serwer wysyła w odpowiedzi nagłówek Content-Type: application/json.
Sprawdź, czy Twój host zezwala Google na pobranie pliku Digital Asset Link. Jeśli masz plik robots.txt, musi on zezwalać agentowi Googlebot na pobieranie /.well-known/assetlinks.json. Większość witryn może zezwolić dowolnemu agentowi automatycznemu na pobieranie plików ze ścieżki /.well-known/, aby inne usługi mogły uzyskać dostęp do metadanych w tych plikach:
```
User-agent: *
Allow: /.well-known/
```

Dodaj do pliku manifestu ten wiersz w sekcji <application>:

<meta-data android:name="asset_statements" android:resource="@string/asset_statements" />

Jeśli używasz logowania za pomocą hasła w Menedżerze danych logowania, wykonaj ten krok, aby skonfigurować łączenie zasobów cyfrowych w pliku manifestu. Ten krok nie jest wymagany, jeśli używasz tylko kluczy dostępu.

Zadeklaruj powiązanie w aplikacji na Androida. Dodaj obiekt, który określa assetlinks.jsonpliki do wczytania. W ciągu znaków musisz zmienić znaczenie wszystkich apostrofów i cudzysłowów. Na przykład:
```
<string name="asset_statements" translatable="false">
[{
  \"include\": \"https://signin.example.com/.well-known/assetlinks.json\"
}]
</string>
```
Uwaga: link https://signin.example.com/.well-known/assetlinks.json musi zwracać odpowiedź HTTP 200 z nagłówkiem Content-Type MIME JSON. Zwrócenie przekierowania HTTP 301 lub 302 albo typu treści innego niż JSON spowoduje niepowodzenie weryfikacji. Poniżej znajdziesz przykład żądania i powiązanych z nim nagłówków odpowiedzi.
```
> GET /.well-known/assetlinks.json HTTP/1.1
> User-Agent: curl/7.35.0
> Host: signin.example.com

< HTTP/1.1 200 OK
< Content-Type: application/json
```

Konfigurowanie Menedżera danych logowania

Aby skonfigurować i zainicjować obiekt CredentialManager, dodaj logikę podobną do tej:

// Use your app or activity context to instantiate a client instance of
// CredentialManager.
private val credentialManager = CredentialManager.create(context)PasskeyAndPasswordFunctions.kt

Wskaż pola danych logowania

Na Androidzie 14 i nowszych atrybut isCredential może służyć do wskazywania pól danych logowania, takich jak pola nazwy użytkownika lub hasła. Ten atrybut wskazuje, że ten widok jest polem danych logowania, które ma współpracować z Menedżerem danych logowania i zewnętrznymi dostawcami danych logowania, a także pomagać usługom autouzupełniania w wyświetlaniu lepszych sugestii autouzupełniania. Gdy aplikacja korzysta z interfejsu Credential Manager API, wyświetla się arkusz Credential Manager z dostępnymi danymi logowania. Nie ma potrzeby wyświetlania okna autouzupełniania w przypadku nazwy użytkownika lub hasła. Podobnie nie trzeba wyświetlać okna dialogowego zapisu autouzupełniania w przypadku haseł, ponieważ aplikacja poprosi interfejs Credential Manager API o zapisanie danych logowania.

Aby używać atrybutu isCredential, dodaj go do odpowiednich widoków:

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:isCredential="true" />xmlsnippets.xml

Aby pobrać wszystkie klucze dostępu i hasła powiązane z kontem użytkownika, wykonaj te czynności:

Zainicjuj opcje uwierzytelniania za pomocą hasła i klucza dostępu:

// Retrieves the user's saved password for your app from their
// password provider.
val getPasswordOption = GetPasswordOption()

// Get passkey from the user's public key credential provider.
val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
  requestJson = requestJson
)PasskeyAndPasswordFunctions.kt

Użyj opcji pobranych w poprzednim kroku, aby utworzyć żądanie logowania.

Uwaga: aplikacje nie powinny ustawiać pola origin z wyjątkiem przeglądarek i podobnych aplikacji z uprawnieniami. Więcej informacji
```
val credentialRequest = GetCredentialRequest(
  listOf(getPasswordOption, getPublicKeyCredentialOption),
)PasskeyAndPasswordFunctions.kt
      
```

Uruchom procedurę logowania:

coroutineScope {
  try {
    result = credentialManager.getCredential(
      // Use an activity-based context to avoid undefined system UI
      // launching behavior.
      context = activityContext,
      request = credentialRequest
    )
    handleSignIn(result)
  } catch (e: GetCredentialException) {
    // Handle failure
  }
}PasskeyAndPasswordFunctions.kt

fun handleSignIn(result: GetCredentialResponse) {
  // Handle the successfully returned credential.
  val credential = result.credential

  when (credential) {
    is PublicKeyCredential -> {
      val responseJson = credential.authenticationResponseJson
      // Share responseJson i.e. a GetCredentialResponse on your server to
      // validate and  authenticate
    }

    is PasswordCredential -> {
      val username = credential.id
      val password = credential.password
      // Use id and password to send to your server to validate
      // and authenticate
    }

    is CustomCredential -> {
      // If you are also using any external sign-in libraries, parse them
      // here with the utility functions provided.
      if (credential.type == ExampleCustomCredential.TYPE) {
        try {
          val ExampleCustomCredential =
            ExampleCustomCredential.createFrom(credential.data)
          // Extract the required credentials and complete the authentication as per
          // the federated sign in or any external sign in library flow
        } catch (e: ExampleCustomCredential.ExampleCustomCredentialParsingException) {
          // Unlikely to happen. If it does, you likely need to update the dependency
          // version of your external sign-in library.
          Log.e(TAG, "Failed to parse an ExampleCustomCredential", e)
        }
      } else {
        // Catch any unrecognized custom credential type here.
        Log.e(TAG, "Unexpected type of credential")
      }
    }
    else -> {
      // Catch any unrecognized credential type here.
      Log.e(TAG, "Unexpected type of credential")
    }
  }
}PasskeyAndPasswordFunctions.kt

Uwaga: jeśli wywołanie Menedżera danych logowania zostało zainicjowane przez wyraźną czynność użytkownika, ustaw wartość preferImmediatelyAvailableCredentials na false. Jeśli menedżer danych logowania został wywołany oportunistycznie, ustaw wartość preferImmediatelyAvailableCredentials na true.

Opcja preferImmediatelyAvailableCredentials określa, czy wolisz używać do realizacji żądania tylko dostępnych lokalnie danych logowania, zamiast danych logowania z kluczy bezpieczeństwa lub przepływów kluczy hybrydowych. Domyślnie ta wartość wynosi false.

Jeśli ustawisz wartość preferImmediatelyAvailableCredentials na true i nie ma dostępnych od razu danych logowania, Menedżer danych logowania nie wyświetli żadnego interfejsu, a żądanie natychmiast się nie powiedzie. W przypadku żądań pobierania zwróci wartość NoCredentialException, a w przypadku żądań tworzenia – CreateCredentialNoCreateOptionException. Jest to zalecane w przypadku wywoływania interfejsu Credential Manager API w sposób oportunistyczny, np. przy pierwszym otwarciu aplikacji.

Poniższy przykład pokazuje, jak sformatować żądanie JSON po uzyskaniu klucza dostępu:

{
  "challenge": "T1xCsnxM2DNL2KdK5CLa6fMhD7OBqho6syzInk_n-Uo",
  "allowCredentials": [],
  "timeout": 1800000,
  "userVerification": "required",
  "rpId": "https://passkeys-codelab.glitch.me/"
}

Poniższy przykład pokazuje, jak może wyglądać odpowiedź JSON po uzyskaniu danych logowania klucza publicznego:

{
  "id": "KEDetxZcUfinhVi6Za5nZQ",
  "type": "public-key",
  "rawId": "KEDetxZcUfinhVi6Za5nZQ",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVDF4Q3NueE0yRE5MMktkSzVDTGE2Zk1oRDdPQnFobzZzeXpJbmtfbi1VbyIsIm9yaWdpbiI6ImFuZHJvaWQ6YXBrLWtleS1oYXNoOk1MTHpEdll4UTRFS1R3QzZVNlpWVnJGUXRIOEdjVi0xZDQ0NEZLOUh2YUkiLCJhbmRyb2lkUGFja2FnZU5hbWUiOiJjb20uZ29vZ2xlLmNyZWRlbnRpYWxtYW5hZ2VyLnNhbXBsZSJ9",
    "authenticatorData": "j5r_fLFhV-qdmGEwiukwD5E_5ama9g0hzXgN8thcFGQdAAAAAA",
    "signature": "MEUCIQCO1Cm4SA2xiG5FdKDHCJorueiS04wCsqHhiRDbbgITYAIgMKMFirgC2SSFmxrh7z9PzUqr0bK1HZ6Zn8vZVhETnyQ",
    "userHandle": "2HzoHm_hY0CjuEESY9tY6-3SdjmNHOoNqaPDcZGzsr0"
  }
}

Obsługa wyjątków, gdy nie ma dostępnych danych logowania

W niektórych przypadkach użytkownik może nie mieć dostępnych danych logowania lub może nie wyrazić zgody na użycie dostępnych danych logowania. Jeśli wywoływana jest funkcja getCredential(), a nie znaleziono danych logowania, zwracana jest funkcja NoCredentialException. W takim przypadku kod powinien obsługiwać wystąpienia NoCredentialException.

coroutineScope {
  try {
    result = credentialManager.getCredential(
      context = activityContext,
      request = credentialRequest
    )
  } catch (e: GetCredentialException) {
    Log.e("CredentialManager", "No credential available", e)
  }
}PasskeyAndPasswordFunctions.kt

Na Androidzie 14 lub nowszym możesz skrócić czas oczekiwania podczas wyświetlania selektora konta, używając metody prepareGetCredential() przed wywołaniem getCredential().

coroutineScope {
  val response = credentialManager.prepareGetCredential(
    GetCredentialRequest(
      listOf(
        getPublicKeyCredentialOption,
        getPasswordOption
      )
    )
  )
}PasskeyAndPasswordFunctions.kt

Metoda prepareGetCredential() nie wywołuje elementów interfejsu. Pomaga tylko w przygotowaniu, aby później można było uruchomić pozostałą operację pobierania danych logowania (która obejmuje interfejsy) za pomocą interfejsu getCredential() API.

Dane z pamięci podręcznej są zwracane w obiekcie PrepareGetCredentialResponse. Jeśli istnieją dane logowania, wyniki zostaną zapisane w pamięci podręcznej. Później możesz uruchomić pozostałe interfejsy API getCredential(), aby wyświetlić selektor konta z danymi z pamięci podręcznej.

Procesy rejestracji

Użytkownika możesz zarejestrować do uwierzytelniania za pomocą klucza dostępu lub hasła.

Utwórz klucz dostępu

Aby umożliwić użytkownikom zarejestrowanie klucza dostępu i używanie go do ponownego uwierzytelniania, zarejestruj dane logowania użytkownika za pomocą obiektu CreatePublicKeyCredentialRequest.

suspend fun createPasskey(requestJson: String, preferImmediatelyAvailableCredentials: Boolean) {
  val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
    // Contains the request in JSON format. Uses the standard WebAuthn
    // web JSON spec.
    requestJson = requestJson,
    // Defines whether you prefer to use only immediately available
    // credentials, not hybrid credentials, to fulfill this request.
    // This value is false by default.
    preferImmediatelyAvailableCredentials = preferImmediatelyAvailableCredentials,
  )

  // Execute CreateCredentialRequest asynchronously to register credentials
  // for a user account. Handle success and failure cases with the result and
  // exceptions, respectively.
  coroutineScope {
    try {
      val result = credentialManager.createCredential(
        // Use an activity-based context to avoid undefined system
        // UI launching behavior
        context = activityContext,
        request = createPublicKeyCredentialRequest,
      )
      //  Handle passkey creation result
    } catch (e : CreateCredentialException){
      handleFailure(e)
    }
  }
}PasskeyAndPasswordFunctions.kt

fun handleFailure(e: CreateCredentialException) {
  when (e) {
    is CreatePublicKeyCredentialDomException -> {
      // Handle the passkey DOM errors thrown according to the
      // WebAuthn spec.
    }
    is CreateCredentialCancellationException -> {
      // The user intentionally canceled the operation and chose not
      // to register the credential.
    }
    is CreateCredentialInterruptedException -> {
      // Retry-able error. Consider retrying the call.
    }
    is CreateCredentialProviderConfigurationException -> {
      // Your app is missing the provider configuration dependency.
      // Most likely, you're missing the
      // "credentials-play-services-auth" module.
    }
    is CreateCredentialCustomException -> {
      // You have encountered an error from a 3rd-party SDK. If you
      // make the API call with a request object that's a subclass of
      // CreateCustomCredentialRequest using a 3rd-party SDK, then you
      // should check for any custom exception type constants within
      // that SDK to match with e.type. Otherwise, drop or log the
      // exception.
    }
    else -> Log.w(TAG, "Unexpected exception type ${e::class.java.name}")
  }
}PasskeyAndPasswordFunctions.kt

Formatowanie żądania JSON

Po utworzeniu klucza dostępu musisz powiązać go z kontem użytkownika i zapisać klucz publiczny klucza dostępu na serwerze. Poniższy przykład kodu pokazuje, jak sformatować żądanie JSON podczas tworzenia klucza dostępu.

Ten post na blogu o wprowadzaniu bezproblemowego uwierzytelniania w aplikacjach pokazuje, jak sformatować żądanie JSON podczas tworzenia kluczy dostępu i uwierzytelniania za ich pomocą. Wyjaśniamy też, dlaczego hasła nie są skutecznym rozwiązaniem do uwierzytelniania, jak wykorzystywać istniejące dane biometryczne, jak powiązać aplikację z posiadaną witryną, jak tworzyć klucze dostępu i jak uwierzytelniać się za ich pomocą.

{
  "challenge": "abc123",
  "rp": {
    "name": "Credential Manager example",
    "id": "credential-manager-test.example.com"
  },
  "user": {
    "id": "def456",
    "name": "helloandroid@gmail.com",
    "displayName": "helloandroid@gmail.com"
  },
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    },
    {
      "type": "public-key",
      "alg": -257
    }
  ],
  "timeout": 1800000,
  "attestation": "none",
  "excludeCredentials": [
    {
      "id": "ghi789",
      "type": "public-key"
    },
    {
      "id": "jkl012",
      "type": "public-key"
    }
  ],
  "authenticatorSelection": {
    "authenticatorAttachment": "platform",
    "requireResidentKey": true,
    "residentKey": "required",
    "userVerification": "required"
  }
}

Ustawianie wartości parametru authenticatorAttachment

Parametr authenticatorAttachment można ustawić tylko podczas tworzenia danych logowania. Możesz podać wartość platform, cross-platform lub nie podawać żadnej wartości. W większości przypadków zalecana jest brak wartości.

platform: aby zarejestrować bieżące urządzenie użytkownika lub poprosić go o przejście na klucze dostępu po zalogowaniu się, ustaw wartość authenticatorAttachment na platform.
cross-platform: ta wartość jest zwykle używana podczas rejestrowania danych logowania z uwierzytelnianiem wieloskładnikowym i nie jest używana w kontekście klucza dostępu.
Brak wartości: aby zapewnić użytkownikom możliwość tworzenia kluczy dostępu na preferowanych urządzeniach (np. w ustawieniach konta), nie należy określać parametru authenticatorAttachment, gdy użytkownik zdecyduje się dodać klucz dostępu. W większości przypadków najlepszym rozwiązaniem jest pozostawienie parametru bez określenia.

Zapobieganie tworzeniu zduplikowanych kluczy dostępu

W opcjonalnej tablicy excludeCredentials podaj identyfikatory danych logowania, aby zapobiec utworzeniu nowego klucza dostępu, jeśli istnieje już klucz dostępu z tym samym dostawcą.

Obsługa odpowiedzi JSON

Ten fragment kodu pokazuje przykładową odpowiedź JSON dotyczącą tworzenia danych logowania klucza publicznego. Dowiedz się więcej o obsłudze zwróconych danych logowania z kluczem publicznym.

{
  "id": "KEDetxZcUfinhVi6Za5nZQ",
  "type": "public-key",
  "rawId": "KEDetxZcUfinhVi6Za5nZQ",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoibmhrUVhmRTU5SmI5N1Z5eU5Ka3ZEaVh1Y01Fdmx0ZHV2Y3JEbUdyT0RIWSIsIm9yaWdpbiI6ImFuZHJvaWQ6YXBrLWtleS1oYXNoOk1MTHpEdll4UTRFS1R3QzZVNlpWVnJGUXRIOEdjVi0xZDQ0NEZLOUh2YUkiLCJhbmRyb2lkUGFja2FnZU5hbWUiOiJjb20uZ29vZ2xlLmNyZWRlbnRpYWxtYW5hZ2VyLnNhbXBsZSJ9",
    "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViUj5r_fLFhV-qdmGEwiukwD5E_5ama9g0hzXgN8thcFGRdAAAAAAAAAAAAAAAAAAAAAAAAAAAAEChA3rcWXFH4p4VYumWuZ2WlAQIDJiABIVgg4RqZaJyaC24Pf4tT-8ONIZ5_Elddf3dNotGOx81jj3siWCAWXS6Lz70hvC2g8hwoLllOwlsbYatNkO2uYFO-eJID6A"
  }
}

Weryfikowanie pochodzenia na podstawie danych klienta w formacie JSON

Symbol origin reprezentuje aplikację lub witrynę, z której pochodzi żądanie. Jest on używany przez klucze dostępu do ochrony przed atakami phishingowymi. Serwer aplikacji musi sprawdzać pochodzenie danych klienta na podstawie listy dozwolonych aplikacji i witryn. Jeśli serwer otrzyma żądanie z aplikacji lub witryny z nierozpoznanego źródła, powinien je odrzucić.

W przypadku internetu wartość origin odzwierciedla źródło w tej samej witrynie, w której nastąpiło podpisanie danych logowania. Na przykład w przypadku adresu URL https://www.example.com:8443/store?category=shoes#athletic atrybut origin to https://www.example.com:8443.

W przypadku aplikacji na Androida agent użytkownika automatycznie ustawia wartość origin na podpis aplikacji wywołującej. Ten podpis powinien być zweryfikowany na Twoim serwerze, aby potwierdzić, że wywołująca aplikacja jest uprawniona do korzystania z interfejsu Passkey API. Identyfikator Android origin to identyfikator URI pochodzący z wartości hash SHA-256 certyfikatu podpisywania pliku APK, np.:

android:apk-key-hash:<sha256_hash-of-apk-signing-cert>

Skróty SHA-256 certyfikatów podpisywania z magazynu kluczy można znaleźć, uruchamiając to polecenie w terminalu:

keytool -list -keystore <path-to-apk-signing-keystore>

Identyfikatory SHA-256 są podawane w formacie szesnastkowym rozdzielonym dwukropkami91:F7:CB:F9:D6:81…, a wartości origin na Androidzie są zakodowane w formacie base64url. Ten przykład w języku Python pokazuje, jak przekonwertować format skrótu na zgodny format szesnastkowy rozdzielony dwukropkami:

import binascii
import base64
fingerprint = '91:F7:CB:F9:D6:81:53:1B:C7:A5:8F:B8:33:CC:A1:4D:AB:ED:E5:09:C5'
print("android:apk-key-hash:" + base64.urlsafe_b64encode(binascii.a2b_hex(fingerprint.replace(':', ''))).decode('utf8').replace('=', ''))

Zastąp wartość fingerprint własną wartością. Oto przykład wyniku:

android:apk-key-hash:kffL-daBUxvHpY-4M8yhTavt5QnFEI2LsexohxrGPYU

Następnie możesz dopasować ten ciąg znaków jako dozwoloną domenę w swoim serwerze. Jeśli masz kilka certyfikatów podpisywania, np. certyfikaty do debugowania i wersji, lub kilka aplikacji, powtórz ten proces i zaakceptuj wszystkie te źródła jako prawidłowe na serwerze.

Zapisywanie hasła użytkownika

Jeśli użytkownik poda nazwę użytkownika i hasło w przepływie uwierzytelniania w Twojej aplikacji, możesz zarejestrować dane logowania użytkownika, które mogą być używane do uwierzytelniania. Aby to zrobić, utwórz obiekt CreatePasswordRequest:

suspend fun registerPassword(username: String, password: String) {
  // Initialize a CreatePasswordRequest object.
  val createPasswordRequest =
    CreatePasswordRequest(id = username, password = password)

  // Create credential and handle result.
  coroutineScope {
    try {
      val result =
        credentialManager.createCredential(
          // Use an activity based context to avoid undefined
          // system UI launching behavior.
          activityContext,
          createPasswordRequest
        )
      // Handle register password result
    } catch (e: CreateCredentialException) {
      handleFailure(e)
    }
  }
}PasskeyAndPasswordFunctions.kt

Pomoc w odzyskiwaniu danych logowania

Jeśli użytkownik nie ma już dostępu do urządzenia, na którym przechowywał dane logowania, może je odzyskać z bezpiecznej kopii zapasowej online. Więcej informacji o tym, jak wspierać ten proces odzyskiwania danych logowania, znajdziesz w sekcji „Odzyskiwanie dostępu lub dodawanie nowych urządzeń” w tym poście na blogu: Bezpieczeństwo kluczy dostępu w menedżerze haseł Google.

Automatyczne tworzenie kluczy dostępu dla użytkowników

Jeśli użytkownik nie ma klucza dostępu, możesz automatycznie utworzyć go w jego imieniu przy następnym logowaniu się za pomocą hasła zapisanego w menedżerze haseł. Aby to zrobić, ustaw pole isConditionalCreateRequest podczas wysyłania prośby o publiczne dane logowania:

CreatePublicKeyCredentialRequest(
    // other parameters
    isConditionalCreateRequest: Boolean = true
)

Gdy użytkownik się zaloguje, klucz dostępu zostanie automatycznie utworzony i zapisany w wybranym przez niego menedżerze haseł. Jeśli użytkownik korzysta z Menedżera haseł Google, musi użyć (za pomocą Menedżera danych logowania lub autouzupełniania) hasła zapisanego w tym menedżerze. Po utworzeniu klucza dostępu użytkownik otrzyma powiadomienie i będzie mógł przejść do menedżera haseł, aby nim zarządzać.

Ta funkcja wymaga wersji 1.6.0-alpha01 lub nowszej.

Dodanie obsługi narzędzi do zarządzania hasłami za pomocą punktów końcowych kluczy dostępu w znanych adresach URL

Aby zapewnić bezproblemową integrację i przyszłą zgodność z narzędziami do zarządzania hasłami i danymi logowania, zalecamy dodanie obsługi dobrze znanych adresów URL punktów końcowych kluczy dostępu. Jest to otwarty protokół, który umożliwia podmiotom powiązanym formalne reklamowanie obsługi kluczy dostępu i udostępnianie bezpośrednich linków do rejestracji i zarządzania kluczami dostępu.

W przypadku podmiotu ufającego na stronie https://example.com, który ma stronę internetową oraz aplikacje na Androida i iOS, dobrze znany adres URL to https://example.com/.well-known/passkey-endpoints.

Gdy adres URL zostanie wysłany jako zapytanie, odpowiedź powinna być zgodna z tym schematem:

{
  "enroll": "https://example.com/account/manage/passkeys/create"
  "manage": "https://example.com/account/manage/passkeys"
}

Aby ten link otwierał się bezpośrednio w aplikacji, a nie w internecie, użyj linków do aplikacji na Androida.
Więcej szczegółów znajdziesz w wyjaśnieniu dotyczącym znanego adresu URL punktów końcowych kluczy dostępu w serwisie GitHub.

Pomaganie użytkownikom w zarządzaniu kluczami dostępu przez wyświetlanie informacji o tym, który dostawca je utworzył

Jednym z problemów, z jakimi spotykają się użytkownicy podczas zarządzania wieloma kluczami dostępu powiązanymi z daną aplikacją, jest identyfikacja prawidłowego klucza dostępu do edycji lub usunięcia. Aby rozwiązać ten problem, zalecamy, aby aplikacje i witryny zawierały dodatkowe informacje, takie jak dostawca, który utworzył dane logowania, data utworzenia i data ostatniego użycia, na liście kluczy dostępu na ekranie ustawień aplikacji.Informacje o dostawcy są uzyskiwane przez sprawdzenie identyfikatora AAGUID powiązanego z odpowiednim kluczem dostępu. Identyfikator AAGUID można znaleźć w danych uwierzytelniania klucza dostępu.

Jeśli na przykład użytkownik utworzy klucz dostępu na urządzeniu z Androidem za pomocą Menedżera haseł Google, RP otrzyma identyfikator AAGUID, który wygląda mniej więcej tak: „ea9b8d66-4d01-1d21-3ce4-b6b48cb575d4”. Strona ufająca może dodać adnotację do klucza dostępu na liście kluczy dostępu, aby wskazać, że został on utworzony przy użyciu Menedżera haseł Google.

Aby zmapować identyfikator AAGUID na dostawcę kluczy dostępu, strony RP mogą użyć repozytorium identyfikatorów AAGUID pochodzącego ze źródeł społecznościowych. Wyszukaj identyfikator AAGUID na liście, aby znaleźć nazwę i ikonę dostawcy klucza dostępu.

Dowiedz się więcej o integracji AAGUID.

Rozwiązywanie typowych problemów

W przewodniku rozwiązywania problemów z Menedżerem danych logowania znajdziesz typowe kody błędów, opisy i informacje o ich przyczynach.

Dodatkowe materiały

Więcej informacji o interfejsie Credential Manager API i kluczach dostępu znajdziesz w tych materiałach: