Nahtlose Anmeldung und digitale Anmeldedaten auf Android-Geräten

Hallo zusammen.

vielen Dank für die Teilnahme!

Heute möchten wir über die Zukunft der Authentifizierung und der digitalen Identität sprechen.

Ich bin Tom Colvin.

Ich bin CTO bei Apptaura und GDE für Android. Außerdem ist Chiping Yeh dabei, Senior Android Developer Relations Engineer bei Google.

Das gute alte Passwort hat ausgedient.

Oder zumindest sollte es so sein.

Heute möchte ich mit Ihnen über eine Welt ohne Passwörter sprechen.

Passwörter sind eine bekannte Schwachstelle in unserer Sicherheitsinfrastruktur.

Selbst wenn sie sicher gespeichert sind, sind sie anfällig für Phishing, Server-Sicherheitslücken und automatisierte Angriffe wie Credential Stuffing.

In der Branche haben wir versucht, dieses Problem durch Komplexität zu lösen: Sonderzeichen, Zahlen, obligatorische Passwortänderungen.

Die Praxis zeigt, dass dies nicht funktioniert hat. Das liegt zum Teil daran, dass Sie durch die Erhöhung des Schwierigkeitsgrads paradoxerweise unsicheres Verhalten fördern.

Denn ein komplexes Passwort, das regelmäßig geändert wird, wird wahrscheinlich auf einem Notizzettel aufgeschrieben.

Und selbst die SMS-basierte 2-Faktor-Authentifizierung hat sich als anfällig für Abfangversuche wie SIM-Swapping erwiesen.

Heute ist dieses Problem jedoch weitgehend gelöst.

Passkeys basieren auf FIDO-Standards und verwenden Public-Key-Kryptografie.

Sie sind sehr resistent gegen Phishing, werden bei einer Serverpanne nicht offengelegt und sind über die Displaysperre direkt mit der Sicherheit des Smartphones des Nutzers verknüpft. In den meisten Fällen basiert die Displaysperre auf unseren biometrischen Daten, Fingerabdrücken usw. Außerdem verbessern sie die Nutzerfreundlichkeit aktiv, da sie eine einheitliche Nutzung auf allen Plattformen ermöglichen und sich Nutzer keine komplexen Passwörter merken müssen.

Unser heutiges Manifest ist einfach.

Es ist an der Zeit, auf Passwörter zu verzichten.

Und die Tools dafür haben wir bereits.

Der Jetpack Credential Manager ist ein zentraler Bestandteil dieser Entwicklung auf Android.

Diese API wird bis Android 4.4 unterstützt. Passkeys werden seit Android 9 unterstützt. Sie bietet eine einzige, einheitliche API, die Passkeys sowie herkömmliche Authentifizierungsmethoden wie die föderierte Anmeldung (z. B. „Über Google anmelden“) unterstützt. Außerdem bietet sie einen reibungslosen Fallback auf Passwörter, falls erforderlich.

Sie rufen die Credential Manager API auf, die die Benutzeroberfläche für die Auswahl der Authentifizierungsmethode durch den Nutzer verwaltet.

Anschließend wird die richtige Anmeldedaten-Anmeldeinformation zurückgegeben, die sicher abgerufen wurde.

Sie unterstützt die Anmeldung, die Registrierung und die Sicherung von Anmeldedaten.

Außerdem können Sie damit Anmeldedaten aktualisieren und löschen.

Außerdem können Nutzer ihre Passwörter und Passkeys mit nur wenigen Klicks zwischen Anbietern von Anmeldedaten übertragen, ohne Dateien herunterladen zu müssen.

Es soll Nutzern die vollständige Kontrolle über ihre Daten und die Freiheit geben, den Anbieter jederzeit zu wechseln.

Der Credential Manager unterstützt viele Formfaktoren, darunter Smartwatches, Fernseher, XR, Autos, Smartphones, Foldables und Tablets.

Und was für uns am wichtigsten ist: Es gibt einen speziellen Ablauf für Passkeys.

So sieht die Registrierung für den Nutzer aus.

Meine App teilt dem Credential Manager mit, dass die Passkey-Authentifizierung verfügbar ist, und stellt ihm die vom Back-End erfassten Details zur Verfügung.

Sie tippen auf „Registrieren“ und der Credential Manager zeigt eine Ansicht am unteren Rand mit einer Aufforderung zur Displaysperre an.

