Удобный вход и цифровые удостоверения на Android

Здравствуйте!

Спасибо, что присоединились.

Сегодня мы поговорим о будущем аутентификации и цифровой идентификации.

Меня зовут Том Колвин.

Я технический директор Apptaura и эксперт по технологиям Google в области Android. Со мной Чипин Йе, старший инженер по связям с разработчиками Android в Google.

Пароли уходят в прошлое.

По крайней мере, так должно быть.

Сегодня я расскажу вам о мире без паролей.

Пароли – это известная уязвимость в нашей инфраструктуре безопасности.

Даже если они хранятся в безопасном месте, они уязвимы для фишинга, взлома серверов и автоматических атак, таких как подстановка учетных данных.

В отрасли пытались решить эту проблему, усложняя пароли: добавляя специальные символы, цифры, обязательную смену.

Доказано, что это не работает, отчасти потому, что чем сложнее вы делаете задачу, тем больше вы, как ни парадоксально, поощряете небезопасное поведение.

Потому что сложный пароль, который регулярно меняется, скорее всего, будет записан на стикере.

И даже двухфакторная аутентификация на основе SMS оказалась уязвимой для перехвата, например, при замене SIM-карты.

Сегодня эта проблема в основном решена.

Ключи доступа созданы на основе стандартов FIDO и используют криптографию с открытым и закрытым ключами.

Они устойчивы к фишингу, не раскрываются при взломе сервера и напрямую связаны с безопасностью телефона пользователя через блокировку экрана, которая в большинстве случаев основана на биометрических данных, отпечатках пальцев и т. д. Ключи доступа активно улучшают пользовательский опыт благодаря унифицированному интерфейсу на разных платформах и отсутствию необходимости запоминать сложные пароли.

Наш манифест сегодня прост.

Пора переходить в мир без паролей.

И инструменты для этого уже у нас в руках.

В Android за это отвечает Менеджер учетных данных Jetpack.

Он поддерживается начиная с Android 4.4, а ключи доступа – с Android 9. Это единый унифицированный API, который поддерживает как ключи доступа, так и традиционную аутентификацию, например интегрированный вход с аккаунтом Google, а также резервный вход с паролем.

Вы вызываете Credential Manager API, и он обрабатывает интерфейс, чтобы выбрать, какой способ аутентификации хочет видеть пользователь.

Затем он выполняет тяжелую работу по возврату правильных учетных данных, полученных безопасным путем.

Она поддерживает вход, регистрацию и резервное копирование учетных данных.

Вы также можете использовать его для обновления и удаления учетных данных.

Она также позволяет пользователям переносить пароли и ключи доступа между поставщиками учетных данных всего за несколько кликов, без необходимости скачивать файлы.

Он разработан, чтобы дать пользователям полный контроль над своими данными и свободу менять поставщиков услуг, когда им это необходимо.

Менеджер учетных данных поддерживает множество типов устройств, включая часы, телевизоры, устройства расширенной реальности, автомобили, телефоны, складные устройства и планшеты.

И, что самое важное для нас, в нем есть специальный процесс для ключей доступа.

Вот как это выглядит для пользователя при регистрации.

Приложение сообщает Менеджеру учетных данных, что аутентификация с помощью ключа доступа доступна, и предоставляет ему сведения, полученные от серверной части.

Вы нажимаете "Зарегистрироваться", и Менеджер учетных данных показывает нижний экран с запросом на разблокировку экрана.

Чаще всего для этого используются биометрические данные, например отпечаток пальца или модель лица.

А Менеджер учетных данных выполняет сложную криптографическую работу, например создает ключ доступа.

и сохраняет ключ доступа в моем менеджере учетных данных. В данном случае это Google Менеджер паролей, но может быть и другой.

Вот как выглядит код:

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

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

Сначала мы создаем объект createPublicKeyCredentialRequest, используя данные, предоставленные серверной частью, то есть registerRequestJson.

Затем мы вызываем магический метод credentialManager.createCredential.

Мы передаем этот запрос и локальный контекст, что позволяет отобразить интерфейс.

Обратите внимание, что мне не пришлось писать код для интерфейса.

Менеджер учетных данных полностью берет это на себя.

Теперь перейдем к процессу входа.

Для пользователя это выглядит как процесс регистрации.

Вам нужно будет только разблокировать устройство.

