ข้อมูลอัปเดตการยืนยันอีเมล ตุลาคม 2026

Rowan Merewood

เผยแพร่: 5 ตุลาคม 2026

เราได้ทำการอัปเดตเพิ่มเติมตามความคิดเห็นของคุณในขณะที่ช่วงทดลองใช้จากต้นทางสำหรับการยืนยันอีเมลยังคงดำเนินต่อไป เราไม่คาดว่าจะมีการเปลี่ยนแปลงที่ทำให้เกิดข้อขัดข้องเพิ่มเติมและกำลัง เตรียมที่จะเปิดตัวฟีเจอร์นี้ นอกจากนี้ เรายังได้เปิดตัวส่วนเอกสารประกอบใหม่สำหรับ การยืนยันทางอีเมล โดยมีส่วนเฉพาะสำหรับ ผู้ยืนยันและ ผู้ออก

ช่วงทดลองใช้จากต้นทางสำหรับการยืนยันอีเมลเริ่มต้นใน Chrome 150 บนเดสก์ท็อป เราจะปรับปรุงการติดตั้งใช้งานต่อไปตามความคิดเห็นของนักพัฒนาแอปและการทดสอบในระบบนิเวศ โพสต์นี้ครอบคลุมการอัปเดตจาก Chrome 154 ซึ่งรวมถึงการรองรับ Android การทดลองใช้ต้นทางของบุคคลที่สาม การจัดการการค้นหาคีย์ระหว่างการตรวจสอบโทเค็น และการอัปเดตส่วนหัวสำหรับผู้ให้บริการอีเมล

การอัปเดตที่แสดงต่อผู้ใช้

การเปลี่ยนแปลงในอินเทอร์เฟซผู้ใช้หรือลักษณะการทำงานที่ผู้ใช้มองเห็น

การรองรับ Chrome บน Android

ตั้งแต่ Chrome 154 เป็นต้นไป Chrome สำหรับ Android จะรองรับการยืนยันอีเมล ผู้ยืนยันหรือผู้ให้บริการไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ เนื่องจาก API หรือ โปรโตคอลยังคงเหมือนเดิม โดยมีข้อกำหนดเบื้องต้นเหมือนกัน ซึ่งรวมถึง ข้อกำหนดที่ผู้ใช้ต้องลงชื่อเข้าใช้ผู้ให้บริการอีเมลใน เบราว์เซอร์

ผู้ใช้เข้าถึงการตั้งค่าได้ที่การตั้งค่า > ที่อยู่และอื่นๆ > อีเมลที่ยืนยันแล้ว

ข้อมูลอัปเดตสำหรับผู้ยืนยัน

การเปลี่ยนแปลงสำหรับเว็บไซต์ที่รวบรวมและยืนยันอีเมล

การทดลองใช้ต้นทางของบุคคลที่สาม

ตั้งแต่ Chrome 154 เป็นต้นไป ระบบจะรองรับการทดลองใช้ต้นทางของบุคคลที่สามสำหรับการยืนยันทางอีเมล (ดูปัญหา 534377131) หากคุณมี สคริปต์ฝังหรือ SDK ของข้อมูลประจำตัว ตอนนี้คุณสามารถลงทะเบียนเพื่อรับโทเค็นทดลองใช้ของบุคคลที่สาม และแทรกลงในหน้าที่โฮสต์สคริปต์ได้แล้ว เว็บไซต์ที่ฝังสคริปต์ของคุณไม่จำเป็นต้องลงทะเบียนโทเค็นช่วงทดลองใช้จากต้นทางแยกต่างหาก

ข้อควรระวังที่สำคัญคือ ผู้ลงทะเบียนช่วงทดลองใช้จากต้นทางและผู้ออกใบรับรองต้องเป็นเว็บไซต์เดียวกัน กล่าวคือ ต้นทางที่ลงทะเบียนสำหรับการทดลองใช้ต้องตรงกับ โดเมนผู้ออกใบรับรอง

การกำหนดค่าที่รองรับ

  • โดเมนผู้ออกใบรับรอง: issuer.example
  • ผู้ลงทะเบียน OT: https://issuer.example
  • ต้นทาง JavaScript: https://issuer.example (หรือ https://app.issuer.example ที่มีการจับคู่โดเมนย่อย)