Diese wird am häufigsten mit biometrischen Daten wie einem Fingerabdruck oder Gesichtsscan entsperrt.

Der Credential Manager übernimmt dann die komplexe kryptografische Arbeit, wie das Erstellen des Passkeys.

Der Passkey wird in meinem Credential Manager gespeichert, in diesem Fall im Google Passwortmanager. Es könnte aber auch ein anderer sein.

So sieht der Code aus.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Zuerst erstellen wir dieses createPublicKeyCredentialRequest-Objekt mit den Details des Back-Ends, also registerRequestJson.

Anschließend rufen wir die magische Methode credentialManager.createCredential auf.

Wir übergeben diese Anfrage und den lokalen Kontext, damit die Benutzeroberfläche angezeigt werden kann.

Übrigens musste ich hier keinen UI-Code schreiben.

Der Credential Manager übernimmt das vollständig für uns.

Das ist der Anmeldevorgang.

Für den Nutzer sieht das Ganze fast wie der Registrierungsprozess aus.

Du musst das Gerät nur einmal entsperren.

Für Entwickler ist es nur geringfügig anders.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

Zuerst rufen wir die Details der Anmeldung vom Backend ab, um eine GetPublicKeyCredential-Instanz zu erstellen.

Wir teilen dem Credential Manager mit, welche Arten von Anmeldedaten wir unterstützen.

Hier sind es nur Passkeys.

Wir können aber auch andere Arten von Anmeldedaten hinzufügen, wenn wir möchten.

Anschließend rufen wir credentialManager.getCredential auf und übergeben die Liste der Anmeldedaten, die wir gerade angefordert haben.

Auch hier gibt es keinen UI-Code.

Sie müssen keinen UI-Code schreiben.

Der Credential Manager übernimmt das vollständig für uns.

Sie lenkt den Nutzer zur am häufigsten verwendeten Option, während die anderen als Backup verfügbar bleiben.

Damit wird eines der lästigsten Authentifizierungsprobleme von heute automatisch gelöst.

Ist dir das aufgefallen?

Das bedeutet, dass sich die App merkt, mit welcher Methode ich mich zuletzt angemeldet habe.

Die Antwort wird übersichtlich in einer Ansicht am unteren Rand präsentiert.

Das ist übrigens nicht nur für die Nutzer ärgerlich.

Das ist ein echter Reibungspunkt.

Sie führt zu unnötigen Kontowiederherstellungen und hat kommerzielle Auswirkungen, z. B. abgebrochene Warenkörbe.

Hier ist der Code meiner Demo-Anwendung, mit dem Sie den Credential Manager selbst ausprobieren können.

Diese Abläufe kannst du dir auf deinem eigenen Gerät ansehen.

Und links sind die offiziellen Google-Codebeispiele.

Diese kümmert sich um das Erstellen von Passkeys.

Wie sieht es mit der Umstellung von Nutzern mit Passwörtern auf Passkeys aus?

Ein leistungsstarkes Tool dafür ist die bedingte Erstellung.

Wenn sich der Nutzer gerade mit seinem Passwort angemeldet hat und dieses von einem unterstützten Anbieter von Anmeldedaten automatisch ausgefüllt wurde, wissen wir, dass er aktiv ist, und haben seine Identität gerade erst bestätigt.

In diesem Fall können wir mit der Funktion „Conditional Create“ die Erstellung eines Passkeys automatisch im Hintergrund anfordern.

Der Workflow des Nutzers wird nicht unterbrochen.

Der Passkey wird im Hintergrund generiert und gespeichert.

Der Google Passwortmanager zeigt eine Benachrichtigung an, um zu bestätigen, dass dies geschehen ist.

Bei anderen Passwortmanagern kann das anders sein.

Der Code für die bedingte Erstellung sieht dem Code für die Registrierung sehr ähnlich.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Das magische Flag ist isConditional true, damit der Nutzer diese Benutzeroberfläche nicht sieht.

Da es opportunistisch funktioniert, fügen wir es in einen Try-Catch-Block ein.

Fehler werden im Hintergrund behandelt, damit der Nutzer nicht gestört wird, wenn der Prozess fehlschlägt.

Anschließend wird der Passkey im Credential Manager des Nutzers gespeichert und ist beim nächsten Mal verfügbar.

Außerdem können Anbieter von Anmeldedaten mit dem Credential Manager ihre Anmeldedaten sicher importieren und exportieren.