Для разработчиков – лишь немного иначе.

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

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

Сначала мы получаем сведения о входе из серверной части, чтобы создать экземпляр GetPublicKeyCredential.

Мы сообщаем Менеджеру учетных данных, какие типы учетных данных поддерживаем.

Здесь только ключи доступа.

Но мы можем добавить и другие типы учетных данных, если захотим.

Затем мы вызываем credentialManager.getCredential, передавая список учетных данных, которые мы только что запросили.

Опять же, без кода пользовательского интерфейса.

Вам не нужно писать код для интерфейса.

Менеджер учетных данных полностью берет это на себя.

Она подталкивает пользователя к наиболее часто используемому варианту, оставляя другие доступными в качестве резервных.

Это автоматически решает одну из самых раздражающих проблем с аутентификацией.

Вы заметили?

Это запоминание того, какой метод я использовал в последний раз для входа.

Вот, ответ аккуратно представлен на нижнем экране.

Кстати, это не просто раздражает пользователя.

Это настоящая точка трения.

Это приводит к ненужным восстановлениям доступа к аккаунтам и имеет коммерческие последствия, такие как брошенные корзины.

Вот код моего демо-приложения, который вы можете использовать, чтобы самостоятельно попробовать Менеджер учетных данных.

Вы можете посмотреть эти процессы на своем устройстве.

А слева есть официальные примеры кода Google.

Это позволяет создавать ключи доступа.

Как перевести пользователей, которые входят по паролю, на ключи доступа?

Для этого есть мощный инструмент – условное создание.

Если пользователь только что вошел в систему с помощью пароля, который был автоматически подставлен поддерживаемым поставщиком учетных данных, мы знаем, что он активно взаимодействует с устройством, и мы только что подтвердили его личность.

В этом случае условное создание позволяет нам запросить создание ключа доступа автоматически в фоновом режиме.

Они не прерывают работу пользователя.

Ключ доступа генерируется и сохраняется в фоновом режиме.

Google Менеджер паролей покажет уведомление о создании ключа.

Другие менеджеры паролей могут работать иначе.

Код для условного создания очень похож на код для регистрации.

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

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

Параметр magic fla-- flag имеет значение isConditional true, поэтому пользователь не видит этот интерфейс.

Поскольку он работает оппортунистически, мы поместим его в блок try-catch.

Мы будем обрабатывать ошибки в фоновом режиме, чтобы не беспокоить пользователя, если процесс завершится неудачно.

Затем ключ доступа сохраняется в Менеджере учетных данных пользователя и будет доступен в следующий раз.

Менеджер учетных данных также позволяет поставщикам учетных данных безопасно импортировать и экспортировать их.

всего за несколько кликов.

Ничего скачивать не нужно.

Это обеспечивает большую гибкость, сохраняя при этом безопасность информации.

Вот как это выглядит.

В новом поставщике учетных данных пользователь запрашивает импорт учетных данных.

Затем Менеджер учетных данных открывает интерфейс импорта, в котором пользователь может выбрать источник данных.

Поставщик учетных данных, из которого выполняется экспорт, может предоставить собственный интерфейс, чтобы показать пользователю инструкции и предупреждения.

Наконец, данные передаются новому поставщику учетных данных пользователя по защищенному каналу.

Поэтому он может импортировать его без какого-либо взаимодействия с пользователем.

Но что произойдет, если пользователь отзовет ключ доступа из приложения или с сайта?

Поставщик учетных данных может не знать об этом.

При следующей попытке входа Менеджер учетных данных предложит недействительный ключ доступа, и пользователь получит отказ.

Аналогично, когда пользователь обновляет свое имя пользователя или отображаемое название, требуется синхронизация.

Теперь с помощью Signal API ваше приложение может сообщать поставщику учетных данных о таких состояниях.

Рассмотрим пример со входом в систему с помощью отозванного пароля.

Приложение может перехватить это состояние ошибки и сообщить о нем поставщику учетных данных пользователя.

После этого поставщик учетных данных может обновить свои данные, чтобы этот ключ доступа больше не предлагался.

Это некоторые из функций Менеджера учетных данных, и он невероятно полезен для того, чтобы пользователи регистрировались с помощью ключей доступа и отдавали приоритет ключам доступа перед другими методами при входе в систему.

