Menghadirkan login yang lancar dan kredensial digital di Android

Halo semuanya.

Terima kasih telah bergabung bersama kami hari ini.

Hari ini, kami ingin membahas masa depan autentikasi dan identitas digital.

Saya Tom Colvin.

Saya CTO Apptaura, dan saya GDE di Android, dan saya bergabung dengan Chiping Yeh, yang merupakan Engineer Developer Relations Android senior di Google.

Sandi yang sudah lama digunakan kini tidak lagi relevan.

Atau, setidaknya, seharusnya demikian.

Hari ini, kami akan membahas dunia tanpa sandi.

Sandi adalah kerentanan yang umum diketahui dalam infrastruktur keamanan kita.

Meskipun disimpan dengan aman, sandi rentan terhadap phishing, pelanggaran server, dan serangan otomatis seperti credential stuffing.

Sebagai sebuah industri, kita telah mencoba mengatasi hal ini dengan menerapkan kompleksitas: karakter khusus, angka, rotasi wajib.

Bukti menunjukkan bahwa hal ini telah gagal, salah satunya karena semakin sulit Anda membuatnya, semakin Anda, secara paradoks, mendorong perilaku yang tidak aman.

Karena sandi rumit yang diubah secara rutin adalah sandi yang kemungkinan akan ditulis di catatan tempel.

Bahkan, autentikasi 2 langkah berbasis SMS terbukti rentan terhadap intersepsi seperti pertukaran SIM.

Namun, saat ini, masalah ini sebagian besar telah teratasi.

Kunci sandi dibuat berdasarkan standar FIDO dan menggunakan kriptografi kunci publik-pribadi.

Kunci sandi sangat tahan terhadap phishing, tidak terekspos dalam pelanggaran server, dan terkait langsung dengan keamanan ponsel pengguna melalui kunci layar, yang dalam banyak kasus, didasarkan pada biometrik, sidik jari, dll. Kunci sandi juga secara aktif meningkatkan pengalaman pengguna dengan pengalaman terpadu di berbagai platform dan tidak perlu mengingat sandi yang rumit.

Manifesto kami saat ini sederhana.

Saatnya beralih ke dunia tanpa sandi.

Dan alat untuk melakukannya sudah ada di tangan kita.

Untuk melakukan lompatan ini di Android, kami memiliki Jetpack Credential Manager.

API ini didukung hingga Android 4.4, dan dengan kunci sandi yang didukung sejak Android 9, API ini menyediakan satu API terpadu yang mendukung kunci sandi serta autentikasi tradisional seperti login gabungan, seperti, login dengan Google, dan termasuk penggantian yang lancar ke sandi jika diperlukan.

Anda memanggil Credential Manager API, dan API ini akan menangani UI untuk memilih metode autentikasi yang ingin dilihat pengguna.

Kemudian, library ini akan melakukan tugas berat untuk menampilkan kredensial yang benar, yang diperoleh dengan aman.

Fitur ini mendukung login, pendaftaran, dan pencadangan kredensial.

Anda juga dapat menggunakannya untuk memperbarui dan menghapus kredensial.

Fitur ini juga membantu pengguna memindahkan sandi dan kunci sandi mereka antar-penyedia kredensial hanya dengan beberapa klik, dan tanpa perlu mendownload file.

Fitur ini dirancang untuk memberi pengguna kontrol penuh atas data mereka dan kebebasan untuk beralih penyedia kapan pun mereka perlu.

Dan Pengelola Kredensial mendukung banyak faktor bentuk, termasuk smartwatch, TV, XR, otomotif, ponsel, perangkat foldable, tablet.

Dan, yang paling penting bagi kami, Credential Manager memiliki alur khusus untuk kunci sandi.

Berikut tampilan untuk pengguna selama pendaftaran.

Aplikasi saya memberi tahu Credential Manager bahwa autentikasi kunci sandi tersedia, dan memberikan detail yang dikumpulkan dari backend.

Anda menekan Daftar, dan Credential Manager akan menampilkan panel bawah dengan perintah kunci layar.

