Android でのシームレスなログインとデジタル認証情報の提供

皆さん、こんにちは。

本日はご参加いただきありがとうございます。

本日は、認証とデジタル ID の未来についてお話しします。

私は Tom Colvin です。

私は Apptaura の CTO で、Android の GDE です。今回は、Google のシニア Android デベロッパー リレーションズ エンジニアである Chiping Yeh も参加しています。

古くから使われてきたパスワードは、もはや時代遅れです。

少なくとも、そうあるべきです。

本日は、パスワードレスの世界についてお話しします。

パスワードは、セキュリティ インフラストラクチャにおけるよく知られた脆弱性です。

安全に保管されていても、フィッシング、サーバー侵害、クレデンシャル スタッフィングなどの自動攻撃に対して脆弱です。

業界としては、特殊文字、数字、強制的なローテーションなど、複雑さを強制することでこれに対処しようとしてきました。

しかし、この方法は失敗に終わっています。その理由の一つは、パスワードを複雑にすればするほど、逆説的に、安全でない行動を助長することになるからです。

定期的に変更される複雑なパスワードは、付箋に書き留められる可能性が高いためです。

また、SMS ベースの 2 要素認証であっても、SIM スワッピングなどの傍受に対して脆弱であることが証明されています。

しかし、現在ではこの問題はほぼ解決されています。

パスキーは FIDO 標準に基づいて構築されており、公開鍵 / 秘密鍵暗号を使用します。

フィッシングに強く、サーバー侵害で漏洩することもなく、画面ロックを介してユーザーのスマートフォンのセキュリティに直接結びついています。画面ロックは、ほとんどの場合、生体認証や指紋認証などに基づいています。また、プラットフォーム間で統一されたエクスペリエンスを提供し、複雑なパスワードを覚える必要がないため、ユーザー エクスペリエンスが積極的に向上します。

私たちのマニフェストはシンプルです。

パスワードレスの世界に移行する時が来ました。

そして、それを実現するためのツールはすでに手元にあります。

Android でこの移行を実現する中心となるのが、Jetpack 認証情報マネージャーです。

Android 4.4 までさかのぼってサポートされており、Android 9 以降ではパスキーがサポートされています。パスキーだけでなく、フェデレーション ログイン（Google でログインなど）のような従来の認証もサポートする単一の統合 API を提供し、必要に応じてパスワードへのグレースフル フォールバックも含まれています。

Credential Manager API を呼び出すと、ユーザーが希望する認証方法を選択するための UI が処理されます。

その後、安全に取得された正しい認証情報を返すという、面倒な処理を行います。

ログイン、登録、認証情報のバックアップをサポートしています。

また、認証情報の更新と削除にも使用できます。

また、ユーザーは数回クリックするだけで、認証情報プロバイダ間でパスワードとパスキーを移動できます。ファイルのダウンロードは必要ありません。

ユーザーが自分のデータを完全に管理し、必要に応じていつでもプロバイダを切り替えられるように設計されています。

認証情報マネージャーは、スマートウォッチ、テレビ、XR、自動車、スマートフォン、折りたたみ式デバイス、タブレットなど、多くのフォーム ファクタをサポートしています。

そして、Google にとって最も重要なのは、パスキー専用のフローがあることです。

登録時にユーザーに表示される画面は次のとおりです。

アプリは、パスキー認証が利用可能であることを認証情報マネージャーに伝え、バックエンドから収集した詳細情報を提供します。

[Register] をタップすると、認証情報マネージャーから画面ロックのプロンプトを含むボトムシートが表示されます。

これは通常、指紋認証や顔認証などの生体認証でロック解除されます。

認証情報マネージャーは、パスキーの実際の作成など、複雑な暗号化作業を処理します。

そして、パスキーが認証情報マネージャーに保存されます。この場合は Google パスワード マネージャーですが、別のマネージャーでも構いません。

コードは次のようになります。

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

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

まず、バックエンドが提供する詳細（registerRequestJson）を使用して、この createPublicKeyCredentialRequest オブジェクトを作成します。

次に、マジック メソッド credentialManager.createCredential を呼び出します。

このリクエストとローカル コンテキストを渡すことで、UI を表示できます。

なお、ここでは UI コードを記述する必要はありません。

認証情報マネージャーがすべて処理してくれます。

これはログイン プロセスです。

ユーザーにとっては、登録プロセスと非常によく似ています。