Nur ein paar Klicks.

Es sind keine Downloads erforderlich.

Das bietet mehr Flexibilität, während die Informationen gleichzeitig geschützt bleiben.

Der Ablauf sieht so aus:

Der Nutzer fordert in seinem neuen Anbieter von Anmeldedaten den Import von Anmeldedaten an.

Anschließend übernimmt der Credential Manager die Import-UI, sodass der Nutzer die Quelle der Anmeldedaten auswählen kann.

Der exportierende Anbieter von Anmeldedaten kann dann eine eigene Benutzeroberfläche bereitstellen, um den Nutzer zu informieren und die entsprechenden Warnungen anzuzeigen.

Schließlich werden die Daten über einen sicheren Kanal an den neuen Anbieter von Anmeldedaten des Nutzers übergeben.

So kann es ohne Nutzerinteraktion importiert werden.

Was passiert aber, wenn der Nutzer einen Passkey in seiner App oder auf seiner Website widerruft?

Der Anbieter der Anmeldedaten weiß dann nicht unbedingt, dass dies geschehen ist.

Wenn sie sich das nächste Mal anmelden möchten, bietet der Credential Manager diesen ungültigen Passkey an und der Anmeldeversuch wird abgelehnt.

Wenn ein Nutzer seinen Nutzernamen oder Anzeigenamen aktualisiert, ist ebenfalls eine Synchronisierung erforderlich.

Mit der Signal API kann Ihre App diese spezifischen Zustände jetzt an den Anbieter von Anmeldedaten melden.

Nehmen wir als Beispiel die Anmeldung mit einem widerrufenen Passwort.

Ihre App kann diesen spezifischen Fehlerstatus abfangen und ihn an den Anbieter der Anmeldedaten des Nutzers weitergeben.

Der Anbieter von Anmeldedaten kann sich dann selbst aktualisieren, sodass dieser bestimmte Passkey nicht angeboten wird.

Das sind einige der Funktionen des Credential Managers. Er ist unglaublich hilfreich, um Nutzer dazu zu bringen, sich mit Passkeys zu registrieren, und um Passkeys bei der Anmeldung gegenüber anderen Methoden zu priorisieren.

Aber denken Sie daran, dass unser oberstes Ziel darin besteht, vollständig auf Passwörter zu verzichten.

Wie hilft der Credential Manager dabei, dieses Ziel zu erreichen?

Hier ist unser Vorschlag für einen fünfstufigen Prozess.

In den ersten beiden Schritten stellen Sie die Nutzer, die Passwörter verwenden, auf Passkeys um.

Zuerst versuchen wir es opportunistisch mit der bedingten Erstellung.

Wenn sich eine solche Gelegenheit nicht ergibt, müssen wir irgendwann die Nutzer um Hilfe bitten. Dazu senden wir ihnen In-App-Einladungen, in denen wir sie auffordern, einen Passkey einzurichten.

Wir können diese nach und nach immer prominenter präsentieren.

Aus Nutzersicht müssen sie in der Regel nur die Displaysperre entsperren, z. B. mit einem biometrischen Verfahren.

Sobald die Analysen zeigen, dass die überwiegende Mehrheit Ihrer Nutzer Konten mit Passkeys verwendet, können Passkeys für alle neuen Nutzer vorgeschrieben werden.

Aber diese alten Nutzer sind diejenigen, mit denen wir uns in den letzten drei Schritten befassen.

Wir empfehlen Passkey-Nutzern, ihre Passwörter zu entfernen.

In Schritt 3 können sie dies manuell tun, indem sie in ihren Kontoeinstellungen die Option „Passwort löschen“ auswählen.

In Schritt 4 beginnen wir, die Löschung von Passwörtern zu forcieren, z. B. durch In-App-Benachrichtigungen in Kombination mit erklärenden Texten.

Und schließlich ändern Sie die Einstellung für das Löschen von Passwörtern von „Opt-in“ zu „deaktivieren“.

Irgendwann kann auch diese letzte Deaktivierungsmöglichkeit verschwinden.

Die Analysen geben uns die Gewissheit, dass wir die Passwortabläufe vollständig aus der App entfernen können.

Der Übergang zu einer Welt ohne Passwörter ist also kein theoretisches Sicherheitskonzept mehr, das irgendwann in der Zukunft umgesetzt wird.

