איך adidas האיצה את ההטמעה של מפתחות גישה ואת המהימנות שלהם באמצעות Conditional Create ו-Signal API

Christopher Kokott

Yu Tsuno

ארגונים ומפתחים נתקלים בקושי משמעותי כשמעבירים משתמשים מסיסמאות למפתחות גישה. מפתחות גישה מספקים שדרוג אבטחה חיוני, אבל תהליך היצירה הידני שלהם עלול להיות מסורבל. בסביבת מסחר אלקטרוני עם נפח גבוה, כל שנייה של היסוס חשובה, כי כל עיכוב עלול לשבש את תהליך הרכישה ולהוביל לנטישה של עגלת קניות. בנוסף, חשוב לשמור על סנכרון של מצבי האישורים בין השרת לבין המכשיר של המשתמש כדי למנוע שגיאות בכניסה ותסכול של המשתמשים.

חברת adidas התמודדה עם האתגרים האלה בדיוק. המטרה העיקרית שלהם הייתה לשפר את תהליך הכניסה לחשבון ולפשט את חוויית השימוש בפלטפורמות ובמכשירים שונים באינטרנט ובאפליקציות. הצוות של המוצר שם דגש על אבטחה, אבל גם על יצירת תהליכי הרשמה וכניסה חלקים ככל האפשר באמצעות מפתחות גישה.

כדי להתמודד עם האתגרים האלה, adidas הטמיעה את Conditional Create כדי לשדרג באופן אוטומטי משתמשים עם סיסמאות למפתחות גישה, ואת Signal API כדי לשמור על עקביות של פרטי הכניסה. בנוסף, הם הטמיעו בקשות שקשורות למקור כדי לתמוך בשימוש חוצה דומיינים במקומות שבהם נדרש.

התוצאות

האסטרטגיה של adidas לאוטומציה של יצירת מפתחות גישה ולשמירה על תקינות פרטי הכניסה הניבה תוצאות מיידיות ומדידות גם בהטמעה וגם באמינות של הכניסה לחשבון:

• שיעור אימוץ גבוה: מאז השקת תהליך הכניסה באמצעות מפתח גישה, adidas השיגה שיעור כולל של 47% ביצירת מפתחות גישה. ההסכמה כוללת גם יצירה אוטומטית מותנית וגם הצטרפות של משתמשים בהנחיה במהלך תהליכי ההרשמה או הכניסה. שיעור ההמרה בניידים היה גבוה במיוחד – 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 שילבה את התכונה הזו עם לוגיקה מותאמת אישית שקודם מאמתת את הסביבה של המשתמש. באופן ספציפי, המערכת בודקת אם הדפדפן תומך בתכונה Conditional Create. המערכת גם מכבדת את העדפות המשתמשים, ולכן לא תציג את ההנחיה אם המשתמש דילג על יצירת מפתח גישה שלוש פעמים במהלך ששת החודשים האחרונים.

אם הסביבה תואמת, המערכת מנסה ליצור את מפתח הגישה ברקע, מיד אחרי שהמשתמש עובר אימות. התזמון הספציפי הזה מגדיל את הסיכוי שהדרישות המוקדמות יתקיימו. חשוב לציין שההטמעה מטפלת בחריגים של WebAuthn לפי העיקרון של 'כשל שמאפשר גישה', כדי לתת תמיד עדיפות לגישת המשתמש. אם הדפדפן מדווח על InvalidStateError, מה שמצביע על כך שכנראה כבר קיים מפתח גישה, המערכת מפסיקה את היצירה ברקע ומכניסה את המשתמש לחשבון באופן מיידי. לעומת זאת, אם מתרחש NotAllowedError, כלומר התנאים הספציפיים ליצירה אוטומטית לא מתקיימים, המערכת מזהה את המצב הזה ומפנה את המשתמש למסך Passkey Collector כדי להנחות אותו בתהליך הגדרה ידני. ההבחנה בין המגבלות הטכניות האלה לבין התנהגויות המשתמשים מאפשרת לחברת adidas לוודא שהמעבר לשימוש במפתחות גישה ישפר את חוויית הכניסה ולא יפריע לה.

2. שיפור האמינות באמצעות Signal API

