วิธีที่ adidas เร่งการใช้งานและความน่าเชื่อถือของพาสคีย์ด้วย Conditional Create และ Signal API

Christopher Kokott

Yu Tsuno

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

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

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

ผลลัพธ์

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

• อัตราการนำไปใช้สูง: นับตั้งแต่เปิดตัวกระบวนการลงชื่อเข้าใช้ด้วยพาสคีย์ adidas มีอัตราการสร้างพาสคีย์โดยรวมอยู่ที่ 47% ซึ่งรวมถึงการสร้างแบบมีเงื่อนไขอัตโนมัติและการเลือกใช้ที่ผู้ใช้เริ่มต้นเมื่อได้รับแจ้งระหว่างขั้นตอนการลงชื่อสมัครใช้หรือลงชื่อเข้าใช้ การนำไปใช้ดังกล่าวสูงเป็นพิเศษในอุปกรณ์เคลื่อนที่ ซึ่งมีอัตรา Conversion 52% (เทียบกับ 34% ในเดสก์ท็อป)
• การอัปเกรดที่รวดเร็วขึ้นโดยใช้การสร้างแบบมีเงื่อนไข: นอกเหนือจากพรอมต์ที่ชัดเจนแล้ว adidas ยังสร้างพาสคีย์ได้เพิ่มขึ้น 8% โดยการ อัปเกรดผู้ใช้ที่ใช้รหัสผ่านอยู่เบื้องหลังอย่างราบรื่นโดยไม่ต้องให้ผู้ใช้ดำเนินการด้วยตนเอง
• ความน่าเชื่อถือในการลงชื่อเข้าใช้ที่เกือบสมบูรณ์แบบ: พาสคีย์มีอัตราความสำเร็จมากกว่า 99% เมื่อเริ่มการลงชื่อเข้าใช้ การอัปเกรดนี้เป็นการอัปเกรดด้านความปลอดภัยครั้งสำคัญ เมื่อเทียบกับอัตราความสำเร็จของรหัสผ่านในอดีตของ adidas ที่ 70% ซึ่ง มักจะลดลงเนื่องจากข้อผิดพลาดของมนุษย์ เช่น การพิมพ์ผิดหรือลืมข้อมูลเข้าสู่ระบบ
• ลดความยุ่งยากและข้อผิดพลาด: การติดตั้งใช้งาน Signal API เพื่อซิงค์ข้อมูลเข้าสู่ระบบของอุปกรณ์และเซิร์ฟเวอร์โดยอัตโนมัติช่วยให้ adidas สามารถควบคุมข้อผิดพลาด PASSKEY_NOT_FOUND ให้ต่ำกว่า 0.3% ของการพยายามลงชื่อเข้าใช้ได้ ซึ่ง ช่วยลดความหงุดหงิดของผู้ใช้จากพาสคีย์ที่ไม่มีเจ้าของได้อย่างมีประสิทธิภาพ

47 _%

อัตราการสร้างพาสคีย์

8 _%

การสร้างพาสคีย์เพิ่มขึ้นโดยใช้การสร้างแบบมีเงื่อนไข

>99 _%

อัตราความสำเร็จในการลงชื่อเข้าใช้ด้วยพาสคีย์เมื่อเริ่มแล้ว

<0.3 _%

อัตราข้อผิดพลาดของพาสคีย์ที่ไม่มีบัญชีหลัก

วิธีที่ adidas แก้ปัญหา

Adidas แก้ไขความท้าทายเหล่านี้อย่างไร

1. เร่งการใช้งานด้วยการสร้างแบบมีเงื่อนไข

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

const cred = await navigator.credentials.create({
  publicKey: options,
  mediation: 'conditional' // Enables automatic passkey creation
});

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

หากสภาพแวดล้อมเข้ากันได้ ระบบจะพยายามสร้างพาสคีย์ในเบื้องหลังทันทีหลังจากที่ผู้ใช้ตรวจสอบสิทธิ์สำเร็จ การกำหนดเวลาที่เฉพาะเจาะจงนี้จะช่วยเพิ่มโอกาสในการปฏิบัติตามข้อกำหนดเบื้องต้น ที่สำคัญคือ การติดตั้งใช้งานจะจัดการข้อยกเว้นของ WebAuthn ตามปรัชญา "เปิดให้เข้าถึง" เพื่อ ให้ความสำคัญกับการเข้าถึงของผู้ใช้เสมอ หากเบราว์เซอร์รายงาน InvalidStateError ซึ่งบ่งชี้ว่ามีพาสคีย์อยู่แล้ว ระบบจะหยุดการสร้างในเบื้องหลัง และลงชื่อเข้าใช้ให้ผู้ใช้ทันที ในทางกลับกัน หากเกิด NotAllowedError ซึ่งหมายความว่าระบบไม่เป็นไปตามเงื่อนไขที่เฉพาะเจาะจงสำหรับการสร้างอัตโนมัติ ระบบจะตรวจพบสถานะนี้และนำผู้ใช้ไปยังหน้าจอ "เครื่องมือรวบรวมพาสคีย์" เพื่อแนะนำขั้นตอนการตั้งค่าด้วยตนเอง การแยกความแตกต่างระหว่างข้อจำกัดทางเทคนิคและพฤติกรรมของผู้ใช้เหล่านี้ช่วยให้ adidas มั่นใจได้ว่าการผลักดันให้อัปเกรดพาสคีย์จะช่วยปรับปรุงประสบการณ์การลงชื่อเข้าใช้แทนที่จะขัดขวาง