Но помните, что наша конечная цель – полностью отказаться от паролей.

Как Менеджер учетных данных помогает достичь этой цели?

Вот предлагаемый нами пятиэтапный процесс.

На первых двух этапах вы переводите пользователей, которые входят в аккаунт с помощью пароля, на ключи доступа.

Сначала мы пробуем условное создание.

Если такой возможности не представится, нам потребуется вмешательство пользователя, поэтому мы будем предлагать ему настроить ключ доступа в приложении.

Мы можем постепенно начать показывать их все более и более заметно.

Ведь с точки зрения пользователя, ему обычно нужно только разблокировать экран, например с помощью биометрии.

Когда аналитика покажет, что подавляющее большинство пользователей используют ключи доступа, вы сможете сделать их обязательными для всех новых пользователей.

Но эти старые пользователи, это то, с кем мы имеем дело на этих последних трех шагах.

Мы рекомендуем пользователям ключей доступа удалить свои пароли.

Поэтому на третьем этапе мы разрешаем им сделать это вручную, используя очень понятную опцию «Удалить пароль» в настройках аккаунта.

На четвертом шаге мы начинаем подталкивать пользователей к удалению паролей, например с помощью уведомлений в приложении и обучающих материалов.

И наконец, вы меняете настройки удаления паролей с согласия на отказ.

В конечном итоге даже эта последняя возможность отказаться может исчезнуть.

Аналитика поможет нам уверенно удалить из приложения все процессы, связанные с паролями.

Поэтому переход на беспарольный доступ – это уже не теоретическая концепция безопасности, которая будет реализована когда-нибудь в будущем.

Она очень популярна.

API надежны, а пользовательский интерфейс превосходен.

Рекомендуем начать интеграцию ключей доступа с Менеджером учетных данных уже сегодня.

Начните переводить пользователей на ключи доступа, чтобы наконец оставить пароли в прошлом.

Спасибо!

А теперь я передаю слово Чипину, который расскажет о следующем этапе развития переноса устройств и идентификации.

то идем дальше.

Хорошо, спасибо, Том.

Как подчеркнул Том, бесперебойная аутентификация на устройствах пользователей имеет решающее значение.

Но что происходит, когда пользователь покупает новый телефон?

Самый большой спад на пути пользователя сегодня часто происходит при переключении устройств.

Сегодня я хочу рассказать о том, как мы решаем эту проблему, и кратко затронуть предстоящее требование Google Play, касающееся восстановления учетных данных.

С апреля 2027 года приложения в Google Play должны будут соответствовать требованиям к входу без нажатий. В противном случае у разработчиков не будет возможности публиковать новые версии, а видимость приложений в Google Play снизится.

Что такое вход без нажатий?

Это означает, что пользователям не нужно вручную проходить повторную аутентификацию в приложении при переходе на новое устройство.

Как это реализовать?

Рекомендуем использовать для этого Android Restore Credentials API через Менеджер учетных данных.

Этот API позволяет генерировать ключ восстановления, который сохраняется на устройстве пользователя или в облаке в зависимости от настроек резервного копирования.

Рекомендуем генерировать этот ключ в фоновом режиме после входа пользователя в аккаунт.

На этой диаграмме показано, как пользователь входит в приложение.

Затем, когда пользователь работает с приложением, создается ключ восстановления.

Этот ключ хранится локально или, если включено, удаленно в облаке.

Когда пользователь настраивает новое устройство, учетные данные для восстановления автоматически переносятся в фоновом режиме.

Пользователи могут восстановить данные из облака или перенести их с одного устройства на другое.

Затем, когда приложение будет открыто, вы сможете вызвать API Менеджера учетных данных, чтобы использовать этот ключ восстановления для входа пользователя на новом устройстве при первом запуске.

Это позволяет пользователю быстро и безопасно войти в ваше приложение.

Если вы хотите, чтобы приложение восстанавливалось сразу после настройки, не дожидаясь запуска, вы можете реализовать собственный агент резервного копирования.

Это позволит пользователю войти в приложение, не открывая его вручную.

Некоторые из наших партнеров уже реализовали это в своих приложениях.

Uber – крупнейшая в мире компания по совместным поездкам, которая предоставляет транспортные услуги миллионам людей, а также поддерживает доставку еды, медицинские перевозки и грузовую логистику.

Простота доступа имеет решающее значение.