ロック解除のプロンプトが 1 つ表示されるだけで、完了です。

デベロッパーにとっては、わずかな違いしかありません。

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

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

まず、バックエンドからログインの詳細を取得して、GetPublicKeyCredential インスタンスをビルドします。

サポートする認証情報の種類を認証情報マネージャーに伝えます。

ここではパスキーのみです。

ただし、必要に応じて他のタイプの認証情報を追加することもできます。

次に、リクエストした認証情報のリストを渡して credentialManager.getCredential を呼び出します。

ここでも、UI コードはありません。

UI コードを記述する必要はありません。

認証情報マネージャーがすべて処理してくれます。

最も頻繁に使用されるオプションをユーザーに提案し、他のオプションはバックアップとして利用できるようにします。

これにより、昨今の最も厄介な認証問題の 1 つが自動的に解決されます。

お気づきになりましたか？

これは、最後にログインに使用した方法を記憶するものです。

ボトムシートに回答がわかりやすく表示されています。

これは、ユーザーにとって不便なだけではありません。

これは、真の摩擦点です。

不要なアカウント復元が発生し、ショッピング カートの放棄など、商業的な影響が生じます。

以下は、認証情報マネージャーを自分で試すために使用できるデモ アプリケーション コードです。

これらのフローは、ご自身のデバイスで確認できます。

左側には、公式の Google コードサンプルがあります。

パスキーの作成を処理します。

既存のパスワード ユーザーをパスキーにアップグレードするにはどうすればよいですか？

そのための強力なツールが条件付き作成です。

ユーザーがパスワードを使用してログインしたばかりで、サポートされている認証情報プロバイダによって自動入力されている場合は、ユーザーが積極的に関与しており、本人確認が完了していることがわかります。

その場合、条件付き作成を使用すると、バックグラウンドでパスキーの作成を自動的にリクエストできます。

ユーザーのワークフローを中断することはありません。

パスキーはバックグラウンドで生成され、保存されます。

Google パスワード マネージャーに、パスキーが作成されたことを確認する通知が表示されます。

他のパスワード マネージャーでは、異なる場合があります。

条件付き作成のコードは、登録のコードとよく似ています。

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

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

マジックフラグは isConditional true で、ユーザーにその UI が表示されないようにします。

また、この処理は状況に応じて行われるため、try-catch ブロックに配置します。

エラーはサイレントで処理されるため、プロセスが失敗してもユーザーに通知されることはありません。

パスキーはユーザーの認証情報マネージャーに保存され、次回から使用できるようになります。

認証情報マネージャーを使用すると、認証情報プロバイダは認証情報を安全にインポートおよびエクスポートすることもできます。

数回クリックするだけです。

ダウンロードは不要です。

これにより、情報の安全性を維持しながら、柔軟性を高めることができます。

フローは次のようになります。

ユーザーは、新しい認証情報プロバイダで認証情報のインポートをリクエストします。

次に、認証情報マネージャーがインポート UI を処理し、ユーザーが認証情報データのソースを選択できるようにします。

エクスポート元の認証情報プロバイダは、独自の UI を提供して、ユーザーに説明し、関連する警告を表示できます。

最後に、ユーザーの新しい認証情報プロバイダに、安全なチャネルを介してデータが提供されます。

そのため、ユーザーの操作なしでインポートできます。

しかし、ユーザーがアプリやウェブサイトからパスキーを取り消した場合はどうなるでしょうか。

この場合、認証情報プロバイダは、そのことが発生したことを必ずしも認識しているわけではありません。

次回ログインしようとすると、認証情報マネージャーがその無効なパスキーを提示し、ログインは拒否されます。

同様に、ユーザーがユーザー名または表示名を更新した場合も、同期が必要です。

Signal API を使用すると、アプリはこれらの特定の状態を認証情報プロバイダに通知できます。

取り消されたパスワードでログインする場合を例に考えてみましょう。

アプリはこの特定のエラー状態をキャッチして、ユーザーの認証情報プロバイダに通知できます。

認証情報プロバイダは、その特定のパスキーが提供されないように自身を更新できます。

これらは認証情報マネージャーの機能の一部であり、ユーザーがパスキーを使用して登録する際や、ログイン時に他の方法よりもパスキーを優先する際に非常に役立ちます。

ただし、ここでの最終的な目標は、完全にパスワードレスにすることです。