Kunci layar ini paling sering dibuka dengan biometrik seperti sidik jari atau pemindaian wajah.

Kemudian, Credential Manager menangani pekerjaan kriptografi yang kompleks seperti membuat kunci sandi.

Dan kunci sandi akan disimpan ke pengelola kredensial saya, yang dalam hal ini adalah Pengelola Sandi Google, tetapi bisa juga yang lain.

Kode akan terlihat seperti berikut ini.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

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

Pertama, kita membuat objek createPublicKeyCredentialRequest ini menggunakan detail yang disediakan backend, yaitu registerRequestJson ini.

Kemudian, kita panggil metode ajaib, credentialManager.createCredential.

Kita meneruskan permintaan tersebut dan konteks lokal, yang memungkinkannya menampilkan UI.

Perhatikan bahwa saya tidak perlu menulis kode UI apa pun di sini.

Credential Manager menangani hal itu sepenuhnya untuk kita.

Sekarang, ini adalah proses login.

Bagi pengguna, proses ini sangat mirip dengan proses pendaftaran.

Ada satu perintah buka kunci, dan Anda selesai.

Bagi developer, hanya sedikit berbeda.

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

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

Pertama, kita mendapatkan detail login dari backend untuk membuat instance GetPublicKeyCredential.

Kita memberi tahu Credential Manager jenis kredensial yang kita dukung.

Di sini, hanya kunci sandi.

Namun, kita juga dapat menambahkan jenis kredensial lain jika diinginkan.

Kemudian, kita memanggil credentialManager.getCredential dengan meneruskan daftar kredensial yang baru saja kita minta.

Sekali lagi, tidak ada kode UI.

Tidak perlu menulis kode UI apa pun.

Pengelola Kredensial sepenuhnya menangani hal tersebut untuk kita.

Tampilan ini mengarahkan pengguna ke opsi yang paling sering digunakan, sementara opsi lainnya tetap tersedia sebagai cadangan.

Hal ini secara otomatis menyelesaikan salah satu masalah autentikasi yang paling mengganggu saat ini.

Apakah Anda memperhatikan?

Yaitu mengingat metode yang terakhir saya gunakan untuk login.

Lihat, jawabannya ditampilkan dengan rapi di panel bawah.

Ngomong-ngomong, hal itu tidak hanya mengganggu pengguna.

Ini adalah titik gesekan yang nyata.

Hal ini menyebabkan pemulihan akun yang tidak perlu, dan memiliki dampak komersial seperti keranjang belanja yang ditinggalkan.

Berikut adalah kode aplikasi demo kami, yang dapat Anda gunakan untuk mencoba Credential Manager sendiri.

Anda juga dapat melihat alur ini di perangkat Anda sendiri.

Dan ada contoh kode resmi dari Google di sebelah kiri.

Yang menangani pembuatan kunci sandi.

Bagaimana cara mengupgrade pengguna sandi yang ada ke kunci sandi?

Nah, alat yang ampuh untuk itu adalah Conditional Create.

Jika pengguna Anda baru saja login menggunakan sandinya, dan sandi tersebut telah diisi otomatis oleh penyedia kredensial yang didukung, berarti kami tahu bahwa pengguna tersebut aktif, dan kami baru saja memverifikasi identitasnya.

Dalam hal ini, Pembuatan Bersyarat memungkinkan kita meminta pembuatan kunci sandi secara otomatis di latar belakang.

Hal ini tidak mengganggu alur kerja pengguna.

Kunci sandi dibuat secara otomatis dan disimpan.

Pengelola Sandi Google akan menampilkan notifikasi untuk mengonfirmasi bahwa hal tersebut telah terjadi.

Pengelola sandi lain mungkin melakukan hal yang berbeda.

Kode untuk Pembuatan Bersyarat sangat mirip dengan kode untuk pendaftaran.

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

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

Flag ajaibnya adalah isConditional true, yang memastikan bahwa pengguna tidak melihat UI tersebut.