При переходе на новое устройство пользователи ожидают, что им не придется заново входить в приложение Uber или каждый раз проходить одноразовую аутентификацию по SMS.

Частая смена устройств усложняет удержание пользователей.

Оценив спрос пользователей и создав прототип кода, компания Uber добавила поддержку ключей восстановления в приложение Uber Rider. Результаты оказались очень хорошими.

По оценкам компании, это позволит сэкономить 4 миллиона входов в систему в день, и ожидается, что это число будет расти по мере расширения внедрения.

Чтобы узнать больше о новых правилах и о том, как обеспечить соответствие приложения требованиям к восстановлению без нажатия, отсканируйте QR-код или перейдите по ссылке.

Напоминаем, что это произойдет в апреле 2027 года.

Если вы хотите начать внедрять Restore Credentials в свое приложение, отсканируйте QR-код или перейдите по ссылке, чтобы получить доступ к навыку Restore Credentials.

Этот навык можно использовать для быстрой разработки или тестирования функции с выбранным агентом.

Теперь давайте заглянем в будущее цифровой идентификации: Digital Credentials API в Менеджере учетных данных.

Давайте разберем, что такое цифровые удостоверения и как они работают.

Цифровые удостоверения – это цифровые документы, которые можно проверить с помощью криптографии. Пользователи могут предоставлять их, чтобы подтвердить информацию о себе.

Эти документы хранятся в цифровых кошельках на устройстве пользователя и могут запрашиваться другими приложениями на устройстве или предъявляться в гибридном формате, например с помощью QR-кода.

Их можно использовать для самых разных целей, от подтверждения личности до доступа к сервисам и покупок в интернете.

Цифровые удостоверения – это безопасный и удобный способ делиться информацией без физических карт.

В работе с цифровыми удостоверениями личности участвуют три стороны: эмитент, владелец и проверяющий.

Жизненный цикл цифрового удостоверения обычно идет слева направо.

Давайте рассмотрим каждый из этих объектов и их роль.

Первая сторона – это эмитент, то есть тот, кто выдает удостоверение. Например, паспорт выдает государство.

Однако в цифровом мире, чтобы предотвратить спуфинг, эти учетные данные также подписываются эмитентом с помощью его цифрового сертификата, поэтому любой, кто получает учетные данные, может точно знать, от кого они.

Эмитентом может быть кто угодно, например фитнес-клуб, отель или даже вы сами.

Вам нужно только создать учетные данные и подписать их.

Итак, эмитент создает и выдает учетные данные, но их нужно где-то хранить, так же как вам нужно хранить свое удостоверение личности в собственном кошельке.

Это следующая сторона, которая называется держателем и обычно представляет собой электронный кошелек.

Владельцы, как следует из названия, в основном хранят учетные данные, выданные эмитентами.

Они хранятся в приложении на устройстве, и их можно предъявлять по запросу.

Как и эмитентом, держателем может быть кто угодно.

На самом деле, нередко эмитентом и держателем управляет одна и та же организация.

Например, фитнес-клуб хочет создать цифровой абонемент и управлять им через собственное приложение.

То есть вы будете одновременно и эмитентом, и держателем.

Хорошо, третья сторона – это верификатор или сторона, которая запрашивает цифровые учетные данные.

Проверяющие запрашивают учетные данные, чтобы проверить атрибуты пользователя, например возрастные ограничения, фамилию и т. д.

Это компании или приложения, которым для предоставления услуги, например продажи алкоголя или проверки минимального возраста, требуются дополнительные пользовательские данные.

На устройствах Android взаимодействие между этими тремя сторонами и пользователем координируется через Менеджер учетных данных с помощью Digital Credentials API.

Эмитент может вызвать API, чтобы выдать учетные данные держателю, хотя это необязательно, если они являются одним и тем же лицом.

После выпуска удостоверения проверяющий может вызвать API, чтобы запросить его.

Менеджер учетных данных сопоставляет запрос со всеми доступными держателями и предлагает пользователю выбрать учетные данные и дать согласие.

После выбора держателя он вызывается и может выполнить дополнительные проверки, прежде чем передать удостоверение проверяющему.

Получив удостоверение, проверяющий может выполнить различные проверки его подлинности, в том числе проверить исходного издателя.

Возможно, вы задаетесь вопросом, как именно обеспечивается безопасность цифровых сертификатов.

