การตรวจสอบสิทธิ์ผู้ใช้ที่ราบรื่นและเป็นส่วนตัวด้วย FedCM: การใช้งานของ Seznam

ผู้นำในอุตสาหกรรมจากหลายภาคส่วนทราบดีว่าการปกป้องความเป็นส่วนตัวมีความสำคัญเพียงใด ขณะเดียวกันก็มอบประสบการณ์การใช้งานที่ยอดเยี่ยมแก่ผู้ใช้ทุกคน Seznam มุ่งมั่นที่จะมอบประสบการณ์การใช้งานและความเป็นส่วนตัวของผู้ใช้โดยไม่ลดทอนคุณภาพ และได้ผสานรวม Federated Credential Management (FedCM) เรียบร้อยแล้ว

กลุ่มเป้าหมาย: บริษัทที่ได้รับประโยชน์จาก FedCM

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

Seznam

Seznam เป็นบริษัทเทคโนโลยีและผู้ให้บริการข้อมูลประจำตัวในยุโรปที่เข้าถึงประชากรเช็กได้ 90% โดยทำหน้าที่เป็นฮับด้านโซเชียล ความรู้ และเนื้อหา Seznam ใช้ FedCM เพื่ออนุญาตให้ลูกค้าของร้านค้าออนไลน์ที่ดำเนินการบนแพลตฟอร์มของพาร์ทเนอร์ลงชื่อเข้าใช้โดยใช้บัญชี Seznam

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

แรงจูงใจ

การตัดสินใจใช้ FedCM ของ Seznam เกิดจากข้อดีหลายประการที่พวกเขาเห็น

• FedCM ออกแบบมาโดยคำนึงถึงผู้ใช้ปลายทางเป็นหลัก เพื่อให้ผู้ใช้ควบคุมข้อมูลที่ให้แก่ IdP ได้ ซึ่งสอดคล้องกับวิสัยทัศน์ของ Seznam ที่ต้องการสร้างสภาพแวดล้อมที่ปลอดภัยและเป็นส่วนตัวสำหรับผู้ใช้
• FedCM เป็นฟีเจอร์เบราว์เซอร์ในตัวที่เข้ากันได้กับประสบการณ์การเข้าสู่ระบบที่มีอยู่ของ Seznam ซึ่งใช้มาตรฐาน OAuth 2.0
• FedCM ออกแบบมาให้เป็นแนวทางที่มุ่งเน้นความเป็นส่วนตัวในการรวมศูนย์ข้อมูลระบบตัวตน ตัวอย่างเช่น ระบบจะแชร์ข้อเท็จจริงที่ว่าผู้ใช้เข้าชม Relying Party (RP) กับ IdP ก็ต่อเมื่อผู้ใช้เลือกที่จะลงชื่อเข้าใช้เท่านั้น ซึ่งสอดคล้องกับมุมมองของ Seznam เกี่ยวกับธุรกิจที่ยั่งยืน

รายละเอียดการติดตั้งใช้งาน

Seznam ใช้ FedCM เป็นเลเยอร์ที่อยู่เหนือโซลูชัน OAuth ที่มีอยู่ ในสถาปัตยกรรมนี้ ระบบจะใช้ขั้นตอน FedCM เพื่อส่งรหัสการให้สิทธิ์ OAuth จาก IdP ไปยัง RP อย่างปลอดภัย

ความพยายามในการติดตั้งใช้งาน

Seznam เน้นย้ำว่าการใช้งาน FedCM นั้นไม่ซับซ้อนและสอดคล้องกับแนวทางที่มีอยู่ การวิจัยและการติดตั้งใช้งาน API ของพวกเขาใช้เวลา 1 เดือนและต้องใช้ ความพยายามของนักพัฒนาแอป 2 คน โดยใช้เวลาไม่ถึง 2 เดือนในการนำ FedCM ไปใช้จริง กระบวนการนี้เป็นการทำซ้ำ โดยใช้เวลาอย่างมากในการศึกษา API อย่างละเอียด

ความท้าทาย

ในฐานะผู้ใช้รุ่นแรก Seznam ได้ระบุความท้าทายหลายประการและให้ความคิดเห็นที่มีคุณค่าซึ่งช่วยพัฒนา API

รองรับผู้ให้บริการข้อมูลประจำตัวหลายราย

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

ฟีเจอร์นี้พร้อมใช้งานใน Chrome 136 และนักพัฒนาซอฟต์แวร์สามารถกำหนดค่าการรองรับผู้ให้บริการข้อมูลประจำตัวหลายรายได้ ตัวอย่างเช่น หากต้องการรองรับทั้งผู้ให้บริการข้อมูลประจำตัว Seznam และ Google ผู้ให้บริการข้อมูลประจำตัวสามารถ รวมผู้ให้บริการทั้ง 2 รายไว้ในการเรียกใช้ get() ครั้งเดียว และ RP ก็สามารถทำเช่นเดียวกันได้โดยอิสระ

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam's config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Also allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam ระบุว่าฟีเจอร์นี้จะเป็นส่วนหนึ่งของโซลูชัน นอกจากนี้ ทีม FedCM ยังกำลังรองรับ SDK หลายรายการ พร้อมรองรับการเรียกใช้ get() หลายรายการ