Dan karena cara kerjanya oportunistik, kita akan memasukkannya ke dalam try-catch.

Kita akan menangani error apa pun secara otomatis, sehingga kita tidak mengganggu pengguna jika prosesnya gagal.

Kemudian, kunci sandi disimpan ke Credential Manager pengguna, dan akan tersedia untuk digunakan pada lain waktu.

Credential Manager juga memungkinkan penyedia kredensial mengimpor dan mengekspor kredensial mereka dengan aman.

Cukup dengan beberapa klik.

Tidak perlu mendownload.

Hal ini memberikan lebih banyak fleksibilitas, sekaligus menjaga keamanan informasi.

Alurnya terlihat seperti ini.

Di penyedia kredensial barunya, pengguna meminta untuk mengimpor kredensial.

Kemudian, Pengelola Kredensial akan menangani UI impor, sehingga pengguna dapat memilih sumber data kredensial.

Penyedia kredensial yang mengekspor kemudian dapat menyediakan UI-nya sendiri, dan memungkinkan mereka untuk mengedukasi pengguna dan memberikan peringatan yang relevan.

Terakhir, penyedia kredensial baru pengguna akan diberi data melalui saluran yang aman.

Jadi, data tersebut dapat diimpor tanpa interaksi pengguna.

Namun, apa yang terjadi jika pengguna mencabut kunci sandi dari aplikasi atau situsnya?

Kemudian, penyedia kredensial tidak perlu mengetahui bahwa hal itu telah terjadi.

Saat berikutnya mereka mencoba login, Pengelola Kredensial akan menawarkan kunci sandi yang tidak aktif tersebut, dan upaya mereka akan ditolak.

Demikian pula, saat pengguna memperbarui nama pengguna atau nama tampilannya, sinkronisasi diperlukan.

Sekarang dengan Signal API, aplikasi Anda dapat menandai status spesifik ini ke penyedia kredensial.

Ambil contoh kasus login dengan sandi yang dicabut.

Aplikasi Anda dapat menangkap status error spesifik tersebut dan menggunakannya untuk memberi tahu penyedia kredensial pengguna.

Penyedia kredensial kemudian dapat mengupdate dirinya sendiri sehingga kunci sandi tertentu tersebut tidak ditawarkan.

Jadi, itulah beberapa fitur Credential Manager, dan fitur ini sangat membantu pengguna mendaftar menggunakan kunci sandi dan memprioritaskan kunci sandi daripada metode lain saat login.

Namun, ingat bahwa tujuan akhir kita di sini adalah sepenuhnya tanpa sandi.

Bagaimana Credential Manager membantu mencapai sasaran tersebut?

Berikut adalah proses lima langkah yang kami usulkan.

Dalam dua langkah pertama, Anda mengupgrade pengguna sandi ke kunci sandi.

Pertama, kita mencoba secara oportunistik, menggunakan Conditional Create.

Kemudian, jika peluang tersebut belum muncul, pada akhirnya, kita akan memerlukan intervensi pengguna, jadi undangan dalam aplikasi yang meminta pengguna untuk menyiapkan kunci sandi.

Kami dapat mulai menampilkan fitur tersebut secara bertahap dan makin terlihat jelas.

Dari perspektif pengguna, mereka biasanya hanya perlu memberikan kunci layar, seperti biometrik.

Setelah analisis menunjukkan bahwa sebagian besar pengguna Anda memiliki akun yang menggunakan kunci sandi, kunci sandi dapat diwajibkan untuk semua pengguna baru.

Namun, pengguna lama tersebut adalah pengguna yang kita tangani dalam tiga langkah terakhir ini.

Kami mendorong pengguna kunci sandi untuk menghapus sandi mereka.

Jadi, pada langkah 3, kami mengizinkan mereka melakukannya secara manual, dengan opsi Hapus Sandi yang sangat jelas di setelan akun mereka.

Pada langkah 4, kami mulai mendorong penghapusan sandi, misalnya, menggunakan notifikasi dalam aplikasi, yang dipasangkan dengan teks edukasi.