На самом деле безопасность обеспечивается на каждом этапе процесса, и сейчас мы рассмотрим некоторые из них.

Когда эмитент хочет передать учетные данные держателю, он должен убедиться, что держатель не может быть подделан или скопирован, то есть ему можно доверять.

Как это можно проверить?

Прежде чем выпустить удостоверение, эмитент должен убедиться в личности владельца и безопасности устройства, на котором оно будет использоваться.

Держатель отправляет подтверждение кошелька, обычно в виде проверяемой цепочки сертификатов.

Держатель также генерирует пару ключей с аппаратной защитой.

Оно отправляет эмитенту открытый ключ из этой пары ключей с аттестацией ключа Android, чтобы эмитент мог проверить подлинность оборудования.

Эмитент подпишет этот открытый ключ в выданных учетных данных, чтобы они были официально привязаны к одному устройству.

После получения новых учетных данных держатель регистрирует в Менеджере учетных данных только их метаданные.

Менеджер учетных данных использует эти метаданные, чтобы определить, какие держатели показывать, когда верификатор запрашивает учетные данные.

Реальные пользовательские данные не регистрируются в Менеджере учетных данных и не передаются Google.

Даже когда Менеджер учетных данных выбирает кошельки, которые будут показаны пользователю, их содержимое не раскрывается.

Теперь, когда поступает запрос на учетные данные и пользователь соглашается предоставить их, вызывается выбранный держатель и управление рабочим процессом передается ему.

Как вы помните, держатель – это просто приложение, поэтому вызывается приложение.

В этот момент держатель может видеть, например, запрашивающего верификатора и запрашиваемые учетные данные, и может решить, хочет ли он поделиться этими учетными данными с этим верификатором, даже если пользователь уже дал разрешение.

У Google нет доступа к самим учетным данным.

Регистрируются только метаданные маршрутизации, а полезная нагрузка шифруется сквозным шифрованием между держателем и проверяющим.

Это позволяет владельцу контролировать, с кем он делится своими учетными данными.

Наконец, после того как проверяющий запросит удостоверение, а владелец поделится им, проверяющий получит удостоверение от владельца.

Теперь проверяющий может убедиться, что ответ был только что сгенерирован исходным владельцем учетных данных для запроса.

Она может подтвердить, что ответ на запрос учетных данных подписан с помощью ключа, привязанного к устройству владельца, в том числе запросить одноразовый токен и вызвать источник, наблюдаемый владельцем.

Проверяющий также может убедиться в подлинности издателя удостоверения, проверив его сертификат и убедившись, что он получен из надежного источника.

Если коротко, то эмитенты получают аппаратные гарантии, держатели могут выбирать, какими удостоверениями делиться, а проверяющие – криптографическое подтверждение эмитента и держателя. При этом пользователи полностью контролируют, какими данными делиться.

Теперь, когда мы рассказали о безопасности цифровых удостоверений, давайте рассмотрим некоторые варианты их использования, доступные сегодня через Digital Credentials API на Android.

Первый из них, который я собираюсь рассмотреть, называется подтверждением адреса электронной почты.

Этот API берет адрес Gmail, с которым пользователь вошел в аккаунт на устройстве, и передает его в ваше приложение как цифровое удостоверение, подтвержденное Google. Благодаря этому вам не нужно отправлять одноразовые коды или ссылки для входа.

Это значит, что пользователю не нужно покидать приложение. Достаточно один раз нажать на знакомый нижний экран Менеджера учетных данных.

Вот демонстрационная запись работы API.

Это пример приложения, в котором реализовано подтверждение адреса электронной почты с помощью Digital Credentials API.

Когда я нажимаю "Запросить подтвержденный адрес электронной почты", Менеджер учетных данных запрашивает цифровое удостоверение с подтвержденным адресом электронной почты у держателей на устройстве, у которых есть удостоверение такого типа.

В этом случае только Google является держателем этих учетных данных, которые вы видите на нижнем экране.

Это один из адресов электронной почты, с помощью которых пользователь вошел в аккаунт на устройстве.

И, по сути, Google является и эмитентом, и держателем цифровых учётных данных в этом случае.

После того как я выберу учетные данные, которыми хочу поделиться, они будут возвращены в приложение, которое в настоящее время просто отображает поля, содержащиеся в учетных данных, то есть подтвержденный адрес электронной почты.