認証情報マネージャーは、この目標の達成にどのように役立ちますか。

Google が提案する 5 つのステップは次のとおりです。

最初の 2 つのステップでは、パスワードを使用しているユーザーをパスキーにアップグレードします。

まず、条件付き作成を使用して、オポチュニスティックに試行します。

そのような機会がなかった場合は、最終的にユーザーの介入が必要になるため、アプリ内招待でユーザーにパスキーの設定を依頼します。

これらの情報を徐々に目立つように表示していくことができます。

結局のところ、ユーザーの観点からは、通常は生体認証などの画面ロックを提供するだけで済みます。

アナリティクスで、ユーザーの大多数がパスキーを使用するアカウントを持っていることが示されたら、すべての新規ユーザーにパスキーを義務付けることができます。

しかし、古いユーザーは、最後の 3 つのステップで対処します。

パスキーを使用しているユーザーには、パスワードを削除することをおすすめします。

そのため、ステップ 3 では、アカウント設定に [パスワードを削除] オプションを明確に表示し、ユーザーが手動で削除できるようにしています。

ステップ 4 では、パスワードの削除を促します。たとえば、アプリ内通知と教育的なコピーを組み合わせて使用します。

最後に、パスワードの削除をオプトインからオプトアウトに切り替えます。

最終的には、その最後のオプトアウトも消える可能性があります。

アナリティクスのおかげで、アプリからパスワード フローを完全に削除する自信が持てました。

したがって、パスワードレスの世界への移行は、もはや将来の理論的なセキュリティ コンセプトではありません。

サポートが充実している。

API は堅牢で、ユーザー エクスペリエンスは優れています。

ぜひ、今すぐ認証情報マネージャーでパスキーフローの統合を始めてください。

ユーザーのアップグレードを開始して、パスワードを過去のものにしましょう。

ありがとうございました

それでは、Chiping にバトンタッチして、デバイスの移行と ID の次の進化について説明してもらいます。

いいですね

Tom、ありがとうございました。

Tom が強調したように、ユーザー デバイスでのシームレスな認証は重要です。

しかし、お客様が新しいスマートフォンに機種変更した場合はどうなりますか？

現在、ユーザー ジャーニーで最も大きな離脱が発生するのは、ユーザーがデバイスを切り替えるときです。

本日は、まずこの問題の解決方法について説明し、次に、認証情報の復元に関する Google Play ストアの今後の要件について簡単に説明します。

2027 年 4 月より、Google Play でアプリの完全な公開機能と最適な表示を維持するには、ゼロタップ ログインの要件を満たす必要があります。

ゼロタップ ログインとは

つまり、ユーザーは新しいデバイスに移行する際に、アプリで手動で再認証する必要がなくなります。

これを実装するにはどうすればよいでしょうか。

この処理を行う方法として推奨されるのは、認証情報マネージャーを介して Android の Restore Credentials API を使用することです。

この API を使用すると、復元キーと呼ばれるものを生成できます。これは、ユーザーのバックアップ設定に基づいて、ユーザーのデバイスまたはクラウドに保存されます。

この鍵は、ユーザーがログインした後にバックグラウンドで生成することをおすすめします。

この図は、ユーザーがアプリにログインする様子を示しています。

その後、ユーザーがアプリを使用しているときに、復元キーが作成されます。

この鍵はローカルに保存されるか、有効になっている場合はクラウドにリモートで保存されます。

ユーザーが新しいデバイスをセットアップすると、デバイスのセットアップ プロセス中に、復元認証情報がバックグラウンドで自動的に転送されます。

ユーザーは、クラウドからのデータ復元またはデバイス間転送を選択できます。

その後、アプリが開かれたときに、Credential Manager API を呼び出してこの復元キーを使用し、新しいデバイスでの初回起動時にユーザーをログインさせることができます。

これにより、ユーザーはアプリにすぐに、迅速かつ安全にログインできます。

また、セットアップ後にアプリを開かずにすぐに復元する場合は、カスタム バックアップ エージェントを実装することで実現できます。

これにより、ユーザーはアプリを手動で開かなくてもアプリにログインできるようになります。

一部のパートナーは、すでにこの機能をアプリに実装しています。

Uber は世界最大のライドシェアリング企業であり、何百万人もの人々に交通手段を提供するとともに、フード デリバリー、医療輸送、貨物物流もサポートしています。

