Uprość uwierzytelnianie za pomocą karty uwierzytelniania

Karta uwierzytelniania zapewnia bezpieczny i uproszczony proces uwierzytelniania do użytku w aplikacjach na Androida. Tworząc i uruchamiając AuthTabIntent, możesz wywołać specjalistyczną kartę niestandardową zaprojektowaną do zarządzania kompleksowym procesem uwierzytelniania. Karta jest uproszczona i ma ograniczone możliwości, dzięki czemu użytkownicy mogą skupić się na wykonywanym zadaniu. Po zakończeniu działania karta wywołuje zwrotnie aplikację z wynikiem za pomocą protokołu HTTPS lub niestandardowych schematów.

W pełni funkcjonalna karta niestandardowa
Rysunek 1. Niestandardowa karta z pełną funkcjonalnością.
Karta uwierzytelniania z minimalną funkcjonalnością
Rysunek 2. Karta uwierzytelniania z minimalnymi możliwościami.

Od wersji Chrome 137 karta uwierzytelniania może bezpośrednio zastępować istniejące integracje uwierzytelniania w niestandardowych kartach. W przypadku użytkowników, których urządzenia nie obsługują karty uwierzytelniania, automatycznie następuje przejście na karty niestandardowe. Przejście z kart niestandardowych na karty uwierzytelniania wymaga zmodyfikowania kilku wierszy kodu.

Jak to działa

W przypadku karty uwierzytelniania aplikacja kliencka uruchamia specjalną kartę niestandardową, która wyświetla okno przeglądarki wczytujące adres URL z oczekiwaną stroną uwierzytelniania. Po zakończeniu karta uwierzytelniania zwraca wynik uwierzytelniania za pomocą wywołania zwrotnego.

Po uwierzytelnieniu, gdy nastąpi przejście do podanego wcześniej adresu URI przekierowania wywołania zwrotnego, przekierowanie zostanie przechwycone i zwrócone do aplikacji klienckiej za pomocą wywołania zwrotnego. W przypadku przekierowań korzystających ze schematu https przeglądarka sprawdza, czy domena przekierowania i aplikacja kliencka należą do tego samego wydawcy, za pomocą Digital Asset Links.

Klient otrzymuje przekierowany identyfikator URI ze schematem przekierowania (lub w przypadku protokołu HTTPS host i ścieżkę przekierowania) za pomocą podanego wywołania zwrotnego. Dane te obejmują kod wyniku oraz wszelkie inne dane dostarczone przez interfejs uwierzytelniania. Możesz użyć tych danych do weryfikacji uwierzytelniania lub obsługi scenariuszy, w których uwierzytelnianie się nie powiodło.

Dlaczego karta Autoryzacja?

Przed wprowadzeniem karty uwierzytelniania do obsługi procesów uwierzytelniania można było używać standardowego zamiaru kart niestandardowych. Karta uwierzytelniania jest lepszym rozwiązaniem, ponieważ zapewnia większe bezpieczeństwo i uproszczone działanie, a także ukrywa niektóre wewnętrzne elementy uwierzytelniania przed kodem klienta. Z tych powodów karta autoryzacji zapewnia lepsze wrażenia.

Zwiększone bezpieczeństwo

W typowym wdrożeniu kart niestandardowych wymagana jest intencja, aby otrzymywać dane z okna przeglądarki obsługującego uwierzytelnianie. Wymaga to dodatkowego kodu i naraża aplikację na potencjalną ingerencję w Twoje intencje. W przypadku karty uwierzytelniania dane są odbierane za pomocą wywołania zwrotnego, a przesyłanie danych odbywa się bezpośrednio między interfejsem Android API a aplikacją klienta.

Uproszczone środowisko

Na karcie niestandardowej użytkownik ma dostęp do dodatkowych funkcji przeglądarki, które mogą być niepożądane w przypadku procesu uwierzytelniania. Karta uwierzytelniania zapewnia uproszczoną obsługę, która usuwa większość opcji dostosowywania dostępnych na standardowej karcie niestandardowej. W przypadku przeglądarek Chrome obejmuje to przycisk minimalizacji, menu kontekstowe po długim naciśnięciu i wyszukiwanie po dotknięciu, a także elementy menu Otwórz w Chrome, dodawanie do zakładek, pobieranie i udostępnianie oraz Dodaj do ekranu głównego.

Karty uwierzytelniania nadal mają funkcje, które umożliwiają przeglądarce automatyczne uzupełnianie wcześniej zapisanych haseł i danych do płatności, cofanie i przewijanie stron, odświeżanie, wyświetlanie informacji o stronie, żądanie wersji strony na komputery i tłumaczenie.

Abstrakcja danych

Samo wdrożenie karty uwierzytelniania eliminuje potrzebę intencji odbierania danych z przeglądarki, a także filtrów intencji w AndroidManifest.xml, które były wcześniej wymagane do prawidłowego działania uwierzytelniania. Upraszcza to proces po stronie klienta. Niektóre z tych funkcji mogą być nadal uwzględniane w kodzie klienta, aby zapewnić zgodność wsteczną z kartami niestandardowymi w sytuacjach, gdy na urządzeniach użytkowników nie jest dostępna karta uwierzytelniania.

Implementacja karty Uwierzytelnianie

