ตรวจสอบผลกระทบที่การเปลี่ยนแปลงคุกกี้ของบุคคลที่สามมีต่อเวิร์กโฟลว์การลงชื่อเข้าใช้

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

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

หากเว็บไซต์จัดการเฉพาะขั้นตอนภายในโดเมนและโดเมนย่อยเดียวกัน เช่น publisher.example และ login.publisher.example เว็บไซต์จะไม่ใช้คุกกี้ข้ามเว็บไซต์ และขั้นตอนลงชื่อเข้าใช้จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงคุกกี้ของบุคคลที่สาม

อย่างไรก็ตาม หากเว็บไซต์ใช้โดเมนแยกต่างหากสำหรับการเข้าสู่ระบบ เช่น ใช้Google Sign-in หรือ Facebook Login หรือเว็บไซต์ต้องแชร์การตรวจสอบสิทธิ์ผู้ใช้ในหลายโดเมนหรือโดเมนย่อย คุณอาจต้องทําการเปลี่ยนแปลงเว็บไซต์เพื่อให้การเปลี่ยนจากคุกกี้ข้ามเว็บไซต์เป็นไปอย่างราบรื่น

เส้นทางของผู้ใช้ที่พบบ่อย

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

API อื่นๆ ที่แนะนําสําหรับ Use Case ที่พบบ่อย

เส้นทางของผู้ใช้	API ที่แนะนํา
การลงชื่อเข้าใช้ผ่านโซเชียล	สําหรับผู้ให้บริการข้อมูลประจําตัว: ใช้ FedCM สําหรับบุคคลที่เชื่อถือ: ติดต่อผู้ให้บริการข้อมูลประจําตัว
การออกจากระบบของช่องด้านหน้า	สําหรับผู้ให้บริการข้อมูลประจําตัว ให้ติดตั้งใช้งาน FedCM
การลงชื่อเพียงครั้งเดียว	สําหรับผู้ให้บริการข้อมูลประจําตัวหรือโซลูชันที่กําหนดเอง ให้ใช้ชุดเว็บไซต์ที่เกี่ยวข้อง
การจัดการโปรไฟล์ผู้ใช้	Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM
การจัดการการสมัครใช้บริการ	Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM
การตรวจสอบสิทธิ์	API การเข้าถึงพื้นที่เก็บข้อมูล FedCM Web Authentication API sciencePopins ที่แบ่งพาร์ติชันแล้ว
เส้นทางของผู้ใช้อื่นๆ	สถานการณ์เหล่านี้มักจะไม่มีทรัพยากร Dependency ของคุกกี้ของบุคคลที่สามและคาดว่าจะไม่ได้รับผลกระทบ

ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับข้อมูลประจำตัว

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

ต่อไปนี้เป็นรายการสิ่งที่ต้องตรวจสอบเมื่อคุณจํากัดคุกกี้ของบุคคลที่สามแล้ว

• การลงทะเบียนผู้ใช้: การสร้างบัญชีใหม่ทํางานได้ตามปกติ หากใช้ผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม ให้ตรวจสอบว่าการลงทะเบียนบัญชีใหม่ใช้งานได้กับการผสานรวมทุกรายการ
• การกู้คืนรหัสผ่าน: การกู้คืนรหัสผ่านทำงานได้ตามที่คาดไว้ ตั้งแต่ UI ของเว็บ CAPTCHA ไปจนถึงการรับอีเมลสำหรับการกู้คืนรหัสผ่าน
• การลงชื่อเข้าใช้: เวิร์กโฟลว์การลงชื่อเข้าใช้จะทำงานภายในโดเมนเดียวกันและเมื่อไปยังโดเมนอื่น โปรดทดสอบการผสานรวมการลงชื่อเข้าใช้ทั้งหมด
• การออกจากระบบ: กระบวนการออกจากระบบทำงานได้ตามที่คาดไว้ และผู้ใช้จะยังคงออกจากระบบหลังจากขั้นตอนการออกจากระบบ

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

โซลูชันการลงชื่อเข้าใช้

ในส่วนนี้ คุณจะเห็นข้อมูลเฉพาะเพิ่มเติมเกี่ยวกับผลกระทบที่อาจเกิดขึ้นกับขั้นตอนเหล่านั้น