Sie wird umfassend unterstützt.

Die APIs sind robust und die Nutzerfreundlichkeit ist hervorragend.

Ich empfehle Ihnen, noch heute mit der Integration von Passkey-Abläufen in den Credential Manager zu beginnen.

Beginnen Sie mit der Umstellung Ihrer Nutzer und lassen Sie Passwörter endlich der Vergangenheit angehören.

Vielen Dank.

Jetzt möchte ich an Chiping übergeben, der über die nächste Entwicklungsstufe bei der Gerätemigration und ‑identität sprechen wird.

Cool.

Vielen Dank, Tom.

Wie Tom bereits erwähnt hat, ist eine nahtlose Authentifizierung auf Nutzergeräten entscheidend.

Was passiert aber, wenn ein Nutzer ein neues Smartphone bekommt?

Die meisten Nutzer brechen die User Journey ab, wenn sie das Gerät wechseln.

Heute möchte ich zuerst darüber sprechen, wie wir dieses Problem lösen, und kurz auf eine bevorstehende Anforderung im Google Play Store zur Wiederherstellung von Anmeldedaten eingehen.

Ab April 2027 müssen Apps bei Google Play die Anforderungen für die Zero-Tap-Anmeldung erfüllen, damit sie weiterhin uneingeschränkt veröffentlicht werden können und im Google Play Store optimal sichtbar sind.

Was ist die Zero-Tap-Anmeldung?

Das bedeutet, dass sich Nutzer beim Wechsel zu einem neuen Gerät nicht manuell noch einmal in Ihrer App authentifizieren müssen.

Wie setzen wir das um?

Die von uns empfohlene Methode hierfür ist die Android Restore Credentials API über den Credential Manager.

Mit dieser API können Sie einen sogenannten Wiederherstellungsschlüssel generieren, der je nach den Sicherungseinstellungen des Nutzers auf dem Gerät des Nutzers oder in der Cloud gespeichert wird.

Wir empfehlen, diesen Schlüssel im Hintergrund zu generieren, sobald der Nutzer angemeldet ist.

In diesem Diagramm wird ein Nutzer dargestellt, der sich in der App anmeldet.

Der Wiederherstellungsschlüssel wird dann erstellt, wenn die App verwendet wird.

Dieser Schlüssel wird dann lokal oder, falls aktiviert, remote in der Cloud gespeichert.

Wenn der Nutzer sein neues Gerät einrichtet, werden die Anmeldedaten für die Wiederherstellung im Hintergrund während der Geräteeinrichtung übertragen.

Nutzer können Daten aus der Cloud oder per Übertragung von Gerät zu Gerät wiederherstellen.

Wenn Ihre App geöffnet wird, können Sie die Credential Manager API aufrufen, um diesen Wiederherstellungsschlüssel zu verwenden und den Nutzer beim ersten Start auf dem neuen Gerät anzumelden.

So können sich Nutzer schnell und sicher in Ihrer App anmelden.

Wenn Sie möchten, dass Ihre App sofort nach der Einrichtung wiederhergestellt wird, ohne geöffnet zu werden, können Sie einen benutzerdefinierten Sicherungs-Agenten implementieren.

So kann sich der Nutzer in Ihrer App anmelden, ohne sie manuell öffnen zu müssen.

Einige unserer Partner haben dies bereits in ihrer App implementiert.

Uber ist der weltweit größte Fahrdienstanbieter, der Millionen von Menschen befördert und gleichzeitig Essenslieferungen, Krankentransporte und Frachtlogistik anbietet.

Ein einfacher Zugriff ist entscheidend.

Wenn Nutzer zu einem neuen Gerät wechseln, erwarten sie einen nahtlosen Übergang, ohne sich jedes Mal wieder in der Uber App anmelden oder eine SMS-basierte Einmalauthentifizierung durchlaufen zu müssen.

Dieser häufige Gerätewechsel stellt eine Herausforderung für die Nutzerbindung dar.

Nach einer Bewertung der Nutzeranforderungen und der Erstellung von Code-Prototypen hat Uber die Unterstützung für die Wiederherstellung von Anmeldedaten in die Uber Rider App integriert. Die Ergebnisse waren sehr positiv.

Sie schätzen, dass dadurch täglich 4 Millionen durchschnittliche Anmeldungen eingespart werden, und erwarten, dass diese Zahl mit zunehmender Akzeptanz steigen wird.