Terakhir, Anda beralih dari penghapusan sandi yang bersifat keikutsertaan menjadi penonaktifan.

Pada akhirnya, opsi terakhir untuk tidak ikut serta pun dapat hilang.

Analytics akan memberi kita keyakinan untuk menghapus alur sandi dari aplikasi sepenuhnya.

Jadi, beralih ke dunia tanpa sandi bukan lagi konsep keamanan teoretis untuk masa depan.

Sangat didukung.

API-nya andal, pengalaman penggunanya luar biasa.

Sebaiknya Anda mulai mengintegrasikan alur kunci sandi dengan Pengelola Kredensial sekarang juga.

Mulailah mengupgrade pengguna Anda, dan mari kita tinggalkan sandi di masa lalu.

Terima kasih.

Sekarang, saya ingin menyerahkan kepada Chiping untuk membahas evolusi berikutnya dalam migrasi dan identitas perangkat.

Keren!

Baiklah, terima kasih, Tom.

Seperti yang ditekankan Tom, autentikasi yang lancar di perangkat pengguna sangatlah penting.

Namun, apa yang terjadi jika pengguna mendapatkan ponsel baru?

Penurunan terbesar dalam perjalanan pengguna saat ini sering terjadi saat mereka beralih perangkat.

Hari ini, saya ingin membahas cara kami mengatasi masalah tersebut dan membahas secara singkat persyaratan Google Play Store mendatang terkait pemulihan kredensial.

Mulai April 2027, Google Play akan mewajibkan aplikasi memenuhi persyaratan login tanpa ketuk untuk mempertahankan kemampuan publikasi penuh dan visibilitas optimal di Google Play Store.

Apa itu login tanpa ketuk?

Artinya, pengguna tidak perlu melakukan autentikasi ulang secara manual di aplikasi Anda saat beralih ke perangkat baru.

Bagaimana cara menerapkannya?

Metode utama yang kami rekomendasikan untuk melakukannya adalah melalui Restore Credentials API Android melalui Credential Manager.

API ini memungkinkan Anda membuat kunci pemulihan, yang disimpan di perangkat pengguna atau di cloud berdasarkan setelan pencadangan pengguna.

Sebaiknya buat kunci ini di latar belakang setelah pengguna login.

Dalam diagram ini, kami mengilustrasikan pengguna yang login ke aplikasi.

Kemudian, kunci pemulihan dibuat saat mereka menggunakan aplikasi pada suatu waktu.

Kunci ini kemudian disimpan secara lokal atau, jika diaktifkan, dari jarak jauh di cloud.

Saat pengguna menyiapkan perangkat barunya, kredensial pemulihan akan ditransfer secara otomatis di latar belakang selama proses penyiapan perangkat.

Pengguna dapat memilih untuk memulihkan data dari cloud atau transfer antarperangkat.

Kemudian, saat aplikasi Anda dibuka, Anda dapat memanggil Credential Manager API untuk menggunakan kunci pemulihan ini guna memproses login pengguna di perangkat baru saat pertama kali diluncurkan.

Hal ini memungkinkan pengguna login ke aplikasi Anda dengan cepat dan aman.

Dan jika Anda ingin aplikasi segera dipulihkan setelah penyiapan tanpa dibuka, Anda dapat menerapkan agen pencadangan kustom untuk melakukannya.

Tindakan ini akan memungkinkan pengguna login ke aplikasi Anda tanpa membukanya secara manual.

Beberapa partner kami telah menerapkan hal ini di aplikasi mereka.

Uber adalah perusahaan transportasi online terbesar di dunia, yang menyediakan transportasi bagi jutaan orang, sekaligus mendukung pengiriman makanan, transportasi layanan kesehatan, dan logistik kargo.

Kemudahan akses sangatlah penting.

Dan saat pengguna beralih ke perangkat baru, mereka mengharapkan transisi yang lancar tanpa perlu login kembali ke aplikasi Uber atau melalui autentikasi satu kali berbasis SMS setiap saat.

Pergantian perangkat yang sering ini menjadi tantangan bagi retensi pengguna.