DNS ส่วนตัว

Seznam พบปัญหาเกี่ยวกับการกำหนดค่าเครือข่ายในระยะการทดสอบ เซิร์ฟเวอร์ IdP สำหรับทดสอบของลูกค้าอยู่ในเครือข่ายส่วนตัว ซึ่งเข้าถึงได้ผ่าน DNS ส่วนตัวเท่านั้น การตั้งค่านี้มักใช้กับสภาพแวดล้อมในการทดสอบและการพัฒนาภายในก่อนที่จะเปิดเผยบริการต่อสาธารณะ

อย่างไรก็ตาม การตั้งค่านี้ทำให้เกิดความท้าทายเนื่องจากต้องแสดงไฟล์ well-known จาก eTLD+1 และโดเมนการพัฒนาส่วนตัวไม่ได้ลงทะเบียนในรายการคำต่อท้ายสาธารณะ เบราว์เซอร์จึงไม่ส่งคำขอเพื่อดึงข้อมูลไฟล์ well-known ที่โฮสต์ในโดเมนการพัฒนา

• login.idp.example: โดเมนการผลิตตัวอย่าง
• idp.example/.well-known/web-identity: ตัวอย่างไฟล์ที่รู้จักกันดีในการใช้งานจริง
• login.dev.idp.example: โดเมนการพัฒนาตัวอย่าง
• login.dev.idp.example/.well-known/web-identity: ตัวอย่างไฟล์ที่รู้จักกันดีในสภาพแวดล้อมการพัฒนา

เมื่อการติดตั้งใช้งาน FedCM โฮสต์อยู่ในโดเมนส่วนตัว คำขอของเบราว์เซอร์ไปยังไฟล์ well-known จะทำให้เกิดข้อผิดพลาดนี้

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

คุณแก้ไขข้อผิดพลาดนี้ได้โดยเปิดใช้ Flag #fedcm-without-well-known-enforcement ของ Chrome เมื่อเปิดใช้ฟีเจอร์นี้ เบราว์เซอร์จะไม่ดึงข้อมูลไฟล์ well-known เพื่อวัตถุประสงค์ในการทดสอบ ดูวิธีเปิดใช้ฟีเจอร์ทดลองใน Chrome

การเปิดเผยข้อมูลที่กำหนดเอง

นอกจากนี้ Seznam ยังแชร์ว่าต้องการรวมข้อมูลเพิ่มเติมไว้ข้างๆ การออกแบบเริ่มต้น ของ UI ของ FedCM กล่องโต้ตอบ FedCM มาตรฐานจะแสดงข้อความที่แก้ไขแล้วต่อผู้ใช้ โดยระบุว่าระบบกำลังแชร์ข้อมูลที่เฉพาะเจาะจง ซึ่งโดยปกติคือรูปโปรไฟล์ ชื่อ และอีเมลของผู้ใช้ กับ RP

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

การตรวจสอบต้นทางของ Relying Party

เซิร์ฟเวอร์ IdP ต้องตรวจสอบส่วนหัว HTTP Origin ในคำขอ FedCM ขาเข้าเพื่อให้แน่ใจว่าคำขอตรงกับต้นทางที่ RP ลงทะเบียนล่วงหน้ากับ IdP ซึ่งจะช่วยให้มั่นใจได้ว่าคำขอการยืนยัน ID ของ FedCM มาจาก RP ที่ได้รับอนุญาต ไม่ใช่จากผู้โจมตีที่ใช้ client_id

Seznam มีกรณีพิเศษคือ เมื่อ RP พาร์ทเนอร์จดทะเบียนกับ Seznam พาร์ทเนอร์จะไม่ ขอข้อมูลต้นทางของ RP ซึ่งหมายความว่ายืนยันแหล่งที่มาของ RP ไม่ได้

การผสานรวม FedCM ของ Seznam สร้างขึ้นบนโซลูชัน OAuth ที่มีอยู่ โดยเลือกใช้เส้นทางอื่น ในการตรวจสอบทั้ง client_id และ client_secret ของ RP เพื่อให้มั่นใจว่าโซลูชันจะยังคง ปลอดภัยโดยไม่ต้องตรวจสอบต้นทาง

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

โครงสร้างพื้นฐานการตรวจสอบสิทธิ์ผู้ใช้ของ Seznam ทำงานในโดเมน szn.cz เป็นหลัก ซึ่งเป็นที่ตั้งของปลายทาง IdP ที่จำเป็นสำหรับ FedCM อย่างไรก็ตาม ตัวตนหลักของบริษัทและ โดเมนที่ผู้ใช้รู้จักและเชื่อถือบริการของบริษัทอย่างกว้างขวางคือ seznam.cz

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

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

ผลกระทบ

FedCM API ช่วยให้ Seznam สามารถมอบโฟลว์การให้สิทธิ์แบบแตะครั้งเดียวแก่ผู้ใช้ของพาร์ทเนอร์ได้แล้ว โดยเน้นย้ำถึงประโยชน์ที่ UX ของ FedCM มอบให้เมื่อเทียบกับวิธีการตรวจสอบสิทธิ์อื่นๆ

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

บทสรุป

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