Über diesen QR-Code und Link erhalten Sie weitere Informationen zu dieser neuen Richtlinie und dazu, wie Sie die Anforderungen für die Wiederherstellung ohne Tippen erfüllen können.

Diese Änderung wird im April 2027 eingeführt. Bitte tragen Sie sich diesen Termin in Ihren Kalender ein.

Wenn Sie die Funktion „Anmeldedaten wiederherstellen“ in Ihrer App implementieren möchten, finden Sie über diesen QR-Code und Link Informationen zu unserem Skill „Anmeldedaten wiederherstellen“.

Mit diesem Skill können Sie die Funktion schnell entwickeln oder mit dem KI-Agenten Ihrer Wahl testen.

Sehen wir uns nun die nächste Innovation im Bereich der digitalen Identität an: die Digital Credentials API über den Credential Manager.

Sehen wir uns an, was digitale Ausweise sind und wie sie funktionieren.

Digitale Ausweise sind kryptografisch überprüfbare digitale Dokumente, mit denen Nutzer Informationen über sich selbst angeben können.

Diese Dokumente werden in digitalen Haltern auf dem Gerät eines Nutzers gespeichert und können von anderen Apps auf dem Gerät angefordert oder auf hybride Weise präsentiert werden, z. B. über einen QR-Code.

Die Einsatzmöglichkeiten sind vielfältig und reichen von der Identitätsprüfung über den Zugriff auf Dienste bis hin zum Onlinekauf von Artikeln.

Digitale Ausweise bieten eine sichere und bequeme Möglichkeit, Informationen weiterzugeben, ohne dass physische Karten erforderlich sind.

An digitalen Ausweisdokumenten sind drei Parteien beteiligt: der Aussteller, der Inhaber und der Prüfer.

Der Lebenszyklus eines digitalen Berechtigungsnachweises verläuft im Allgemeinen von links nach rechts.

Sehen wir uns die einzelnen Entitäten und ihre Rolle genauer an.

Die erste ist der Aussteller, der, wie der Name schon sagt, ein Berechtigungsnachweis ausstellt, so wie die Regierung Ihren Reisepass ausstellt.

In der digitalen Welt werden diese Berechtigungsnachweise jedoch auch vom Aussteller mit seinem digitalen Zertifikat signiert, um Spoofing zu verhindern. So kann jeder, der den Berechtigungsnachweis erhält, genau wissen, von wem er stammt.

Tatsächlich kann jeder ein Aussteller sein, egal ob Fitnessstudio, Hotel oder Sie selbst.

Sie müssen nur einen Berechtigungsnachweis erstellen und signieren.

Der Aussteller erstellt und stellt also Berechtigungsnachweise aus, aber sie müssen irgendwo gespeichert werden, so wie Sie Ihren amtlichen Ausweis in Ihrer eigenen Brieftasche aufbewahren müssen.

Das ist die nächste Partei, die als Inhaber bezeichnet wird und auch häufig als digitales Wallet beschrieben wird.

Inhaber haben, wie der Name schon sagt, hauptsächlich Berechtigungsnachweise, die von Ausstellern ausgestellt wurden.

Sie werden als App auf dem Gerät gespeichert und können dann bei Bedarf vorgezeigt werden.

Ähnlich wie bei Ausstellern kann jeder Inhaber sein.

Tatsächlich ist es nicht ungewöhnlich, dass Aussteller und Inhaber von derselben Entität verwaltet werden.

Ein Beispiel wäre ein Fitnessstudio, das einen eigenen digitalen Mitgliedsausweis erstellen und über eine eigene App verwalten möchte.

Das wäre sowohl ein Aussteller als auch ein Inhaber in einem.

Die dritte Partei ist der Prüfer oder die Partei, die die digitalen Berechtigungsnachweise anfordert.

Prüfer stellen in der Regel Anfragen zu Ausweisdokumenten, um Attribute eines Nutzers zu prüfen, z. B. das Mindestalter oder den Nachnamen.

Das sind Unternehmen oder Apps, die zusätzliche Nutzerdaten benötigen, um einen Dienst auszuführen, z. B. den Kauf von Alkohol oder die Überprüfung eines Mindestalters.

Unter Android werden die Interaktionen zwischen diesen drei Parteien und dem Nutzer über den Credential Manager mit der Digital Credentials API koordiniert.