Setelah melakukan penilaian terhadap permintaan pengguna dan pembuatan prototipe kode, Uber memperkenalkan dukungan Restore Credentials ke aplikasi Uber Rider, dan hasilnya sangat positif.

Mereka memperkirakan bahwa hal ini akan menghemat 4 juta login harian rata-rata per hari, dan mereka memperkirakan jumlah ini akan meningkat seiring dengan pertumbuhan adopsi.

Lihat kode QR dan link ini untuk mempelajari lebih lanjut kebijakan mendatang ini dan cara aplikasi Anda dapat memenuhi persyaratan pemulihan tanpa ketukan.

Sekali lagi, perubahan ini akan berlaku pada April 2027, jadi pastikan untuk menandainya di kalender Anda.

Jika Anda ingin memulai lebih awal dalam menerapkan Pulihkan Kredensial di aplikasi Anda, lihat kode QR dan link ini untuk mengakses keterampilan Pulihkan Kredensial kami.

Keterampilan ini dapat digunakan untuk membantu mengembangkan atau menguji fitur dengan cepat menggunakan agen pilihan Anda.

Sekarang, mari kita lihat masa depan identitas digital: Digital Credentials API melalui Credential Manager.

Mari kita bahas apa itu Kredensial Digital dan cara kerjanya.

Kredensial Digital adalah dokumen digital yang dapat diverifikasi secara kriptografis yang dapat digunakan pengguna untuk memberikan informasi tentang diri mereka.

Dokumen ini disimpan dalam dompet digital di perangkat pengguna dan dapat diminta oleh aplikasi lain di perangkat atau ditampilkan kepada dunia secara hibrid, misalnya melalui kode QR.

Penggunaannya luas dan bervariasi, mulai dari memverifikasi identitas hingga mengakses layanan untuk membeli item secara online.

Kredensial Digital menawarkan cara yang aman dan praktis untuk membagikan informasi tanpa memerlukan kartu fisik.

Kredensial Digital melibatkan tiga pihak: penerbit, pemegang, dan pemverifikasi.

Masa berlaku kredensial digital umumnya mengalir dari kiri ke kanan.

Mari kita bahas setiap entitas ini dan perannya.

Pertama adalah penerbit, yang, seperti namanya, adalah pihak yang menerbitkan kredensial, seperti pemerintah yang menerbitkan paspor Anda.

Namun, di dunia digital, untuk mencegah spoofing, kredensial ini juga ditandatangani oleh penerbit dengan sertifikat digital mereka, sehingga siapa pun yang menerima kredensial dapat mengetahui dengan pasti dari siapa kredensial tersebut berasal.

Sebenarnya, siapa pun dapat menjadi penerbit, baik itu gym, hotel, atau bahkan Anda sendiri.

Anda hanya perlu membuat kredensial dan menandatanganinya.

Jadi, penerbit membuat dan menerbitkan kredensial, tetapi kredensial tersebut perlu disimpan di suatu tempat, sama seperti Anda perlu menyimpan tanda pengenal terbitan pemerintah di dompet Anda sendiri.

Pihak berikutnya adalah pemegang, yang juga biasa disebut sebagai dompet digital.

Pemegang, seperti namanya, terutama menyimpan kredensial yang diterbitkan dari penerbit.

Kredensial ini berada sebagai aplikasi di perangkat Anda, lalu dapat ditampilkan kepada pihak yang meminta.

Sama seperti penerbit, siapa pun dapat menjadi pemegang.

Bahkan, penerbit dan pemegang kartu sering kali dikelola oleh entitas yang sama.

Misalnya, pusat kebugaran yang ingin membuat kredensial keanggotaan digitalnya sendiri dan juga mengelolanya melalui aplikasinya sendiri.

Itu akan menjadi penerbit dan pemegang sekaligus.

Oke, pihak ketiga adalah pemverifikasi, atau pihak yang meminta Kredensial Digital.

Pemverifikasi membuat permintaan kredensial biasanya untuk memeriksa atribut tentang pengguna, seperti persyaratan usia, atau nama keluarga, dan sebagainya.

