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

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

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

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

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

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

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

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

API ทางเลือกที่แนะนำสำหรับ Use Case ทั่วไป

ในตารางยังอยู่ในช่วงเริ่มต้นของการพัฒนา ความคิดเห็นของคุณมี คุณค่าและจะช่วยกำหนดอนาคตของครีเอเตอร์ แสดงความคิดเห็นเกี่ยวกับ API Partitioned Popins

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

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

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

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

• การลงทะเบียนผู้ใช้: การสร้างบัญชีใหม่ทำงานได้ตามปกติ หากใช้ผู้ให้บริการข้อมูลประจำตัวบุคคลที่สาม ให้ตรวจสอบว่าการลงทะเบียนบัญชีใหม่ ใช้งานได้กับการผสานรวมทุกรายการ
• การกู้คืนรหัสผ่าน: การกู้คืนรหัสผ่านทำงานได้ตามที่คาดไว้ ตั้งแต่ 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ป๊อปอัปจะตั้งค่าคุกกี้ของบุคคลที่หนึ่ง อย่างไรก็ตาม 3-party-app.example iframe ที่ฝังอยู่ใน top-level.example จะได้รับการแบ่งพาร์ติชันและไม่สามารถเข้าถึงคุกกี้ที่ตั้งค่าไว้ในบริบทของบุคคลที่หนึ่งใน 3-party-app.example

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

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

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

อีกโซลูชันหนึ่งที่เสนอสำหรับโฟลว์นี้คือ Partitioned Popins ซึ่งอยู่ระหว่างการใช้งาน

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

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

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

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

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

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

ตัวอย่างเช่น ผู้ใช้อาจเข้าสู่ระบบ website.example ซึ่งฝังวิดเจ็ต subscriptions.example วิดเจ็ตนี้ช่วยให้ผู้ใช้จัดการข้อมูลของตนได้ เช่น การสมัครใช้เนื้อหาระดับพรีเมียมหรือการอัปเดตข้อมูลการเรียกเก็บเงิน หากต้องการแก้ไขข้อมูลผู้ใช้ วิดเจ็ตที่ฝังอาจต้องเข้าถึงคุกกี้ของตัวเองขณะฝังใน website.example ในกรณีที่ควรแยกข้อมูลนี้website.example CHIPS จะช่วยให้มั่นใจได้ว่า การฝังจะเข้าถึงข้อมูลที่ต้องการได้ เมื่อใช้ 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 ที่ควรเลือกใช้เพื่อจัดการเส้นทางของผู้ใช้ที่เฉพาะเจาะจง ด้วยเนื้อหาที่ฝังได้ที่คู่มือการฝัง

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

เส้นทางของผู้ใช้ที่ไม่ต้องอาศัยคุกกี้ของบุคคลที่สามไม่ควรได้รับผลกระทบจากการเปลี่ยนแปลงวิธีที่ Chrome จัดการคุกกี้ของบุคคลที่สาม โซลูชันที่มีอยู่ เช่น การลงชื่อเข้าใช้ การออกจากระบบ หรือการกู้คืนบัญชีภายในบริบทของบุคคลที่หนึ่ง, 2FA ควรทํางานตามที่ตั้งใจไว้ เราได้อธิบายจุดที่อาจเกิดการหยุดทำงาน ไปแล้ว ดูข้อมูลเพิ่มเติมเกี่ยวกับ API ที่เฉพาะเจาะจงได้ที่หน้าสถานะ API

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

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