Der Aussteller kann die API aufrufen, um dem Inhaber Anmeldedaten auszustellen. Dies ist jedoch nicht erforderlich, wenn es sich um dieselbe Entität handelt.

Nachdem der Berechtigungsnachweis ausgestellt wurde, kann ein Prüfer eine API aufrufen, um den Berechtigungsnachweis anzufordern.

Der Credential Manager gleicht die Anfrage mit allen verfügbaren Inhabern ab und präsentiert sie dem Nutzer, damit er den Berechtigungsnachweis auswählen und seine Einwilligung erteilen kann.

Nachdem ein Inhaber ausgewählt wurde, wird er aufgerufen und kann bei Bedarf zusätzliche Prüfungen durchführen, bevor der Berechtigungsnachweis schließlich mit dem Prüfer geteilt wird.

Sobald der Prüfer die Anmeldedaten erhält, kann er auch verschiedene Prüfungen der Legitimität der Anmeldedaten durchführen, einschließlich der Überprüfung des ursprünglichen Ausstellers.

Sie fragen sich vielleicht, wie digitale Berechtigungsnachweise genau geschützt werden.

In jeden Schritt des Prozesses sind Sicherheitsmaßnahmen integriert. Einige davon sehen wir uns jetzt an.

Wenn der Aussteller einen Berechtigungsnachweis mit einem Inhaber teilen möchte, muss er also prüfen, ob der Inhaber nicht manipuliert oder kopiert werden kann, also ob er vertrauenswürdig ist.

Wie kann es das überprüfen?

Bevor ein Aussteller den Berechtigungsnachweis ausstellt, muss der Inhaber seine eigene Identität und die Sicherheit des Geräts nachweisen, auf dem er arbeitet.

Der Inhaber sendet seine Wallet-Attestierung, in der Regel als überprüfbare Zertifikatskette.

Der Inhaber generiert außerdem ein hardwaregebundenes Schlüsselpaar.

Es sendet dem Aussteller den öffentlichen Schlüssel aus diesem Schlüsselpaar mit der Android-Schlüsselattestierung, sodass der Aussteller die Legitimität der Hardware prüfen kann.

Der Aussteller signiert diesen öffentlichen Schlüssel in den ausgestellten Berechtigungsnachweis, sodass der Berechtigungsnachweis offiziell an das einzelne Gerät gebunden ist.

Sobald der Inhaber einen neuen Berechtigungsnachweis hat, registriert er nur die Metadaten des Berechtigungsnachweises beim Credential Manager.

Der Credential Manager verwendet diese Metadaten, um zu bestimmen, welche Inhaber angezeigt werden sollen, wenn ein Prüfer eine Anfrage für einen Berechtigungsnachweis stellt.

Es werden keine echten Nutzerdaten im Credential Manager registriert oder an Google weitergegeben.

Auch wenn der Credential Manager Wallets auswählt, die dem Nutzer angezeigt werden sollen, wird der Inhalt der einzelnen Wallets zu diesem Zeitpunkt nicht offengelegt.

Wenn jetzt eine Anfrage für einen Berechtigungsnachweis gestellt wird und ein Nutzer der Freigabe eines Berechtigungsnachweises zustimmt, wird der ausgewählte Inhaber aufgerufen und die Workflow-Steuerung an den Inhaber übergeben.

Zur Erinnerung: Ein Holder ist nur eine App, also wird die App aufgerufen.

Der Inhaber kann dann beispielsweise den anfragenden Prüfer und den angeforderten Berechtigungsnachweis sehen und entscheiden, ob er diesen Berechtigungsnachweis mit dem Prüfer teilen möchte, auch wenn der Nutzer bereits die Erlaubnis erteilt hat.

Die Anmeldedaten selbst sind für Google nicht zugänglich.

Es werden nur die Routing-Metadaten registriert und die Nutzlast wird zwischen dem Inhaber und dem Prüfer Ende-zu-Ende verschlüsselt.

So hat der Inhaber die Kontrolle darüber, mit welchen Parteien er seine Berechtigungsnachweise teilen möchte.

Nachdem der Prüfer den Berechtigungsnachweis angefordert und der Inhaber ihn freigegeben hat, erhält der Prüfer die Präsentation des Berechtigungsnachweises vom Inhaber.

Der Prüfer kann jetzt prüfen, ob die Antwort vom ursprünglichen Inhaber des Berechtigungsnachweises für die Anfrage neu generiert wurde.