Bisnis atau aplikasi ini adalah bisnis atau aplikasi yang memerlukan data pengguna tambahan untuk menjalankan layanan, seperti membeli alkohol atau memverifikasi usia minimum.

Di Android, interaksi antara ketiga pihak ini dan pengguna dikoordinasikan melalui Pengelola Kredensial dengan Digital Credentials API.

Penerbit dapat memanggil API untuk menerbitkan kredensial kepada pemegang, meskipun hal ini tidak diperlukan jika mereka adalah entitas yang sama.

Setelah kredensial diterbitkan, verifikator dapat memanggil API untuk meminta kredensial.

Credential Manager mencocokkan permintaan dengan semua pemegang yang tersedia dan menyajikannya kepada pengguna untuk memilih kredensial dan memberikan izin.

Setelah dipilih, pemegang akan dipanggil dan dapat melakukan pemeriksaan tambahan jika diperlukan sebelum membagikan kredensial kepada pemverifikasi.

Setelah menerima kredensial, verifikator juga dapat melakukan berbagai pemeriksaan terhadap legitimasi kredensial, termasuk memeriksa penerbit aslinya.

Sekarang, Anda mungkin bertanya-tanya, bagaimana sebenarnya Kredensial Digital diamankan?

Keamanan sebenarnya sudah disertakan dalam setiap langkah prosesnya, dan kita akan membahas beberapa di antaranya sekarang.

Jadi, di sisi penerbit, saat penerbit ingin membagikan kredensial kepada pemegang, penerbit harus memverifikasi bahwa pemegang tidak dapat diubah atau disalin, pada dasarnya bahwa pemegang dapat dipercaya.

Bagaimana cara memverifikasinya?

Sebelum penerbit merilis kredensial, penerbit memerlukan pemegang untuk membuktikan identitasnya sendiri dan keamanan perangkat yang dioperasikannya.

Pemegang mengirimkan pengesahan dompetnya, biasanya sebagai rantai sertifikat yang dapat diverifikasi.

Pemegang juga membuat pasangan kunci yang terikat hardware.

Kunci ini mengirimkan kunci publik dari pasangan kunci ini kepada penerbit dengan pengesahan kunci Android, sehingga penerbit dapat memvalidasi legitimasi hardware.

Penerbit akan menandatangani kunci publik ini ke dalam kredensial yang diterbitkan, sehingga kredensial tersebut secara resmi terikat ke satu perangkat.

Di sisi pemegang, setelah pemegang memiliki kredensial baru, pemegang hanya mendaftarkan metadata kredensialnya ke Credential Manager.

Credential Manager menggunakan metadata ini untuk menentukan pemegang mana yang akan ditampilkan saat pemverifikasi membuat permintaan kredensial.

Tidak ada data pengguna sebenarnya yang didaftarkan ke Pengelola Kredensial atau diungkapkan kepada Google.

Bahkan saat Credential Manager memilih dompet untuk ditampilkan kepada pengguna, konten di dalam setiap dompet tidak akan diungkapkan pada saat itu.

Sekarang, saat permintaan kredensial dibuat dan izin pengguna untuk membagikan kredensial diberikan, pemegang yang dipilih akan dipanggil dan kontrol alur kerja akan diserahkan kepada pemegang.

Seperti yang mungkin Anda ingat, holder hanyalah sebuah aplikasi, sehingga aplikasi tersebut dipanggil.

Pada saat ini, pemegang dapat melihat hal-hal seperti pemverifikasi yang meminta dan kredensial yang diminta, serta dapat memutuskan apakah ingin membagikan kredensial tersebut kepada pemverifikasi tersebut meskipun pengguna telah memberikan izin.

Data kredensial itu sendiri tidak dapat diakses oleh Google.

Hanya metadata pemilihan rute yang didaftarkan, dan payload dienkripsi end-to-end antara pemegang dan pemverifikasi.

Hal ini memberi pemegang kontrol atas pihak mana yang ingin diajak berbagi kredensial.

