Authentifizierung mit dem Auth-Tab vereinfachen

Auth Tab bietet einen sicheren und vereinfachten Authentifizierungsablauf für die Verwendung in Android-Apps. Wenn Sie eine AuthTabIntent erstellen und starten, können Sie einen speziellen benutzerdefinierten Tab aufrufen, der für die Verwaltung einer End-to-End-Authentifizierung entwickelt wurde. Der Tab ist übersichtlich und bietet nur begrenzte Funktionen, damit sich die Nutzer auf die aktuelle Aufgabe konzentrieren können. Nach Abschluss wird über HTTPS oder benutzerdefinierte Schemas ein Ergebnis an Ihre Anwendung zurückgegeben.

Voll funktionsfähiger benutzerdefinierter Tab
Abbildung 1. Benutzerdefinierter Tab mit allen Funktionen
:
Ein Autorisierungstab mit minimalen Funktionen
Abbildung 2. Tab „Autorisierung“ mit minimalen Funktionen
:

Ab Chrome 137 kann der Auth-Tab vorhandene Authentifizierungsintegrationen für benutzerdefinierte Tabs direkt ersetzen. Bei Nutzern, deren Geräte den Auth-Tab nicht unterstützen, wird automatisch auf benutzerdefinierte Tabs zurückgegriffen. Die Migration von benutzerdefinierten Tabs zum Authentifizierungstab ist durch Ändern einiger Codezeilen möglich.

Funktionsweise

Mit dem Auth-Tab startet eine Client-App einen speziellen benutzerdefinierten Tab, in dem ein Browserfenster mit einer URL geladen wird, die die erwartete Authentifizierungsseite enthält. Nach Abschluss gibt der Auth-Tab das Authentifizierungsergebnis über einen Callback zurück.

Nach der Authentifizierung wird die Weiterleitung an den zuvor angegebenen Callback-Weiterleitungs-URI abgefangen und über den Callback an die Clientanwendung zurückgegeben. Bei Weiterleitungen mit dem HTTPS-Schema prüft der Browser mithilfe von Digital Asset Links, ob die Weiterleitungsdomain und die Client-App demselben Publisher gehören.

Der Client empfängt den aufgerufenen URI mit dem Weiterleitungsschema (oder bei HTTPS den Weiterleitungshost und -pfad) über den bereitgestellten Callback. Diese Daten enthalten einen Ergebniscode sowie alle anderen Daten, die von der Authentifizierungsschnittstelle bereitgestellt werden. Anhand dieser Daten können Sie die Authentifizierung überprüfen oder nicht erfolgreiche Szenarien bearbeiten.

Warum der Tab „Autorisierung“?

Vor dem Auth-Tab konnten Sie einen Standard-Intent für benutzerdefinierte Tabs verwenden, um Authentifizierungsabläufe zu ermöglichen. Ein Auth-Tab ist vorzuziehen, da es für mehr Sicherheit und eine optimierte Nutzererfahrung sorgt und außerdem einige interne Authentifizierungsdetails vom Clientcode abstrahiert. Aus diesen Gründen bietet der Tab „Authentifizierung“ eine bessere Nutzererfahrung.

Erweiterte Sicherheitsfunktionen

Bei einer typischen Implementierung von benutzerdefinierten Tabs ist ein Intent erforderlich, um Daten aus dem Browserfenster zu empfangen, in dem die Authentifizierung erfolgt. Dazu ist zusätzlicher Code erforderlich und Ihre App ist potenziellen Manipulationen ausgesetzt. Bei einem Auth-Tab werden Daten über einen Callback empfangen. Die Daten werden direkt zwischen der Android API und der Client-App übertragen.

Eine optimierte Mediennutzung

In einem benutzerdefinierten Tab hat der Nutzer Zugriff auf zusätzliche Funktionen im Browser, die für einen Authentifizierungsablauf möglicherweise unerwünscht sind. Ein Auth Tab bietet eine vereinfachte Nutzererfahrung, bei der die meisten Anpassungsoptionen eines Standard-Custom Tabs entfernt werden. Bei Chrome-Browsern sind das die Schaltfläche zum Minimieren, das Kontextmenü, das durch langes Drücken aufgerufen wird, die Funktion „Mit Touch suchen“ sowie Menüelemente zum Öffnen in Chrome, zum Setzen von Lesezeichen, zum Herunterladen und Teilen und zum Hinzufügen zum Startbildschirm.

Auth-Tabs bieten weiterhin Funktionen, mit denen der Browser zuvor gespeicherte Passwörter und Zahlungen automatisch ausfüllen, vorwärts oder rückwärts navigieren, die Seite aktualisieren, Seiteninformationen anzeigen, eine Desktopversion der Seite anfordern und Übersetzungen bereitstellen kann.