В приложении вы можете использовать эту информацию, чтобы перейти к следующему экрану, например к созданию ключа доступа или другим шагам по созданию аккаунта.

Для пользователя это действительно так же просто, как дать согласие и перейти к следующему экрану.

Если вы хотите попробовать эту функцию, перейдите к нашему примеру на GitHub и установите его на свое устройство.

Попробуйте использовать его на физическом устройстве. Обратите внимание, что на устройстве нужно войти хотя бы в один аккаунт Gmail.

Поэтому я дам немного больше времени, если люди заинтересованы.

Теперь

Звучит захватывающе, не так ли?

А когда вы думаете о подтверждении адреса электронной почты, какая следующая форма подтверждения пользователя приходит на ум?

Правильно, подтверждение номера телефона.

Digital Credentials API также поддерживает подтверждение номера телефона, что позволяет избежать сложностей и уязвимостей, связанных с одноразовыми кодами в SMS.

Подтверждение номера телефона также выполняется через Digital Credentials API. В этом случае номер телефона на устройстве запрашивается и предоставляется как цифровое удостоверение личности.

Пользователь видит только знакомый нижний экран Менеджера учетных данных, где можно подтвердить номер телефона или поделиться им. При этом не нужно выходить из приложения, а для подтверждения достаточно нескольких нажатий.

На этом примере показано, как клиент может поделиться своим номером телефона одним нажатием, не выходя из приложения.

Как это работает?

Если сопоставить это с участниками процесса цифровой идентификации, то издателем в данном случае является оператор связи, которому принадлежит номер телефона на SIM-карте устройства, а держателем – Android Telephony.

Когда верификатор, например ваше приложение, запрашивает номер телефона пользователя, он извлекается из Google Telephony с помощью вызова Digital Credentials API.

Возможно, вы хотите узнать, как происходит оплата.

В этом случае есть дополнительный шаг, когда учетные данные передаются оператору или агрегатору для выставления счета.

Это происходит после того, как номер телефона извлекается из Google Telephony, где он хранится в зашифрованном виде.

Затем он передается оператору, который расшифровывает его и возвращает номер телефона непосредственно в серверную часть вашего приложения. В этот момент с вас списывается плата.

Оператор будет взимать плату только за успешные проверки, которые выполняются через мобильный интернет или Wi-Fi и гораздо надежнее, чем SMS.

Вот пример подтверждения номера телефона с помощью Firebase в качестве агрегатора операторов связи.

Приложение запрашивает номер телефона пользователя в процессе входа.

У пользователя несколько SIM-карт, и он выбирает одну из них, чтобы предоставить доступ приложению.

После того как пользователь подтвердит свой выбор, обмен произойдет в фоновом режиме.

Затем вы увидите следующий экран с полученным номером телефона.

Пользователю не пришлось выходить из приложения, а только выбрать и подтвердить номер телефона, чтобы продолжить процесс. Все это заняло несколько нажатий.

Просто позвольте этому закончиться, чтобы вы могли увидеть завершение ещё раз.

И вы видите номер телефона на этом последнем экране.

нужно будет

Сегодня мы обсудили много вопросов.

Сначала мы рассмотрели, как использовать Менеджер учетных данных, чтобы улучшить реализацию ключей доступа и перейти к миру без паролей.

Чтобы узнать больше и получить доступ к примерам приложений, ознакомьтесь с нашими ресурсами о Менеджере учетных данных и ключах доступа.

Затем мы рассказали о новом требовании к приложениям – входе без касания. Он упрощает вход в аккаунт при настройке нового устройства.

Это требование станет обязательным в Google Play с апреля 2027 года.

Наконец, мы рассмотрели, как работают цифровые удостоверения и некоторые из их наиболее полезных функций на Android.

Чтобы узнать больше о цифровых удостоверениях и посмотреть примеры, изучите наши ресурсы.

Все, о чем мы сегодня рассказали, уже доступно для использования.

Будущее идентификации на Android уже наступило, и оно выглядит многообещающе.

Спасибо за внимание. Сейчас время обеда, поэтому угощайтесь едой, которая ждет вас снаружи.

И не стесняйтесь обращаться ко мне или к Тому с вопросами о ключах доступа или цифровых удостоверениях.

Ура!