כשמשתמשים מנהלים את פרטי הכניסה שלהם במכשירים שונים, יכולות להיווצר אי-התאמות. לדוגמה, יכול להיות שמפתח גישה יימחק מהשרת אבל יישאר במכשיר של המשתמש. כדי למנוע כשלים בכניסה שנגרמים על ידי פרטי הכניסה הפיקטיביים האלה, adidas הטמיעה את Signal API. ה-API הזה מאפשר לשרת לסמן את הסטטוס של פרטי הכניסה לספק מפתחות הגישה.

כדי לשמור על העקביות הזו, adidas משתמשת בכל שלוש השיטות הזמינות של Signal API. במקום לנחש אילו פרטי כניסה להסיר, 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
    });
  }
}

3. איחוד הגישה באמצעות בקשות ממקורות קשורים ו-Digital Asset Links

כדי לתמוך עוד יותר בארכיטקטורה שלהם בשווקים רבים, adidas הטמיעו בקשות שקשורות למקור. רוב המשתמשים נשארים בשוק המקומי שלהם (לדוגמה, adidas.nl), אבל ההגדרה הזו מאפשרת למשתמשים שעוברים בין אזורים להשתמש מחדש במפתחות גישה בדומיינים מותרים על ידי טירגוט של מזהה צד נסמך יחיד (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 לבין מזהה הצד המסתמך (adidas.com). האימות הזה מאפשר לאפליקציה לגשת לאותם מפתחות גישה שמשמשים באינטרנט, וכך ליצור חוויית כניסה חלקה ואחידה בכל הפלטפורמות.

כדי לעשות את זה, adidas מארחת קובץ Digital Asset Links ‏ (assetlinks.json) בדומיינים המתאימים של האתרים שלה. הקובץ הזה מכריז באופן פומבי על הקשר הקריפטוגרפי לאפליקציות שלהם ל-Android. באופן דומה, כדי לתמוך במערכת האקולוגית של iOS, חברת adidas משתמשת בדומיינים משויכים. אירוח קובץ apple-app-site-association מאפשר ליצור חיבור מאובטח שמאפשר לאפליקציית iOS להשתמש במפתחות גישה בתצוגת אינטרנט בצורה מאובטחת.

// 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 תבסס את השדרוגים האוטומטיים ואת נתוני הכניסה המסונכרנים באתרים adidas.fi ו-adidas.nl, היא תיישם את ההגדרה הזו בכל השווקים הגלובליים האחרים עד סוף אפריל 2026. בנוסף, אדידס בודקת את ניסוי המקור של תהליך בחירת הרשת המיידית כדי לספק חוויית כניסה חלקה עוד יותר. בתוכניות העתידיות שלנו אנחנו מתכוונים לאפשר למשתמשים ליצור חשבונות ישירות באמצעות מפתחות גישה. כך לא תהיה יותר דרישה להירשם קודם בשיטה חלופית. הצוות בודק גם אפשרות של הפעלה חכמה כדי להציג ישירות את תיבת הדו-שיח של מפתח הגישה בשלב השני של הכניסה לחשבון. כך לא צריך לבצע קליק נוסף כשבטוח שהמשתמש יכול להשתמש במפתח גישה במכשיר הנוכחי.

למה זה חשוב לכם

המעבר לאימות ללא סיסמה מצליח כשהמשתמשים ממשיכים ליהנות מחוויה חלקה. הטמעה של Conditional Create מאפשרת להעביר משתמשים מסיסמאות בקלות, בלי לשנות את ההרגלים שלהם. באמצעות בקשות שקשורות למקור, אתם יכולים לשתף את מפתחות הגישה האלה בין הדומיינים שלכם, וכך לאפשר למשתמשים לגשת לכל המערכת האקולוגית שלכם בצורה חלקה עם מפתח גישה יחיד. לבסוף, שילוב של התכונה הזו עם Signal API מבטיח שהחוויה המאוחדת שלכם ללא סיסמה תישאר מהימנה וללא שגיאות.

מידע נוסף

• עזרה למשתמשים לעבור למפתחות גישה בצורה חלקה יותר באמצעות יצירה מותנית
• שמירה על עקביות של מפתחות הגישה עם Signal API
• איך מאפשרים שימוש חוזר במפתחות גישה באתרים באמצעות בקשות ממקורות קשורים