Datenabstraktion

Wenn Sie nur den Auth-Tab implementieren, ist kein Intent mehr erforderlich, um Daten vom Browser zu empfangen. Außerdem sind keine Intent-Filter in AndroidManifest.xml mehr erforderlich, damit die Authentifizierung richtig funktioniert. Dadurch wird die Komplexität auf Clientseite reduziert. Einige dieser Funktionen können weiterhin in den Clientcode aufgenommen werden, um die Abwärtskompatibilität mit benutzerdefinierten Tabs in Situationen zu gewährleisten, in denen der Auth-Tab auf Nutzergeräten nicht verfügbar ist.

Tab „Authentifizierung“ implementieren

Für den Tab „Auth“ ist die AndroidX-Browser-Auth-Bibliothek erforderlich. Die AndroidX Browser Library kann im Abschnitt „dependencies“ der build.gradle-Datei eines Projekts hinzugefügt werden. Die APIs sind in einem Alpha-Build verfügbar. Fügen Sie Ihrer Build-Datei Folgendes hinzu:

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

Bevor Sie einen Auth-Tab starten, deklarieren Sie eine ActivityResultLauncher, die sowohl ein ActivityResultCaller als auch ein ActivityResultCallback akzeptiert. Dies erfolgt vor dem Erstellen der Aktivität oder des Fragments:

// 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();  
}

Verwenden Sie als Nächstes AuthTabIntent.Builder, um eine AuthTabIntent zu erstellen, und rufen Sie dann die Methode launch auf. Die Startmethoden akzeptieren je nach Schema, das Sie benötigen, einen von zwei Parametersätzen:

  • redirectScheme: Bei einem benutzerdefinierten Weiterleitungsschema leitet der Browser weiter und gibt den URI mit dem angegebenen Schema zurück.

  • redirectHost, redirectPath: Bei HTTPS-Weiterleitungsschemas sind für die API ein separater Host und Pfad erforderlich, damit der Browser die Weiterleitung erkennen und die URI zurückgeben kann. Wenn Sie HTTPS verwenden, ist eine Digital Asset Link-Bestätigung erforderlich.

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);
}

Von benutzerdefinierten Tabs zum Auth-Tab migrieren

Aktualisieren Sie Ihre vorhandene Implementierung der benutzerdefinierten Tab-Authentifizierung, indem Sie die benutzerdefinierte Tab-Intent in die neue Auth Tab-Intent ändern. Suchen Sie nach dem Hinzufügen des Codes nach dem Intent für benutzerdefinierte Tabs und ändern Sie ihn in den neuen Intent für den Auth-Tab.

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);

Fallback auf benutzerdefinierte Tabs

Bei einigen Implementierungen kann eine Authentifizierung erforderlich sein, bei der das Gerät des Nutzers nicht für den Auth-Tab geeignet ist. Das kann beispielsweise passieren, wenn der Standardbrowser die Authentifizierungsregisterkarte nicht unterstützt oder die Version des Standardbrowsers nicht den erforderlichen Anforderungen entspricht. In diesen Fällen wird für Browser, die Custom Tabs unterstützen, automatisch ein Custom Tab anstelle eines Auth Tab-Intents gestartet.

Mit CustomTabsClient#isAuthTabSupported() können Sie prüfen, ob der Auth-Tab vom Browser unterstützt wird. Mit dieser Methode kann Ihre App je nach Browserfunktionen dynamisch zwischen dem Starten eines Auth-Tabs oder eines Custom Tabs-Ablaufs wählen. Um die Situation, in der der Auth-Tab nicht unterstützt wird, ordnungsgemäß zu behandeln, fügen Sie die Auth-Tab-Implementierung hinzu und behalten Sie Ihren vorhandenen benutzerdefinierten Tab-Code bei, der Authentifizierungsabläufe als Fallback behandelt.

Achten Sie darauf, Daten zu verarbeiten, die entweder an Ihre ActivityResultCallback oder an Ihren Activity-Intent gesendet werden können. Wenn AuthTabIntent verwendet wird, um die Fallback-Version zu starten, und der Auth-Tab vom aktuellen Browser nicht unterstützt wird, erhält Ihre App das Ergebnis Activity.RESULT_CANCELED, wenn der benutzerdefinierte Tab geschlossen wird.

Ein Beispiel für die Implementierung des Auth-Tabs mit Fallback auf benutzerdefinierte Tabs finden Sie in der Android Browser Helper-Bibliothek.

Zusätzliche Ressourcen