Chrome เสนอประสบการณ์การใช้งานแบบใหม่สำหรับตัวเลือกของผู้ใช้ด้วยคุกกี้ของบุคคลที่สาม คุณต้องเตรียมเว็บไซต์ให้พร้อมสําหรับผู้ใช้ที่เลือกท่องเว็บโดยไม่มีคุกกี้ของบุคคลที่สาม
ในหน้านี้ คุณจะเห็นข้อมูลเกี่ยวกับสถานการณ์ข้อมูลประจำตัวที่มีแนวโน้มจะได้รับผลกระทบมากที่สุด รวมถึงข้อมูลอ้างอิงเกี่ยวกับวิธีแก้ปัญหาที่เป็นไปได้
หากเว็บไซต์จัดการเฉพาะขั้นตอนภายในโดเมนและโดเมนย่อยเดียวกัน เช่น publisher.example และ login.publisher.example เว็บไซต์จะไม่ใช้คุกกี้ข้ามเว็บไซต์ และขั้นตอนลงชื่อเข้าใช้จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงคุกกี้ของบุคคลที่สาม
อย่างไรก็ตาม หากเว็บไซต์ใช้โดเมนแยกต่างหากสำหรับการเข้าสู่ระบบ เช่น ใช้Google Sign-in หรือ Facebook Login หรือเว็บไซต์ต้องแชร์การตรวจสอบสิทธิ์ผู้ใช้ในหลายโดเมนหรือโดเมนย่อย คุณอาจต้องทําการเปลี่ยนแปลงเว็บไซต์เพื่อให้การเปลี่ยนจากคุกกี้ข้ามเว็บไซต์เป็นไปอย่างราบรื่น
เส้นทางของผู้ใช้ที่พบบ่อย
ก่อนหน้านี้เวิร์กโฟลว์การระบุตัวตนจำนวนมากใช้คุกกี้ของบุคคลที่สาม ตารางแสดงเส้นทางของผู้ใช้ที่พบบ่อยและโซลูชันที่เป็นไปได้สำหรับแต่ละเส้นทาง ซึ่งไม่ใช้คุกกี้ของบุคคลที่สาม ส่วนต่อไปนี้จะอธิบายเหตุผลของคําแนะนําเหล่านี้
API อื่นๆ ที่แนะนําสําหรับ Use Case ที่พบบ่อย
| เส้นทางของผู้ใช้ | API ที่แนะนํา |
|---|---|
| การลงชื่อเข้าใช้ด้วยบัญชีโซเชียล |
สําหรับผู้ให้บริการข้อมูลประจําตัว: ใช้ FedCM สําหรับบุคคลที่เชื่อถือ: ติดต่อผู้ให้บริการข้อมูลประจําตัว |
| การออกจากระบบของช่องด้านหน้า | สําหรับผู้ให้บริการข้อมูลประจําตัว ให้ติดตั้งใช้งาน FedCM |
|
สําหรับผู้ให้บริการข้อมูลประจําตัวหรือโซลูชันที่กําหนดเอง ให้ใช้ชุดเว็บไซต์ที่เกี่ยวข้อง |
|
| การจัดการโปรไฟล์ผู้ใช้ |
Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM + SAA |
|
Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM + SAA |
|
| การตรวจสอบสิทธิ์ |
Storage Access API FedCM Web Authentication API scienceป๊อปอัปที่มีการแบ่งพาร์ติชัน |
| โดยทั่วไปแล้ว สถานการณ์เหล่านี้จะไม่ใช้คุกกี้ของบุคคลที่สามและคาดว่าจะไม่ได้รับผลกระทบ |
ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับข้อมูลประจำตัว
วิธีที่ดีที่สุดในการทดสอบว่าขั้นตอนการลงชื่อเข้าใช้ได้รับผลกระทบจากการเปลี่ยนแปลงคุกกี้ของบุคคลที่สามหรือไม่คือการทําตามขั้นตอนการลงทะเบียน การกู้คืนรหัสผ่าน การลงชื่อเข้าใช้ และการออกจากระบบโดยเปิดใช้การแจ้งว่ากำลังทดสอบคุกกี้ของบุคคลที่สาม
ต่อไปนี้เป็นรายการสิ่งที่ต้องตรวจสอบเมื่อคุณจํากัดคุกกี้ของบุคคลที่สามแล้ว
- การลงทะเบียนผู้ใช้: การสร้างบัญชีใหม่ทํางานได้ตามปกติ หากใช้ผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม ให้ตรวจสอบว่าการลงทะเบียนบัญชีใหม่ใช้งานได้กับการผสานรวมทุกรายการ
- การกู้คืนรหัสผ่าน: การกู้คืนรหัสผ่านทำงานได้ตามที่คาดไว้ ตั้งแต่ UI ของเว็บ CAPTCHA ไปจนถึงการรับอีเมลสำหรับการกู้คืนรหัสผ่าน
- การลงชื่อเข้าใช้: เวิร์กโฟลว์การลงชื่อเข้าใช้จะทำงานภายในโดเมนเดียวกันและเมื่อไปยังโดเมนอื่น อย่าลืมทดสอบการผสานรวมการลงชื่อเข้าใช้ทุกรายการ
- การออกจากระบบ: กระบวนการออกจากระบบทำงานได้ตามที่คาดไว้ และผู้ใช้จะยังคงออกจากระบบหลังจากขั้นตอนการออกจากระบบ
นอกจากนี้ คุณควรทดสอบว่าฟีเจอร์อื่นๆ ของเว็บไซต์ที่ต้องมีการลงชื่อเข้าใช้ของผู้ใช้ยังคงทํางานได้โดยไม่ต้องใช้คุกกี้ข้ามเว็บไซต์ โดยเฉพาะในกรณีที่เกี่ยวข้องกับการโหลดทรัพยากรข้ามเว็บไซต์ เช่น หากคุณใช้ CDN เพื่อโหลดรูปโปรไฟล์ผู้ใช้ ให้ตรวจสอบว่า 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 แต่มีการแบ่งพาร์ติชันและเข้าถึงไม่ได้ภายใน 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 เพื่อการทำงานร่วมกัน เราขอแนะนําให้ทดสอบเว็บไซต์โดยเปิดใช้การแจ้งว่ากําลังทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม และหากจําเป็น ให้ใช้รายการตรวจสอบการย้ายข้อมูล 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 ที่ควรเลือกเพื่อจัดการเส้นทางของผู้ใช้ที่เฉพาะเจาะจงซึ่งมีเนื้อหาที่ฝังได้ที่คู่มือการฝัง
ออกจากระบบในช่องทางด้านหน้า
การออกจากระบบช่องทางด้านหน้าเป็นกลไกที่ช่วยให้ผู้ใช้ออกจากระบบแอปที่เกี่ยวข้องทั้งหมดได้เมื่อออกจากระบบในบริการหนึ่ง การออกจากระบบในช่องทางด้านหน้าของ OIDC กำหนดให้ IdP ต้องฝัง iframe ของบุคคลที่เชื่อถือ (RP) หลายรายการซึ่งใช้คุกกี้ของ RP
หากโซลูชันของคุณใช้ผู้ให้บริการข้อมูลประจำตัว คุณอาจต้องทำการเปลี่ยนแปลงเล็กน้อย (เช่น การอัปเกรดไลบรารี) โปรดติดต่อผู้ให้บริการข้อมูลประจำตัวเพื่อขอคำแนะนำเพิ่มเติม
FedCM ได้ทดสอบฟีเจอร์ logoutRPs เพื่อจัดการกับกรณีการใช้งานนี้ ซึ่งช่วยให้ IdP ออกจากระบบ RP ทั้งหมดที่ผู้ใช้เคยอนุมัติการสื่อสารระหว่าง RP กับ IdP ไว้ก่อนหน้านี้ได้ ฟีเจอร์นี้ไม่มีให้บริการแล้ว แต่เราขอแนะนำให้คุณดูข้อเสนอเริ่มต้นและแชร์ความคิดเห็นกับเราหากคุณสนใจหรือต้องการฟีเจอร์นี้
เส้นทางของผู้ใช้อื่นๆ
เส้นทางของผู้ใช้ที่ไม่ได้ใช้คุกกี้ของบุคคลที่สามจะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงวิธีจัดการคุกกี้ของบุคคลที่สามใน Chrome โซลูชันที่มีอยู่ เช่น การลงชื่อเข้าใช้ การลงชื่อออก หรือการกู้คืนบัญชีภายในบริบทของบุคคลที่หนึ่ง 2FA ควรทำงานได้ตามที่ต้องการ เราได้อธิบายจุดที่อาจเกิดข้อขัดข้องไว้ก่อนหน้านี้แล้ว ดูข้อมูลเพิ่มเติมเกี่ยวกับ API หนึ่งๆ ได้ที่หน้าสถานะ API รายงานปัญหาการหยุดทำงานที่พบที่ goo.gle/report-3pc-broken นอกจากนี้ คุณยังส่งแบบฟอร์มความคิดเห็นหรือแจ้งปัญหาใน GitHub ได้ที่ที่เก็บข้อมูลการสนับสนุนนักพัฒนาซอฟต์แวร์ของ Privacy Sandbox
ตรวจสอบเว็บไซต์
หากเว็บไซต์ของคุณใช้เส้นทางของผู้ใช้อย่างใดอย่างหนึ่งที่อธิบายไว้ในคู่มือนี้ คุณต้องตรวจสอบว่าเว็บไซต์พร้อมใช้งาน โดยตรวจสอบเว็บไซต์เพื่อหาการใช้คุกกี้ของบุคคลที่สาม ทดสอบเพื่อหาข้อบกพร่อง และเปลี่ยนไปใช้โซลูชันที่แนะนํา