Karta uwierzytelniania wymaga biblioteki uwierzytelniania przeglądarki AndroidX. Bibliotekę AndroidX Browser Library można dodać w sekcji zależności pliku build.gradle projektu. Interfejsy API są dostępne w wersji alfa. Dodaj do pliku kompilacji te informacje:

dependencies {
    implementation 'androidx.browser:browser:1.9.0'
}

Przed uruchomieniem karty uwierzytelniania zadeklaruj ActivityResultLauncher, która przyjmuje ActivityResultCallerActivityResultCallback. Odbywa się to przed utworzeniem aktywności lub fragmentu:

// In your activity

private final ActivityResultLauncher<Intent> mLauncher =
    AuthTabIntent.registerActivityResultLauncher(this, this::handleAuthResult);

private void handleAuthResult(AuthResult result) {
    String message = switch (result.resultCode) {
        case AuthTabIntent.RESULT_OK -> "Received auth result.";
        case AuthTabIntent.RESULT_CANCELED -> "AuthTab canceled.";
        case AuthTabIntent.RESULT_VERIFICATION_FAILED -> "Verification failed.";
        case AuthTabIntent.RESULT_VERIFICATION_TIMED_OUT -> "Verification timed out.";
    }

    if (result.resultCode == AuthTabIntent.RESULT_OK) {
        message += " Uri: " + result.resultUri;
    }

    Toast.makeText(this, message, Toast.LENGTH_LONG).show();  
}

Następnie użyj AuthTabIntent.Builder, aby utworzyć AuthTabIntent, a potem wywołać metodę launch. Metody uruchamiania akceptują jeden z 2 zestawów parametrów w zależności od wymaganego schematu:

  • redirectScheme: w przypadku niestandardowego schematu przekierowania przeglądarka przekierowuje i zwraca identyfikator URI z podanym schematem.

  • redirectHost, redirectPath: w przypadku schematów przekierowania HTTPS interfejs API wymaga oddzielnego hosta i ścieżki, aby przeglądarka mogła wykryć przekierowanie i zwrócić identyfikator URI. Jeśli używasz protokołu HTTPS, musisz przeprowadzić weryfikację Digital Asset Link.

private void launchAuthTab() {
    AuthTabIntent authTabIntent = new AuthTabIntent.Builder.build();
    authTabIntent.launch(mLauncher, Uri.parse("https://www.example.com/auth"), "mycustomscheme");
}

private void launchAuthTabHttps() {
    String host = "your_host";
    String path = "your_path";
    AuthTabIntent authTabIntent = new AuthTabIntent.Builder.build();
    authTabIntent.launch(mLauncher, Uri.parse("https://www.example.com/auth", host, path);
}

Migracja z kart niestandardowych na kartę uwierzytelniania

Zaktualizuj dotychczasową implementację uwierzytelniania na kartach niestandardowych, modyfikując intencję kart niestandardowych na nową intencję karty uwierzytelniania. Po dodaniu kodu znajdź intencję kart niestandardowych i zmodyfikuj ją na nową intencję karty uwierzytelniania.

CustomTabsIntent customTabsIntent = new CustomTabsIntent.Builder().build();
customTabsIntent.launchUrl(context, uri)

// change to -->

AuthTabIntent authTabIntent = new AuthTabIntent.Builder.build();

authTabIntent.launch(mLauncher, Uri.parse("https://www.example.com/auth", "mycustomscheme");

/* - OR - */

authTabIntent.launch(mLauncher, Uri.parse("https://www.example.com/auth", host, path);

Przełączanie na karty niestandardowe

Niektóre implementacje mogą wymagać uwierzytelniania, w przypadku którego urządzenie użytkownika nie jest przystosowane do obsługi karty uwierzytelniania. Może się to zdarzyć na przykład wtedy, gdy domyślna przeglądarka nie obsługuje karty uwierzytelniania lub gdy jej wersja nie jest na wymaganym poziomie. W takich przypadkach intencja karty uwierzytelniania automatycznie uruchamia kartę niestandardową w przeglądarkach, które ją obsługują.

Możesz sprawdzić, czy przeglądarka obsługuje kartę uwierzytelniania, korzystając z CustomTabsClient#isAuthTabSupported(). Ta metoda umożliwia aplikacji dynamiczne wybieranie między uruchomieniem karty uwierzytelniania a przepływem kart niestandardowych na podstawie możliwości przeglądarki. Aby w elegancki sposób poradzić sobie z sytuacją, w której karta uwierzytelniania nie jest obsługiwana, dodaj implementację karty uwierzytelniania, zachowując dotychczasowy kod kart niestandardowych obsługujący przepływy uwierzytelniania jako rozwiązanie rezerwowe.

Zadbaj o obsługę danych, które mogą pochodzić z usługi ActivityResultCallback lub z intencji działania. Pamiętaj, że jeśli do uruchomienia wersji zapasowej użyjesz AuthTabIntent, a bieżąca przeglądarka nie obsługuje karty uwierzytelniania, po zamknięciu karty niestandardowej Twoja aplikacja otrzyma wynik Activity.RESULT_CANCELED.

Przykład implementacji karty uwierzytelniania z przełączaniem na karty niestandardowe znajdziesz w bibliotece Android Browser Helper.

Dodatkowe materiały