Pembaruan verifikasi email, Oktober 2026

Rowan Merewood

Dipublikasikan: 5 Oktober 2026

Seiring berlanjutnya uji coba origin Verifikasi Email, kami telah melakukan pembaruan lebih lanjut berdasarkan masukan Anda. Kami tidak memperkirakan akan ada perubahan yang merusak lebih lanjut dan sedang bersiap untuk meluncurkan fitur ini. Kami juga telah meluncurkan bagian dokumentasi baru untuk Verifikasi Email dengan bagian khusus untuk pemverifikasi dan penerbit.

Uji coba origin Verifikasi Email dimulai di Chrome 150 di desktop. Setelah menerima masukan developer dan melakukan pengujian di seluruh ekosistem, kami terus menyempurnakan penerapan ini. Postingan ini membahas update dari Chrome 154, termasuk dukungan Android, uji coba origin pihak ketiga, penanganan penemuan kunci selama validasi token, dan update header untuk penyedia email.

Pembaruan yang ditampilkan kepada pengguna

Perubahan pada antarmuka pengguna atau perilaku yang ditampilkan kepada pengguna.

Dukungan Chrome di Android

Mulai Chrome 154, Chrome untuk Android mendukung verifikasi email. Verifikator atau penyedia tidak perlu melakukan perubahan apa pun karena API atau protokol tetap sama. Prasyarat yang sama berlaku, termasuk persyaratan bahwa pengguna harus login ke penyedia email mereka di browser.

Pengguna dapat mengakses setelan mereka di bagian Setelan > Alamat dan lainnya > Email Terverifikasi.

Pembaruan verifikasi

Perubahan untuk situs yang mengumpulkan dan memverifikasi email.

Uji coba origin pihak ketiga

Mulai Chrome 154, uji coba origin pihak ketiga didukung untuk verifikasi email (Lihat masalah 534377131). Jika Anda menyediakan skrip sematan atau SDK identitas, Anda kini dapat mendaftar untuk mendapatkan token uji coba pihak ketiga dan menyisipkannya ke halaman yang menghosting skrip Anda. Situs yang menyematkan skrip Anda tidak perlu mendaftarkan token uji coba origin terpisah.

Ada satu peringatan penting: pendaftar uji coba origin dan penerbit harus berada di situs yang sama. Secara khusus, asal yang terdaftar untuk uji coba harus cocok dengan domain penerbit.

Konfigurasi yang didukung:

  • Domain penerbit: issuer.example
  • Pendaftar OT: https://issuer.example
  • Origin JavaScript: https://issuer.example (atau https://app.issuer.example dengan pencocokan subdomain)

Konfigurasi yang tidak didukung:

  • Pendaftar subdomain: Domain penerbit adalah issuer.example, tetapi pendaftar OT adalah https://app.issuer.example.
  • Pendaftar lintas situs: Domain penerbit adalah issuer.example, tetapi pendaftar OT adalah https://different.example.

Menangani kid opsional di EVT

Saat memvalidasi Token Verifikasi Email (EVT), server Anda mengambil JSON Web Key Set (JWKS) penyedia untuk memverifikasi tanda tangan kriptografi penerbit. Kunci secara opsional menyertakan ID kunci kid yang juga secara opsional disertakan dalam JWT yang menunjukkan kunci mana yang digunakan untuk menandatangani token. Jika token tidak menyertakan klaim kid (misalnya, dengan Gmail), lakukan iterasi melalui kunci untuk menemukan kunci yang benar. Dokumentasi dan demo menunjukkan kode untuk melakukannya.

Menampilkan klaim email persis seperti yang diberikan

Mulai Chrome 156, alamat email dalam token akan ditampilkan persis seperti yang diberikan dalam pengiriman formulir (lihat masalah 549217427). Sebelumnya, penerbit mungkin telah menampilkan alamat email kanonis akun (misalnya, menampilkan First.Last@example.com saat pengiriman formulir berisi first.last@example.com). Perhatikan bahwa selalu merupakan praktik yang baik untuk menggunakan perbandingan yang tidak peka huruf besar/kecil pada email yang ditampilkan, sehingga hal ini tidak akan menjadi perubahan yang merusak.

Info terbaru penyedia

Perubahan untuk penyedia email.

Menampilkan klaim email persis seperti yang diberikan

Dari sisi penyedia, persyaratan ini lebih ketat: jika penyedia tidak menampilkan email persis seperti yang diberikan, Chrome akan menolak token. Tindakan ini menghindari pemaparan lebih banyak data daripada yang akan diungkapkan dengan mengirim email konfirmasi. Validasi email masuk terhadap pengguna yang login untuk menemukan kecocokan dengan cara yang sama seperti yang Anda lakukan saat menangani pengiriman email.

Mengganti nama Sec-Fetch-Dest menjadi email-verification

Mulai Chrome 154, header Sec-Fetch-Dest yang dikirim pada permintaan penerbitan token telah diperbarui untuk menggunakan tanda hubung:

  • Chrome 154+: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Perubahan ini menstandardisasi ID tujuan pengambilan dengan konvensi penamaan platform web (lihat masalah 546618576).

Jika endpoint penerbitan Anda memvalidasi header Sec-Fetch-Dest (direkomendasikan untuk melindungi dari CSRF dan konteks permintaan yang tidak diinginkan), perbarui pemeriksaan Anda untuk menerima email-verification. Untuk menghindari gangguan selama peluncuran browser, terima kedua nilai selama transisi.

Referensi dan masukan