Terakhir, di sisi pemverifikasi, setelah kredensial diminta dan pemegang membagikan kredensial, pemverifikasi akan menerima presentasi kredensial dari pemegang.

Sekarang, pemverifikasi dapat memeriksa apakah respons baru saja dibuat oleh pemegang kredensial asli untuk permintaan tersebut.

API ini dapat mengonfirmasi bahwa respons kredensial ditandatangani menggunakan kunci terikat perangkat milik pemegang, termasuk meminta token sekali pakai dan origin panggilan yang diamati oleh pemegang.

Pemverifikasi juga dapat memeriksa keaslian penerbit kredensial dengan memverifikasi sertifikat penerbit, sehingga memastikan bahwa kredensial tersebut berasal dari sumber tepercaya.

Singkatnya, penerbit mendapatkan jaminan hardware, pemegang mendapatkan kontrol atas kredensial yang ingin mereka bagikan, pemverifikasi mendapatkan bukti kriptografis dari penerbit dan pemegang, lalu pengguna mempertahankan izin penuh atas data yang ingin mereka bagikan.

Setelah membahas keamanan Kredensial Digital, mari kita pelajari beberapa kasus penggunaan Kredensial Digital yang tersedia saat ini melalui Digital Credentials API di Android.

Yang pertama akan saya bahas adalah verifikasi email.

API ini mengambil Gmail pengguna yang login langsung dari perangkatnya, dan menyajikannya sebagai kredensial digital yang diverifikasi Google ke aplikasi Anda, sehingga tidak perlu mengirim sandi sekali pakai atau magic link.

Artinya, pengguna tidak perlu keluar dari aplikasi Anda dan hanya perlu memberikan izin dengan sekali ketuk pada panel bawah Credential Manager yang sudah dikenal.

Berikut adalah demo rekaman demo API yang sedang beraksi.

Ini adalah aplikasi contoh yang menerapkan verifikasi email melalui Digital Credentials API.

Saat saya mengetuk "Minta email terverifikasi", Pengelola Kredensial akan meminta kredensial digital email terverifikasi dari pemegang di perangkat yang menyimpan jenis kredensial ini.

Dalam hal ini, hanya Google yang menjadi pemegang kredensial email terverifikasi ini, yang ditampilkan di panel bawah.

Email ini adalah salah satu email yang digunakan pengguna untuk login di perangkat.

Dan, dalam hal ini, Google adalah penerbit dan pemegang kredensial digital.

Setelah saya memilih kredensial yang ingin saya bagikan, kredensial tersebut akan ditampilkan ke aplikasi, yang saat ini hanya menampilkan kolom yang terdapat dalam kredensial, yaitu email terverifikasi.

Di aplikasi, Anda dapat menggunakan informasi ini untuk melanjutkan ke layar aplikasi berikutnya, seperti membuat kunci sandi atau langkah pembuatan akun lainnya.

Bagi pengguna, prosesnya sangat sederhana, yaitu memberikan izin, lalu melanjutkan ke layar berikutnya.

Jika ingin mencobanya, Anda dapat membuka contoh GitHub kami dan menginstalnya di perangkat Anda sendiri.

Coba gunakan di perangkat fisik, dan perhatikan bahwa Anda harus login ke setidaknya satu akun Gmail di perangkat Anda.

Jadi, saya akan memberikan sedikit lebih banyak waktu jika ada yang tertarik.

Oke.

Kedengarannya menarik, bukan?

Dan saat Anda memikirkan verifikasi email, apa bentuk verifikasi pengguna berikutnya yang terlintas dalam pikiran?

Benar, verifikasi nomor telepon.

Digital Credentials API juga mendukung verifikasi nomor telepon secara native, sehingga menghilangkan hambatan dan kerentanan OTP SMS.

Cara kerja verifikasi nomor telepon juga melalui Digital Credentials API, dan dalam hal ini, nomor telepon di perangkat diminta dan ditampilkan sebagai kredensial digital.