การลงชื่อเพียงครั้งเดียว (SSO) ของบุคคลที่สาม

การลงชื่อเพียงครั้งเดียว (SSO) ของบุคคลที่สามช่วยให้ผู้ใช้ตรวจสอบสิทธิ์ด้วยข้อมูลเข้าสู่ระบบชุดเดียวในแพลตฟอร์มเดียว จากนั้นเข้าถึงแอปพลิเคชันและเว็บไซต์ต่างๆ ได้โดยไม่ต้องป้อนข้อมูลเข้าสู่ระบบอีกครั้ง เนื่องจากการติดตั้งใช้งานโซลูชัน SSO มีความซับซ้อน หลายบริษัทจึงเลือกใช้ผู้ให้บริการโซลูชันบุคคลที่สามเพื่อแชร์สถานะการลงชื่อเข้าใช้ระหว่างต้นทางหลายแห่ง ตัวอย่างผู้ให้บริการ ได้แก่ Okta, Ping Identity, Google Cloud IAM หรือ Microsoft Entra ID

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

หลายโดเมน

บางเว็บไซต์ใช้โดเมนอื่นเพื่อตรวจสอบสิทธิ์ผู้ใช้ที่ไม่มีสิทธิ์ใช้คุกกี้ของเว็บไซต์เดียวกันเท่านั้น เช่น เว็บไซต์ที่ใช้ example.com สำหรับเว็บไซต์หลักและ login.example สำหรับขั้นตอนการเข้าสู่ระบบ ซึ่งอาจต้องมีการเข้าถึงคุกกี้ของบุคคลที่สามเพื่อให้แน่ใจว่าผู้ใช้ได้รับการตรวจสอบสิทธิ์ในทั้ง 2 โดเมน

บางธุรกิจอาจมีผลิตภัณฑ์หลายรายการที่โฮสต์ในโดเมนหรือโดเมนย่อยที่แตกต่างกัน โซลูชันดังกล่าวอาจต้องการแชร์เซสชันผู้ใช้ในผลิตภัณฑ์เหล่านั้น ซึ่งเป็นสถานการณ์ที่อาจต้องมีการเข้าถึงคุกกี้ของบุคคลที่สามระหว่างโดเมนหลายรายการ

เส้นทางการย้ายข้อมูลสำหรับสถานการณ์นี้มีดังนี้

• อัปเดตเพื่อใช้คุกกี้ของบุคคลที่หนึ่ง ("เว็บไซต์เดียวกัน"): การเปลี่ยนแปลงโครงสร้างพื้นฐานของเว็บไซต์เพื่อให้โฮสต์ขั้นตอนการเข้าสู่ระบบในโดเมนเดียวกัน (หรือโดเมนย่อย) กับเว็บไซต์หลัก ซึ่งจะใช้เฉพาะคุกกี้ของบุคคลที่หนึ่ง ซึ่งอาจต้องใช้ความพยายามมากกว่า โดยขึ้นอยู่กับวิธีตั้งค่าโครงสร้างพื้นฐาน
• ใช้ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) และ Storage Access API (SAA): RWS ช่วยให้เข้าถึงคุกกี้ข้ามเว็บไซต์ได้แบบจํากัดระหว่างโดเมนที่เกี่ยวข้องกลุ่มเล็กๆ เมื่อใช้ RWS ผู้ใช้ไม่จําเป็นต้องได้รับข้อความแจ้งเมื่อขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลด้วย Storage Access API ซึ่งจะทำให้สามารถใช้ SSO กับ RP ที่อยู่ใน RWS เดียวกันกับ IdP อย่างไรก็ตาม RWS รองรับการเข้าถึงคุกกี้ข้ามเว็บไซต์ในโดเมนจํากัดเท่านั้น
• ใช้ Web Authentication API: Web Authentication API อนุญาตให้บุคคลที่เชื่อถือ (RP) ลงทะเบียนชุดต้นทางที่เกี่ยวข้องแบบจํากัดซึ่งสร้างและใช้ข้อมูลเข้าสู่ระบบได้
• หากตรวจสอบสิทธิ์ผู้ใช้ในโดเมนที่เชื่อมโยงมากกว่า 5 โดเมน ให้ดูการจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์ (FedCM): FedCM ช่วยให้ผู้ให้บริการข้อมูลประจำตัวใช้ Chrome ในการจัดการขั้นตอนที่เกี่ยวข้องกับข้อมูลประจำตัวได้โดยไม่ต้องใช้คุกกี้ของบุคคลที่สาม ในกรณีนี้ "โดเมนการลงชื่อเข้าใช้" อาจทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัวของ FedCM และใช้ตรวจสอบสิทธิ์ผู้ใช้ในโดเมนอื่นๆ