アクセスのシンプルさは重要です。

また、ユーザーが新しいデバイスに切り替える際には、Uber アプリに再度ログインしたり、SMS ベースのワンタイム認証を毎回行ったりすることなく、シームレスに移行できることを期待しています。

この頻繁なデバイスの入れ替えは、ユーザー維持率の課題となっています。

ユーザーの需要を評価し、コードのプロトタイプを作成した後、Uber は Uber Rider アプリに Restore Credentials のサポートを導入しました。その結果は非常に良好でした。

これにより、1 日あたりの平均ログイン数が 400 万回削減されると推定されており、導入が進むにつれてこの数はさらに増加すると予想されています。

このポリシーと、アプリがゼロタップ復元の要件を満たす方法について詳しくは、この QR コードとリンクをご覧ください。

この変更は 2027 年 4 月に予定されています。カレンダーに登録して、忘れずにご対応ください。

アプリに Restore Credentials を実装する準備を始めたい場合は、こちらの QR コードとリンクから Restore Credentials のスキルにアクセスしてください。

このスキルを使用すると、選択したエージェントで機能を迅速に開発またはテストできます。

次に、デジタル ID の新たなフロンティアである、認証情報マネージャーを介した Digital Credentials API について見ていきましょう。

デジタル認証情報とは何か、その仕組みについて説明します。

デジタル認証情報とは、ユーザーが自分に関する情報を提供するために使用できる、暗号で検証可能なデジタル ドキュメントです。

これらのドキュメントは、ユーザーのデバイス上のデジタル ホルダーに保存され、デバイス上の他のアプリからリクエストしたり、QR コードなどを介してハイブリッドな方法で提示したりできます。

本人確認からサービスへのアクセス、オンラインでの商品購入まで、用途は多岐にわたります。

デジタル認証情報を使用すると、物理的なカードを必要とせずに、安全かつ便利に情報を共有できます。

デジタル認証情報には、発行者、保有者、検証者の 3 者が関与します。

デジタル認証情報のライフサイクルは、一般的に左から右に流れます。

これらのエンティティと、それぞれの役割について説明します。

1 つ目は発行者です。その名のとおり、認証情報を発行する当事者です。たとえば、政府がパスポートを発行するようなものです。

ただし、デジタルの世界では、なりすましを防ぐために、これらの認証情報には発行者のデジタル証明書も署名されています。そのため、認証情報を受け取った人は誰でも、それが誰からのものかを正確に知ることができます。

実際、ジム、ホテル、さらには個人でも、誰でも発行者になることができます。

認証情報を作成して署名するだけです。

発行者は認証情報を作成して発行しますが、政府機関発行の身分証明書を自分の財布に保管する必要があるように、認証情報もどこかに保管する必要があります。

次の当事者はホルダーと呼ばれ、一般的にはデジタル ウォレットとも呼ばれます。

ホルダーは、その名のとおり、主に発行者から発行された認証情報を保持します。

デバイス上のアプリとして保存され、リクエスト元に提示できます。

発行者と同様に、誰でも保有者になることができます。

実際、発行者と保有者が同じエンティティによって管理されることは珍しくありません。

たとえば、独自のデジタル メンバーシップ認証情報を作成し、独自のアプリで管理したいと考えているジムを考えてみましょう。

これは、発行者と保有者の両方を兼ね備えたものです。

3 つ目は、検証者、つまりデジタル認証情報をリクエストする当事者です。

検証者は通常、年齢制限や姓などのユーザーの属性を確認するために認証情報リクエストを行います。

これらは、アルコールの購入や最低年齢の確認など、サービスを提供するために追加のユーザーデータを必要とするビジネスまたはアプリです。

Android では、これら 3 つの当事者とユーザーの間のやり取りは、認証情報マネージャーと Digital Credentials API を介して調整されます。

発行者は API を呼び出して、保有者に認証情報を発行できます。ただし、発行者と保有者が同じエンティティである場合は、この操作は不要です。

認証情報が発行されると、検証者は API を呼び出して認証情報をリクエストできます。

認証情報マネージャーは、リクエストを利用可能なすべてのホルダーと照合し、ユーザーに提示して認証情報の選択と同意を求めます。

ホルダーが選択されると、ホルダーが呼び出され、必要に応じて追加のチェックを行ってから、最終的に検証者と認証情報を共有できます。