หน้าจอ "ตัวรวบรวมพาสคีย์"

2. รับประกันความน่าเชื่อถือด้วย Signal API

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

adidas ใช้เมธอด Signal API ทั้ง 3 แบบที่มีอยู่เพื่อรักษาความสอดคล้องนี้ adidas จะเชื่อมโยงเหตุการณ์วงจรของผู้ใช้ที่เฉพาะเจาะจงกับการเรียก API ที่เหมาะสมแทนที่จะคาดเดาว่าควรนำข้อมูลเข้าสู่ระบบใดออก

• การลงทะเบียนไม่สำเร็จ: เมื่อสร้างพาสคีย์ในไคลเอ็นต์แต่ลงทะเบียนในแบ็กเอนด์ไม่สำเร็จ adidas จะใช้ signalUnknownCredential เพื่อนำข้อมูลเข้าสู่ระบบที่ไม่มีเจ้าของออกทันที
• การลงชื่อเข้าใช้ที่ไม่ถูกต้อง: หากผู้ใช้พยายามลงชื่อเข้าใช้ด้วยพาสคีย์ที่ถูกเพิกถอนหรือ ล้าสมัย signalUnknownCredential จะส่งสัญญาณให้ผู้ให้บริการซ่อนพาสคีย์นั้น
• การจัดการผู้ใช้: เมื่อผู้ใช้นำพาสคีย์ออกอย่างชัดเจนในการตั้งค่าบัญชี signalAllAcceptedCredentials จะซิงค์รายการที่อนุญาต ซึ่งจะช่วยให้มั่นใจได้ว่าจะไม่มีการเสนอพาสคีย์ที่ลบไปแล้วอีก
• การอัปเดตบัญชี: เมื่อผู้ใช้เปลี่ยนอีเมลหรือชื่อผู้ใช้ signalCurrentUserDetails จะอัปเดตข้อมูลเมตาในอุปกรณ์ให้ตรงกับเซิร์ฟเวอร์

// Detect authentication failure due to lack of the credential

if (result.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "adidas.com",
      credentialId: "..." // base64url encoded credential ID
    });
  }
}

โมดอลการยืนยันสำหรับการนำพาสคีย์ออก

การแจ้งเตือน Signal API สำหรับพาสคีย์ที่ถูกลบ

3. รวมการเข้าถึงด้วยคำขอต้นทางที่เกี่ยวข้องและลิงก์ไปยังเนื้อหาดิจิทัล

adidas ได้ใช้คำขอที่มาจากต้นทางที่เกี่ยวข้องเพื่อรองรับสถาปัตยกรรมแบบหลายตลาด แม้ว่าผู้ใช้ส่วนใหญ่จะ ใช้เว็บไซต์ในประเทศของตน (เช่น adidas.nl) แต่การกำหนดค่านี้ จะช่วยให้ผู้ใช้ที่ไปยังส่วนต่างๆ ของภูมิภาคสามารถใช้พาสคีย์ซ้ำในโดเมนที่อนุญาตได้ โดยกำหนดเป้าหมายไปยัง ID ของผู้ให้บริการที่เชื่อถือได้ รายเดียว (adidas.com)

หากต้องการเปิดใช้ฟีเจอร์นี้ adidas จะโฮสต์ไฟล์การกำหนดค่า webauthn ที่โดเมนรหัสผู้ให้บริการที่เชื่อถือได้ (RP ID) หลัก ไฟล์นี้มีรายการที่อนุญาตอย่างชัดเจนของ ต้นทางที่ได้รับอนุญาตให้ใช้ adidas.com สำหรับการลงทะเบียนพาสคีย์และ การตรวจสอบสิทธิ์ การกำหนดความสัมพันธ์เหล่านี้จะช่วยให้เบราว์เซอร์ยืนยันได้ว่า พาสคีย์ที่สร้างในเว็บไซต์ระดับภูมิภาคหนึ่งใช้ได้ในเว็บไซต์อื่น ซึ่งจะช่วยให้ผู้ใช้ทั่วโลกได้รับประสบการณ์การใช้งานที่ราบรื่น