Pengguna hanya akan melihat panel bawah Credential Manager yang sudah dikenal untuk membagikan atau memverifikasi nomor telepon mereka, tetap berada dalam aplikasi, dan hanya memerlukan beberapa ketukan untuk menyelesaikan verifikasi.

Di sini, Anda dapat melihat contoh aplikasi tempat pelanggan dapat membagikan nomor teleponnya dengan sekali ketuk, tanpa keluar dari aplikasi.

Jadi, bagaimana cara kerja penyiapan ini?

Jika kita memetakan ini ke pihak kredensial digital, penerbit, dalam hal ini, adalah operator telepon dari nomor telepon di kartu SIM perangkat, dan pemegangnya adalah Android Telephony.

Saat pemverifikasi, seperti aplikasi Anda, meminta nomor telepon pengguna, nomor telepon tersebut akan diambil dari Google Telephony dengan panggilan API Digital Credentials.

Anda mungkin bertanya-tanya bagaimana cara kerja penagihan.

Ada langkah tambahan yang unik untuk alur ini, yaitu kredensial diteruskan ke operator atau agregator Anda untuk tujuan penagihan.

Hal ini terjadi setelah nomor telepon diambil dari Google Telephony, tempat nomor telepon disimpan dalam status terenkripsi.

Token ini kemudian diteruskan ke operator, yang mendekripsi dan menampilkan nomor telepon ke backend aplikasi Anda secara langsung, dan Anda akan ditagih selama proses ini.

Hal yang menarik dari hal ini adalah operator hanya akan menagih Anda untuk verifikasi yang berhasil, yang ditransfer melalui data atau Wi-Fi, dan jauh lebih andal daripada SMS.

Berikut demo verifikasi nomor telepon yang sedang berjalan, menggunakan Firebase sebagai agregator operator.

Aplikasi meminta nomor telepon pengguna sebagai bagian dari proses login.

Pengguna ini memiliki beberapa kartu SIM, dan memilih satu untuk dibagikan ke aplikasi.

Setelah pengguna mengonfirmasi pilihannya, pertukaran akan terjadi di latar belakang.

Kemudian, Anda hanya akan melihat layar berikutnya dengan nomor telepon yang diambil terisi.

Pengguna tidak perlu keluar dari aplikasi, dan hanya perlu memilih dan mengonfirmasi nomor telepon yang akan dibagikan untuk melanjutkan alur dengan lancar, semuanya dalam beberapa ketukan.

Tunggu hingga proses ini selesai agar Anda dapat melihat penyelesaiannya sekali lagi.

Jadi, Anda akan melihat nomor telepon di layar terakhir tersebut.

Selesai.

Kita telah membahas banyak hal hari ini.

Pertama, kita mempelajari penggunaan Credential Manager untuk meningkatkan implementasi kunci sandi Anda, dan beralih ke dunia tanpa sandi.

Lihat referensi kami tentang Credential Manager dan kunci sandi di sini untuk mempelajari lebih lanjut dan mendapatkan akses ke aplikasi contoh kami.

Selanjutnya, kami membahas persyaratan login tanpa ketukan yang akan datang untuk aplikasi Anda, yang memudahkan pengguna login saat menyiapkan perangkat baru.

Hal ini akan diwajibkan di Google Play Store paling lambat April 2027, jadi harap catat hal ini di kalender Anda.

Terakhir, kami membahas cara kerja kredensial digital, dan beberapa fitur yang paling berguna di Android.

Lihat referensi kami tentang kredensial digital di sini untuk pembahasan mendalam tentang konten dan akses ke contoh kami.

Semua yang kami bagikan hari ini sudah tersedia dan siap Anda gunakan untuk membangun.

Masa depan identitas di Android telah hadir, dan lebih menarik dari sebelumnya.

Terima kasih atas waktu Anda, dan saya tahu ini waktunya makan siang, jadi silakan nikmati makanan di luar.

Jangan ragu untuk menghubungi saya atau Tom jika ada pertanyaan tentang kunci sandi atau kredensial digital.

Terima kasih.