Es kann bestätigen, dass die Antwort auf die Anfrage nach dem Ausweis mit dem gerätegebundenen Schlüssel des Inhabers signiert ist, einschließlich der Anforderung eines Einmal-Tokens und des vom Inhaber beobachteten Aufrufursprungs.

Der Prüfer kann auch die Authentizität des Ausstellers des Berechtigungsnachweises prüfen, indem er das Ausstellerzertifikat verifiziert und so sicherstellt, dass es von einer vertrauenswürdigen Quelle stammt.

Kurz gesagt: Aussteller erhalten Hardwaregarantien, Inhaber können festlegen, welche Berechtigungsnachweise sie teilen möchten, Prüfer erhalten einen kryptografischen Nachweis des Ausstellers und Inhabers und Nutzer behalten die volle Kontrolle darüber, welche Daten sie teilen möchten.

Nachdem wir uns mit der Sicherheit von digitalen Berechtigungsnachweisen befasst haben, sehen wir uns nun einige der Anwendungsfälle für digitale Berechtigungsnachweise an, die heute über die Digital Credentials API unter Android verfügbar sind.

Die erste Methode, die ich vorstellen möchte, ist die E‑Mail-Bestätigung.

Diese API ruft die Gmail-Adresse, mit der ein Nutzer angemeldet ist, direkt von seinem Gerät ab und stellt sie Ihrer App als von Google verifizierte digitale Anmeldedaten zur Verfügung. So müssen keine Einmalpasswörter oder Magic Links mehr gesendet werden.

Das bedeutet, dass der Nutzer Ihre App nicht verlassen muss und nur einmal auf die vertraute Ansicht am unteren Rand des Credential Managers tippen muss, um seine Einwilligung zu erteilen.

Hier ist eine Demoaufnahme der API in Aktion.

Dies ist eine Beispiel-App, die die E‑Mail-Bestätigung über die Digital Credentials API implementiert.

Wenn ich auf „Bestätigte E‑Mail-Adresse anfordern“ tippe, fordert der Credential Manager einen digitalen Ausweis mit einer bestätigten E‑Mail-Adresse von den Inhabern auf dem Gerät an, die diese Art von Ausweis haben.

In diesem Fall ist nur Google der Inhaber dieses bestätigten E‑Mail-Ausweises, der in der Ansicht am unteren Rand angezeigt wird.

Dies ist eine der E-Mail-Adressen, mit denen der Nutzer auf dem Gerät angemeldet ist.

In diesem Fall ist Google sowohl der Aussteller als auch der Inhaber des digitalen Berechtigungsnachweises.

Nachdem ich den Berechtigungsnachweis ausgewählt habe, den ich teilen möchte, wird er an die App zurückgegeben. Diese zeigt derzeit nur die im Berechtigungsnachweis enthaltenen Felder an, also die bestätigte E‑Mail-Adresse.

In Ihrer App können Sie diese Informationen verwenden, um zum nächsten App-Bildschirm zu gelangen, z. B. zum Erstellen eines Passkeys oder zu anderen Schritten der Kontoerstellung.

Für die Nutzer ist es wirklich so einfach, wie die Einwilligung zu erteilen und dann zum nächsten Bildschirm zu wechseln.

Wenn Sie es ausprobieren möchten, rufen Sie unser GitHub-Beispiel auf und installieren Sie es auf Ihrem eigenen Gerät.

Bitte versuchen Sie, die Funktion auf einem physischen Gerät zu verwenden. Beachten Sie, dass Sie auf Ihrem Gerät in mindestens einem Gmail-Konto angemeldet sein müssen.

Wenn die Leute interessiert sind, gebe ich ihnen also etwas mehr Zeit.

Okay.

Klingt spannend, oder?

Und wenn Sie an die E‑Mail-Bestätigung denken, welche andere Form der Nutzerbestätigung fällt Ihnen dann ein?

Richtig, die Bestätigung der Telefonnummer.

Die Digital Credentials API unterstützt auch die Bestätigung der Telefonnummer, wodurch die Probleme und Sicherheitslücken von Einmalpasswörtern per SMS vermieden werden.

Die Bestätigung per Telefonnummer erfolgt ebenfalls über die Digital Credentials API. In diesem Fall wird die Telefonnummer auf dem Gerät angefordert und als digitaler Berechtigungsnachweis präsentiert.