検証者は、認証情報を受け取ると、元の発行者の確認など、認証情報の正当性に関するさまざまなチェックを行うこともできます。

デジタル認証情報のセキュリティはどのように確保されているのでしょうか。

実際には、プロセスの各ステップにセキュリティが組み込まれています。ここでは、その一部について説明します。

そのため、発行者側では、発行者が保有者と認証情報を共有したい場合、保有者が改ざんやコピーができないこと、つまり信頼できることを確認する必要があります。

これを検証するにはどうすればよいですか？

発行元が認証情報をリリースする前に、保有者は自身の ID と、操作しているデバイスのセキュリティを証明する必要があります。

ホルダーは、通常は検証可能な証明書チェーンとして、ウォレット証明書を送信します。

また、ホルダーはハードウェアにバインドされた鍵ペアを生成します。

この鍵ペアの公開鍵を、Android のキー構成証明とともにカード発行会社に送信します。これにより、カード発行会社はハードウェアの正当性を検証できます。

カード発行会社は、この公開鍵を発行された認証情報に署名します。これにより、認証情報は 1 台のデバイスに正式にバインドされます。

ホルダー側では、新しい認証情報を取得すると、その認証情報のメタデータのみを認証情報マネージャーに登録します。

認証情報マネージャーは、このメタデータを使用して、検証者が認証情報リクエストを行ったときに表示するホルダーを決定します。

実際のユーザーデータが認証情報マネージャーに登録されたり、Google に公開されたりすることはありません。

また、認証情報マネージャーがユーザーに表示するウォレットを選択しているときでも、各ウォレットの内容はその時点では公開されません。

認証情報リクエストが行われ、ユーザーの同意を得て認証情報が共有されると、選択されたホルダーが呼び出され、ワークフローの制御がホルダーに渡されます。

ご存じのとおり、ホルダーは単なるアプリであるため、アプリが呼び出されます。

この時点で、ホルダーはリクエスト元の検証者やリクエストされた認証情報などを確認し、ユーザーがすでに許可を与えている場合でも、その認証情報をその検証者と共有するかどうかを決定できます。

認証情報データ自体に Google がアクセスすることはできません。

登録されるのはルーティング メタデータのみで、ペイロードはホルダーと検証者の間でエンドツーエンドで暗号化されます。

これにより、保有者はクルデンシャルを共有する相手を管理できます。

最後に、検証者側では、認証情報がリクエストされ、ホルダーが認証情報を共有すると、検証者はホルダーから認証情報の提示を受け取ります。

これで、検証者は、リクエストに対して元の認証情報ホルダーによってレスポンスが新たに生成されたかどうかを確認できます。

ワンタイム トークンのリクエストや、ホルダーが確認した呼び出し元オリジンなど、ホルダーのデバイスにバインドされた鍵を使用して認証情報レスポンスが署名されていることを確認できます。

検証者は、発行者の証明書を検証して、信頼できるソースから発行されたものであることを確認することで、認証情報の発行者の真正性を確認することもできます。

つまり、発行者はハードウェアによる保証を受け、保有者は共有する認証情報を管理し、検証者は発行者と保有者の暗号証明を受け、ユーザーは共有するデータについて完全な同意を保持します。

デジタル認証情報のセキュリティについて説明したところで、Android の Digital Credentials API を通じて現在利用可能なデジタル認証情報のユースケースをいくつかご紹介します。

最初に取り上げるのは、メール確認です。

この API は、ユーザーがログインしている Gmail をデバイスから直接取得し、Google で検証済みのデジタル認証情報としてアプリに提示します。これにより、ワンタイム パスワードやマジックリンクを送信する必要がなくなります。

つまり、ユーザーはアプリを離れることなく、使い慣れた認証情報マネージャーのボトムシートを 1 回タップするだけで同意できます。

API の動作を録画したデモをご覧ください。

これは、Digital Credentials API を介してメール確認を実装するサンプルアプリです。

[Request verified email] をタップすると、認証情報マネージャーは、このタイプの認証情報を保持しているデバイス上のホルダーに、確認済みのメールのデジタル認証情報をリクエストします。

この場合、この確認済みメール認証情報の所有者は Google のみであり、ボトムシートに表示されます。

これは、ユーザーがデバイスでログインしているメールアドレスの 1 つです。

実際、この場合、Google はデジタル認証情報の発行者であり、保持者でもあります。