// https://www.adidas.com/.well-known/webauthn

{
  "origins": [
    "https://www.adidas.fi",
    "https://www.adidas.nl",
    // ... abridged (the full file lists 50+ regional domains)
  ]
}

ที่สำคัญ adidas ยังรองรับพาสคีย์ได้อย่างราบรื่นภายในแอป Android บนอุปกรณ์เคลื่อนที่โดยใช้ลิงก์เนื้อหาดิจิทัล (Digital Asset Links) เนื่องจากแอปใช้ WebView ที่โฮสต์ใน idp.adidas.com สำหรับการตรวจสอบสิทธิ์ จึงต้องใช้ Digital Asset Links เพื่อสร้างความสัมพันธ์ที่เชื่อถือได้ระหว่างแอป Android กับ รหัส Relying Party (adidas.com) การยืนยันนี้ช่วยให้แอปเข้าถึงพาสคีย์เดียวกันกับที่ใช้บนเว็บได้ ซึ่งจะสร้างประสบการณ์การลงชื่อเข้าใช้ที่ราบรื่นและเป็นหนึ่งเดียวในแพลตฟอร์มต่างๆ

adidas จึงโฮสต์ไฟล์ลิงก์เนื้อหาดิจิทัล (Digital Asset Links) (assetlinks.json) ในโดเมนเว็บของตนเอง ไฟล์นี้จะประกาศการเชื่อมโยงทาง การเข้ารหัสกับแอปพลิเคชัน Android ของตนต่อสาธารณะ ในทำนองเดียวกัน adidas ใช้โดเมนที่เชื่อมโยงเพื่อรองรับระบบนิเวศ iOS การโฮสต์ไฟล์ apple-app-site-association จะสร้างการเชื่อมต่อที่ปลอดภัย ซึ่งช่วยให้แอป iOS ใช้พาสคีย์ใน WebView ได้อย่างปลอดภัย

// https://www.adidas.fi/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.adidas.app",
      "sha256_cert_fingerprints": [
        "B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
        "..."
      ]
    }
  },
  // ... abridged
]

แผนภาพลำดับของคำขอที่เกี่ยวข้องกับต้นทาง

การลงชื่อเข้าใช้แบบมีเงื่อนไข

ตัวระบุเป็นอันดับแรก

ก้าวต่อไปของ adidas

ด้วยรากฐานที่แข็งแกร่งของการอัปเกรดอัตโนมัติและข้อมูลเข้าสู่ระบบที่ซิงค์กันซึ่งใช้งานจริง ใน adidas.fi และ adidas.nl ทาง adidas จะใช้การตั้งค่าที่ราบรื่นนี้กับตลาดอื่นๆ ทั้งหมด ทั่วโลกภายในสิ้นเดือนเมษายน 2026 นอกจากนี้ adidas ยังกำลังสำรวจประสบการณ์การลงชื่อเข้าใช้ที่ราบรื่นยิ่งขึ้นด้วยการทดสอบการทดลองใช้ต้นทางของสื่อกลางทันที แผนในอนาคตของเราคือการอนุญาตให้ผู้ใช้สร้างบัญชีด้วยพาสคีย์โดยตรง ซึ่งจะ ยกเลิกข้อกำหนดปัจจุบันที่ต้องลงชื่อสมัครใช้ด้วยวิธีอื่นก่อน ทีมยังตรวจสอบ "การทริกเกอร์อัจฉริยะ" เพื่อเรียกใช้กล่องโต้ตอบพาสคีย์ของระบบโดยตรงในขั้นตอนที่ 2 ของการลงชื่อเข้าใช้ ซึ่งจะช่วยให้ไม่ต้องคลิกเพิ่มเติมเมื่อมีความมั่นใจสูงว่าผู้ใช้มีพาสคีย์ในอุปกรณ์ปัจจุบัน

ความสำคัญที่มีต่อคุณ

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

ดูข้อมูลเพิ่มเติม

• ช่วยให้ผู้ใช้เปลี่ยนมาใช้พาสคีย์ได้อย่างราบรื่นยิ่งขึ้นด้วยการสร้างแบบมีเงื่อนไข
• รักษาพาสคีย์ให้สอดคล้องกับ Signal API
• อนุญาตให้ใช้พาสคีย์ซ้ำในเว็บไซต์ต่างๆ ด้วยคำขอต้นทางที่เกี่ยวข้อง