Der Nutzer sieht nur die vertraute Ansicht am unteren Rand des Credential Managers, um seine Telefonnummer zu teilen oder zu bestätigen. Er bleibt in der App und muss nur ein paar Mal tippen, um die Bestätigung abzuschließen.

Hier sehen Sie eine Beispiel-App, in der der Kunde seine Telefonnummer mit nur einem Tippen teilen kann, ohne die App zu verlassen.

Wie funktioniert diese Einrichtung?

Wenn wir das auf die Parteien für digitale Ausweise übertragen, ist der Aussteller in diesem Fall der Mobilfunkanbieter der Telefonnummer auf der SIM-Karte des Geräts und der Inhaber ist Android Telephony.

Wenn ein Prüfer, z. B. Ihre App, die Telefonnummer des Nutzers anfordert, wird sie über einen Aufruf der Digital Credentials API von Google Telephony abgerufen.

Sie fragen sich vielleicht, wie die Abrechnung funktioniert.

In diesem Ablauf gibt es einen zusätzlichen Schritt, bei dem der Berechtigungsnachweis zu Abrechnungszwecken an deinen Mobilfunkanbieter oder Aggregator weitergegeben wird.

Dies geschieht, nachdem die Telefonnummer von Google Telephony abgerufen wurde, wo sie verschlüsselt gespeichert ist.

Diese wird dann an den Mobilfunkanbieter weitergegeben, der sie entschlüsselt und die Telefonnummer direkt an das Back-End Ihrer App zurückgibt. Währenddessen wird Ihnen der Betrag in Rechnung gestellt.

Das Tolle daran ist, dass der Mobilfunkanbieter Ihnen nur erfolgreiche Bestätigungen in Rechnung stellt, die über eine mobile Datenverbindung oder ein WLAN übertragen werden und viel zuverlässiger als SMS sind.

Hier sehen Sie eine Demo der Bestätigung der Telefonnummer in Aktion, bei der Firebase als Carrier Aggregator verwendet wird.

Die App fragt im Rahmen des Anmeldevorgangs nach der Telefonnummer des Nutzers.

Dieser Nutzer hat mehrere SIM-Karten und wählt eine aus, die er für die App freigeben möchte.

Sobald der Nutzer seine Auswahl bestätigt, erfolgt der Austausch im Hintergrund.

Anschließend wird der nächste Bildschirm mit der abgerufenen Telefonnummer angezeigt.

Der Nutzer musste die App nicht verlassen und nur die Telefonnummer auswählen und bestätigen, um den Vorgang mit wenigen Schritten abzuschließen.

Lassen Sie den Vorgang einfach abschließen, damit Sie die Fertigstellung noch einmal sehen können.

Auf dem letzten Bildschirm wird die Telefonnummer angezeigt.

Das wars!

Wir haben heute viel gelernt.

Zuerst haben wir uns angesehen, wie Sie mit dem Credential Manager Ihre Passkey-Implementierung verbessern und zu einer passwortlosen Welt übergehen können.

Weitere Informationen zum Credential Manager und zu Passkeys sowie Zugriff auf unsere Beispiel-Apps finden Sie in unseren Ressourcen.

Als Nächstes haben wir die bevorstehende Anforderung für die Anmeldung ohne Tippen für Ihre Apps behandelt, mit der sich Nutzer beim Einrichten eines neuen Geräts nahtlos anmelden können.

Ab April 2027 ist dies im Google Play Store Pflicht. Bitte merkt euch diesen Termin vor.

Abschließend haben wir uns angesehen, wie digitale Ausweise funktionieren und welche nützlichen Funktionen sie auf Android-Geräten bieten.

Weitere Informationen zu digitalen Berechtigungsnachweisen und Zugriff auf unsere Beispiele finden Sie in unseren Ressourcen zu digitalen Berechtigungsnachweisen.

Alles, was wir heute vorgestellt haben, ist bereits verfügbar und kann von Ihnen genutzt werden.

Die Zukunft der Identität auf Android ist da und sie ist spannender denn je.

Vielen Dank für Ihre Zeit. Ich weiß, dass es Mittagszeit ist, also genießen Sie bitte das Essen draußen.

Und scheuen Sie sich nicht, mich oder Tom mit Fragen zu Passkeys oder digitalen Anmeldedaten anzusprechen.

Viele Grüße