การตรวจสอบสิทธิ์จากการฝัง

สมมติว่าฝัง iframe ของ 3-party-app.example ใน top-level.example ใน 3-party-app.example ผู้ใช้จะเข้าสู่ระบบด้วยข้อมูลเข้าสู่ระบบ 3-party-app.example หรือผู้ให้บริการบุคคลที่สามรายอื่นก็ได้

ผู้ใช้คลิก "เข้าสู่ระบบ" และตรวจสอบสิทธิ์ภายในป๊อปอัป 3-party-app.example ป๊อปอัป 3-party-app.example จะตั้งค่าคุกกี้ของบุคคลที่หนึ่ง แต่ iframe 3-party-app.example ที่ฝังใน top-level.example ถูกแบ่งพาร์ติชันแล้ว และจะเข้าถึงคุกกี้ที่ตั้งค่าในบริบทของบุคคลที่หนึ่งใน 3-party-app.example ไม่ได้

ปัญหาเดียวกันนี้จะเกิดขึ้นเมื่อระบบเปลี่ยนเส้นทางผู้ใช้จาก top-level.example ไปยัง 3-party-app.example และกลับ คุกกี้จะเขียนในบริบทของบุคคลที่หนึ่งของเว็บไซต์ 3-party-app.example แต่มีการแบ่งพาร์ติชันและเข้าถึงไม่ได้ภายใน iframe ของ 3-party-app.example

ในกรณีที่ผู้ใช้เข้าชมต้นทางที่ฝังในบริบทระดับบนสุด Storage Access API เป็นโซลูชันที่ดี

หากต้องการย้ายข้อมูลออกจากโซลูชันที่ใช้คุกกี้ของบุคคลที่สาม เราขอแนะนำให้ผู้ให้บริการข้อมูลประจำตัวใช้ FedCM API และมีการเรียก FedCM จากภายในการฝังแทนการใช้ป๊อปอัป

โซลูชันที่เสนออีกรายการสำหรับขั้นตอนนี้คือป๊อปอัปที่มีการแบ่งพาร์ติชัน ซึ่งอยู่ระหว่างการติดตั้งใช้งาน

การลงชื่อเข้าใช้ด้วยโซเชียล

ปุ่มลงชื่อเข้าใช้ เช่น ลงชื่อเข้าใช้ด้วย Google, Facebook Login และลงชื่อเข้าใช้ด้วย Twitter เป็นสัญญาณที่ชัดเจนว่าเว็บไซต์ของคุณใช้ผู้ให้บริการข้อมูลระบุตัวตนแบบรวมศูนย์ ผู้ให้บริการข้อมูลประจำตัวที่รวมศูนย์แต่ละรายจะมีการติดตั้งใช้งานของตนเอง

หากคุณใช้ไลบรารีแพลตฟอร์ม JavaScript ของ Google Sign-In ที่เลิกใช้งานแล้ว คุณสามารถดูข้อมูลเกี่ยวกับวิธีย้ายข้อมูลไปยังไลบรารี Google Identity Services เวอร์ชันใหม่เพื่อการตรวจสอบสิทธิ์และการให้สิทธิ์

เว็บไซต์ส่วนใหญ่ที่ใช้ไลบรารี Google Identity Services เวอร์ชันใหม่ได้เลิกใช้คุกกี้ของบุคคลที่สามแล้ว เนื่องจากไลบรารีจะย้ายข้อมูลโดยอัตโนมัติเพื่อใช้ FedCM เพื่อการทำงานร่วมกัน เราขอแนะนําให้ทดสอบเว็บไซต์โดยเปิดใช้ Flag การทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม และเตรียมความพร้อมโดยใช้รายการตรวจสอบการย้ายข้อมูล FedCM หากจําเป็น

เข้าถึงและแก้ไขข้อมูลผู้ใช้จากการฝัง