การกำหนดค่าที่ไม่รองรับ

  • ผู้จดทะเบียนโดเมนย่อย: โดเมนผู้ออกคือ issuer.example แต่ผู้จดทะเบียน OT คือ https://app.issuer.example
  • ผู้จดทะเบียนข้ามเว็บไซต์: โดเมนผู้ออกคือ issuer.example แต่ผู้จดทะเบียน OT คือ https://different.example

จัดการตัวเลือก kid ใน EVT

เมื่อตรวจสอบโทเค็นการยืนยันทางอีเมล (EVT) เซิร์ฟเวอร์จะดึงข้อมูลชุดคีย์เว็บ JSON (JWKS) ของผู้ให้บริการเพื่อยืนยันลายเซ็นเข้ารหัสของผู้ให้บริการ คีย์อาจมีkidตัวระบุคีย์ ซึ่งอาจรวมอยู่ใน JWT เพื่อระบุว่าใช้คีย์ใดในการลงนามโทเค็น หากโทเค็นไม่มีการอ้างสิทธิ์ kid (เช่น ใน Gmail) ให้ทำซ้ำ ผ่านคีย์เพื่อค้นหาคีย์ที่ถูกต้อง เอกสารประกอบ และการสาธิตแสดงโค้ดที่ใช้ทำสิ่งนี้

ส่งคืนการอ้างสิทธิ์ email ตามที่ระบุไว้ทุกประการ

ตั้งแต่ Chrome 156 เป็นต้นไป ระบบจะแสดงอีเมลในโทเค็นตรงตามที่ระบุในการส่งแบบฟอร์ม (ดูปัญหา 549217427) ก่อนหน้านี้ ผู้ออกบัตร อาจส่งคืนอีเมลมาตรฐานของบัญชี (เช่น ส่งคืน First.Last@example.com เมื่อการส่งแบบฟอร์มมี first.last@example.com) โปรดทราบว่าควรใช้การเปรียบเทียบที่ไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่กับอีเมลที่ส่งคืนเสมอ ดังนั้นการเปลี่ยนแปลงนี้จึงไม่ควรเป็นการเปลี่ยนแปลงที่ทำให้เกิดข้อขัดข้อง

ข้อมูลอัปเดตจากผู้ให้บริการ

การเปลี่ยนแปลงสำหรับผู้ให้บริการอีเมล

ส่งคืนการอ้างสิทธิ์ email ตามที่ระบุไว้ทุกประการ

ในฝั่งผู้ให้บริการ ข้อกำหนดนี้จะเข้มงวดมากขึ้น กล่าวคือ หากผู้ให้บริการไม่ส่งคืนอีเมลตามที่ระบุไว้ทุกประการ Chrome จะปฏิเสธโทเค็น ซึ่งจะช่วย หลีกเลี่ยงการเปิดเผยข้อมูลมากกว่าที่ควรจะเปิดเผยด้วยการส่งอีเมล ยืนยัน ตรวจสอบอีเมลขาเข้ากับผู้ใช้ที่ลงชื่อเข้าใช้เพื่อให้ตรงกันในลักษณะเดียวกับที่คุณจัดการการนำส่งอีเมล

เปลี่ยนชื่อ Sec-Fetch-Dest เป็น email-verification

ตั้งแต่ Chrome 154 เป็นต้นไป ส่วนหัว Sec-Fetch-Dest ที่ส่งในคำขอออกโทเค็นจะได้รับการอัปเดตให้ใช้ขีดกลาง

  • Chrome 154 ขึ้นไป: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

การเปลี่ยนแปลงนี้จะกำหนดตัวระบุปลายทางการดึงข้อมูลตามมาตรฐานด้วย รูปแบบการตั้งชื่อของแพลตฟอร์มเว็บ (ดูปัญหา 546618576)

หากปลายทางการออกบัตรตรวจสอบส่วนหัว Sec-Fetch-Dest (แนะนําให้ทําเพื่อป้องกัน CSRF และบริบทคําขอที่ไม่ต้องการ) ให้อัปเดตการตรวจสอบเพื่อยอมรับ email-verification ยอมรับทั้ง 2 ค่าในช่วงการเปลี่ยนผ่านเพื่อไม่ให้เกิดการหยุดชะงักระหว่างการเปิดตัวเบราว์เซอร์

แหล่งข้อมูลและความคิดเห็น