共有する認証情報を選択すると、アプリに返されます。アプリには、認証情報に含まれるフィールド（確認済みのメールアドレス）が表示されます。

アプリでは、この情報を使用して、パスキーの作成やその他のアカウント作成手順など、次のアプリ画面に進むことができます。

ユーザーにとっては、同意して次の画面に進むだけの簡単な操作です。

この機能を試すには、GitHub のサンプルに移動して、ご自身のデバイスにインストールしてください。

実機で試してみてください。なお、デバイスで少なくとも 1 つの Gmail アカウントにログインしている必要があります。

ご興味のある方のために、もう少し時間を取ります。

それでは

魅力的だと思いませんか？

メール確認の次に思い浮かぶユーザー確認の形式は何ですか？

そのとおりです。電話番号の確認です。

Digital Credentials API は電話番号の確認もネイティブにサポートしているため、SMS OTP の煩わしさや脆弱性を排除できます。

電話番号の確認も Digital Credentials API を通じて行われます。この場合、デバイスの電話番号がリクエストされ、デジタル認証情報として提示されます。

ユーザーには、電話番号の共有または確認を行うための、おなじみの認証情報マネージャーのボトムシートのみが表示されます。アプリを離れることなく、数回のタップで確認を完了できます。

この例では、ユーザーはアプリを離れることなく、1 回タップするだけで電話番号を共有できます。

では、この設定はどのように機能するのでしょうか。

これをデジタル認証情報の関係者にマッピングすると、この場合の発行者はデバイスの SIM カードに登録されている電話番号の携帯通信会社であり、保有者は Android Telephony です。

アプリなどの検証ツールがユーザーの電話番号をリクエストすると、Digital Credentials API 呼び出しによって Google Telephony から電話番号が取得されます。

請求の仕組みについて疑問に思われるかもしれません。

このフローに固有の追加の手順として、請求目的で認証情報が携帯通信会社またはアグリゲータに渡されます。

これは、電話番号が Google Telephony から取得された後に行われます。Google Telephony では、電話番号は暗号化された状態で保存されます。

このトークンは携帯通信会社に渡され、携帯通信会社はトークンを復号して電話番号をアプリのバックエンドに直接返します。この時点で課金されます。

この方法の優れた点は、携帯通信会社が課金するのは、データまたは Wi-Fi 経由で転送され、SMS よりもはるかに信頼性の高い、確認が成功した場合のみであることです。

ここでは、Firebase を携帯通信会社の集約サービスとして使用した、電話番号の確認のデモをご紹介します。

アプリがログイン プロセスの一環としてユーザーの電話番号をリクエストする。

このユーザーは複数の SIM カードを所有しており、アプリと共有する SIM カードを 1 つ選択します。

ユーザーが選択を確定すると、交換はすべてバックグラウンドで行われます。

その後、取得した電話番号が入力された次の画面が表示されます。

ユーザーはアプリを離れる必要がなく、共有する電話番号を選択して確認するだけで、数回のタップでスムーズにフローを進めることができました。

完了するまで待ちます。

最後の画面に電話番号が表示されます。

ユーザーはリンクをタップし このようなページに移動して参加するだけです

本日は非常に幅広い内容を取り上げました。

まず、認証情報マネージャーを使用してパスキーの実装を改善し、パスワードレスの世界に移行する方法について説明しました。

認証情報マネージャーとパスキーに関するリソースについては、こちらをご覧ください。詳細情報やサンプルアプリへのアクセス方法をご確認いただけます。

次に、アプリに今後適用されるゼロタップ ログインの要件について説明しました。これにより、ユーザーは新しいデバイスをセットアップする際にシームレスにログインできるようになります。

この要件は 2027 年 4 月までに Google Play ストアで義務付けられる予定ですので、ご留意ください。

最後に、デジタル認証情報の仕組みと、Android での最も便利な機能について説明しました。

コンテンツの詳細とサンプルへのアクセスについては、デジタル認証情報に関するリソースをご覧ください。

本日ご紹介した機能はすべて、今すぐご利用いただけます。

Android の ID の未来は、これまで以上にエキサイティングなものになっています。

お時間をいただきありがとうございました。ランチタイムですので、外で食事をお楽しみください。

パスキーやデジタル認証情報についてご質問がある場合は、私や Tom に遠慮なくお尋ねください。

ご検討のほどよろしくお願い申し上げます。