เนื้อหาที่ฝังมักใช้สำหรับเส้นทางของผู้ใช้ เช่น การเข้าถึงหรือจัดการข้อมูลโปรไฟล์ผู้ใช้หรือการติดตาม

เช่น ผู้ใช้อาจเข้าสู่ระบบ website.example ซึ่งฝังวิดเจ็ต subscriptions.example วิดเจ็ตนี้ช่วยให้ผู้ใช้จัดการข้อมูลของตนได้ เช่น การสมัครรับเนื้อหาพรีเมียมหรือการอัปเดตข้อมูลการเรียกเก็บเงิน หากต้องการแก้ไขข้อมูลผู้ใช้ วิดเจ็ตที่ฝังอาจต้องเข้าถึงคุกกี้ของตนเองขณะที่ฝังอยู่ใน website.example ในสถานการณ์ที่ควรแยกข้อมูลนี้ไปยัง website.example CHIP จะช่วยให้แน่ใจว่าการฝังเข้าถึงข้อมูลที่ต้องการได้ เมื่อใช้ CHIPS วิดเจ็ต subscriptions.example ที่ฝังใน website.example จะไม่มีสิทธิ์เข้าถึงข้อมูลการสมัครใช้บริการของผู้ใช้บนเว็บไซต์อื่นๆ

ลองพิจารณาอีกกรณีหนึ่งคือ วิดีโอจาก streaming.example ฝังอยู่ใน website.example และผู้ใช้มีการสมัครใช้บริการ streaming.example แบบพรีเมียม ซึ่งวิดเจ็ตจำเป็นต้องทราบเกี่ยวกับการปิดโฆษณา หากต้องเข้าถึงคุกกี้เดียวกันในหลายเว็บไซต์ ให้พิจารณาใช้ Storage Access API หากผู้ใช้เคยเข้าชม streaming.example เป็นระดับบนสุด และชุดเว็บไซต์ที่เกี่ยวข้องหากชุด website.example เป็นเจ้าของ streaming.example

ตั้งแต่ Chrome 131 เป็นต้นไป FedCM จะผสานรวมกับ Storage Access API เมื่อผสานรวมแล้ว เมื่อผู้ใช้ยอมรับข้อความแจ้งของ FedCM เบราว์เซอร์จะให้สิทธิ์การฝัง IdP เข้าถึงพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน

ดูข้อมูลเพิ่มเติมเกี่ยวกับ API ที่ควรเลือกเพื่อจัดการเส้นทางของผู้ใช้ที่เฉพาะเจาะจงซึ่งมีเนื้อหาที่ฝังได้ที่คู่มือการฝัง

ออกจากระบบในช่องทางด้านหน้า

การออกจากระบบช่องทางด้านหน้าเป็นกลไกที่อนุญาตให้ผู้ใช้ออกจากระบบแอปที่เกี่ยวข้องทั้งหมดเมื่อผู้ใช้ออกจากระบบในบริการหนึ่ง การออกจากระบบ Front-channel ของ OIDC กำหนดให้ IdP ต้องฝัง iframe ของคู่สัญญา (RP) หลายรายการที่อาศัยคุกกี้ของ RP

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

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

เส้นทางของผู้ใช้อื่นๆ

เส้นทางของผู้ใช้ที่ไม่ได้ใช้คุกกี้ของบุคคลที่สามจะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงวิธีจัดการคุกกี้ของบุคคลที่สามใน Chrome โซลูชันที่มีอยู่ เช่น การลงชื่อเข้าใช้ การลงชื่อออก หรือการกู้คืนบัญชีภายในบริบทของบุคคลที่หนึ่ง 2FA ควรทำงานได้ตามที่ต้องการ มีการอธิบายจุดที่เกิดความเสียหายที่อาจเกิดขึ้นก่อนหน้านี้แล้ว ดูข้อมูลเพิ่มเติมเกี่ยวกับ API หนึ่งๆ ได้ที่หน้าสถานะ API รายงานปัญหาการหยุดทำงานที่พบที่ goo.gle/report-3pc-broken นอกจากนี้ คุณยังส่งแบบฟอร์มความคิดเห็นหรือแจ้งปัญหาใน GitHub ได้ที่ที่เก็บข้อมูลการสนับสนุนนักพัฒนาซอฟต์แวร์ของ Privacy Sandbox

ตรวจสอบเว็บไซต์

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