פורסם: 8 בספטמבר 2025
מובילים בתעשייה במגוון תחומים מבינים כמה חשוב להגן על הפרטיות ולספק חוויית משתמש מצוינת. חברת Seznam מחויבת לספק חוויית משתמש ופרטיות ללא פשרות, והיא הטמיעה בהצלחה את Federated Credential Management (ניהול מאוחד של פרטי כניסה, FedCM).
חברות שיכולות להפיק תועלת מ-FedCM
ארגונים בתחומים מגוונים משלבים את FedCM בפתרונות שלהם. מכיוון ש-FedCM מיועד לניהול זהויות מאוחד, ספקי הזהויות (IdP) הם המרוויחים העיקריים ממנו. הם משתמשים במידע הזה כדי לשפר את חוויית הכניסה לחשבון. ספקי שירותי מסחר אלקטרוני וספקי תשלומים, שרבים מהם משמשים גם כספקי זהויות, מזהים גם הם הזדמנויות לשיפור חוויית המשתמש באמצעות FedCM.
Seznam
Seznam היא חברת טכנולוגיה וספקית זהויות אירופאית שמגיעה ל-90% מהאוכלוסייה בצ'כיה. הוא משמש כמרכז חברתי, מרכז ידע ומרכז תוכן. חברת Seznam הטמיעה את FedCM כדי לאפשר ללקוחות של חנויות אונליין שפועלות בפלטפורמות של השותפים שלה להיכנס באמצעות חשבון Seznam.
בעזרת FedCM, חברת Seznam השיגה עלייה משמעותית בשיעורי הכניסה של משתמשים לרשתות שותפים, שיפור בחוויית המשתמש וזרימת זהויות עקבית ללא קשר לזמינות של קובצי Cookie של צד שלישי.
למה בחרנו לעשות זאת?
חברת Seznam בחרה להטמיע את FedCM בגלל כמה יתרונות מוכרים:
- FedCM מיועד למשתמשי הקצה, ומאפשר להם לשלוט במידע שהם מספקים לספק הזהויות. ההחלטה הזו תואמת לחזון של Seznam לספק למשתמשים סביבה בטוחה ופרטית.
- FedCM היא תכונה מובנית בדפדפן והיא תואמת לחוויית הכניסה הקיימת של Seznam, שמבוססת על תקן OAuth 2.0.
- ממשק FedCM הוא גישה שממוקדת בשמירה על הפרטיות לאיחוד שירותי אימות הזהות. לדוגמה, הביקור של המשתמש בצד המסתמך (RP) משותף רק עם ספק הזהויות (IdP) אם המשתמש נכנס לחשבון. הגישה הזו תואמת לגישה של Seznam לעסקים בני קיימא.
פרטי ההטמעה
חברת Seznam הטמיעה את FedCM כשכבה מעל פתרון ה-OAuth הקיים שלה. בארכיטקטורה הזו, תהליך FedCM מעביר באופן מאובטח קוד הרשאה של OAuth מה-IdP אל ה-RPs.
מאמץ ההטמעה
ההטמעה של FedCM הייתה פשוטה עבור Seznam והתאימה לגישה הקיימת שלה. המחקר וההטמעה של ה-API נמשכו חודש ודרשו שני מפתחים. הטמענו את FedCM בסביבת הייצור תוך פחות מחודשיים. התהליך היה איטרטיבי, והקדשנו זמן רב ללימוד ה-API.
אתגרים
חברת Seznam הייתה בין המאמצות הראשונות של ה-API, זיהתה כמה אתגרים וסיפקה משוב חשוב שעזר לשפר את ה-API.
תמיכה בכמה ספקי זהויות
חברת Seznam התעניינה בתמיכה של FedCM בספקי זהויות מרובים. התכונה הזו נועדה לאפשר למשתמשים לבחור בין חשבונות Seznam או חשבונות Google בדפי כניסה של שותפים. עם זאת, כש-Seznam התחילה להטמיע את FedCM, התכונה הייתה בשלב מוקדם של הטמעה, והמפתחים נדרשו להירשם לניסיון מקור ולהשתמש בטוקן כדי להפעיל את התכונה למשתמשים. לכן, בחברת Seznam החליטו להמתין עד שהתכונה תושק בגרסה היציבה של Chrome.
התכונה זמינה החל מגרסה Chrome 136, ומפתחים יכולים להגדיר תמיכה בכמה ספקי זהויות. לדוגמה, כדי לתמוך גם בספק הזהויות Seznam וגם בספק הזהויות של Google, ספק הזהויות יכול לכלול את שני הספקים בקריאה אחת של get(), וסומך הצדדים יכול לעשות זאת באופן עצמאי:
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// 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: קובץ לדוגמהwell-knownבסביבת הייצור. -
login.dev.idp.example: דומיין פיתוח לדוגמה. -
login.dev.idp.example/.well-known/web-identity: קובץ לדוגמהwell-knownבסביבת פיתוח.
כשיישום FedCM מתארח בדומיין פרטי, בקשות של הדפדפן לקובץ well-known גורמות לשגיאה הזו:
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
כדי לפתור את השגיאה הזו, צריך להפעיל את התכונה הניסיונית #fedcm-without-well-known-enforcement ב-Chrome. כשהדגל הזה מופעל, הדפדפן מדלג על אחזור קובץ well-known למטרות בדיקה. איך מפעילים תכונות ניסיוניות ב-Chrome
גילוי נאות בהתאמה אישית
בנוסף, חברת Seznam רצתה לכלול מידע נוסף לצד עיצוב ממשק המשתמש הראשוני של FedCM. בתיבת הדו-שיח הרגילה של FedCM מוצגת למשתמש הודעה קבועה, שבה מצוין שנתונים ספציפיים – בדרך כלל תמונת הפרופיל, השם וכתובת האימייל של המשתמש – משותפים עם ה-RP.
צוות FedCM שילב משוב והרחיב את ה-API כדי לאפשר התאמה אישית של הגילוי הנאות שמוצג למשתמש. לדוגמה, באמצעות התכונה 'המשך', ספק ה-IdP יכול להפנות את המשתמש לדף מותאם אישית כדי לבקש מידע או הרשאות נוספים. פרמטרים מותאמים אישית ושדות, שנתמכים החל מ-Chrome 132, מאפשרים התאמה אישית נוספת.
אימות המקור של הצד המסתמך
שרת ה-IdP צריך לאמת את כותרת ה-HTTP Origin בבקשת FedCM נכנסת, כדי לוודא שהבקשה תואמת למקור שספק ה-RP רשם מראש ב-IdP. כך מוודאים שבקשת הצהרת הזהות של FedCM מגיעה מ-RP מורשה, ולא מתוקף שמשתמש ב-client_id.
יש מקרה קצה ב-Seznam: כשספקי זהויות שותפים נרשמים ב-Seznam, המערכת לא מבקשת את נתוני המקור של ספק הזהויות. המשמעות היא שלא ניתן לאמת את המקור של ספק הזהויות.
השילוב של FedCM ב-Seznam מתבסס על פתרון OAuth קיים. הוא בחר בדרך החלופית של אימות גם של client_id וגם של client_secret כדי לוודא שהפתרון יישאר מאובטח בלי לבדוק את המקור.
דומיין שגלוי למשתמשים של ספק הזהויות
תשתית אימות המשתמשים של Seznam פועלת בעיקר בדומיין szn.cz, שבו מתארחות נקודות הקצה של ספק הזהויות שנדרשות ל-FedCM. עם זאת, הזהות התאגידית העיקרית שלה והדומיין שדרכו המשתמשים מזהים את השירותים שלה וסומכים עליהם הם seznam.cz.
בתיבת הדו-שיח של FedCM מוצג דומיין המקור בפועל של נקודות הקצה של IdP: szn.cz. משתמשים שמכירים את המותג seznam.cz עלולים להתבלבל ולהסס כשהם מתבקשים להיכנס באמצעות הדומיין szn.cz, שהוא פחות מוכר להם, במהלך תהליך הכניסה.
החל מ-Chrome 141, FedCM לא מאפשר להציג דומיין ששונה מהדומיין שמארח את ההטמעה של ספק הזהויות. ההגבלה הזו היא בחירה מכוונת שנועדה להבטיח שקיפות כלפי המשתמשים. עם זאת, צוות FedCM מודע לאתגרים שהמגבלה הזו עלולה ליצור, ודן בהתאמות אפשריות.
השפעה
בעזרת FedCM API, Seznam יכולה לספק עכשיו למשתמשים שותפים תהליכי הרשאה בלחיצה אחת. המאמר הדגיש את היתרונות של חוויית המשתמש ב-FedCM בהשוואה לשיטות אימות אחרות.
ב-Seznam ציינו עלייה משמעותית במעורבות המשתמשים באתרים שעברו לכניסה באמצעות FedCM, אבל לא ביצעו ניתוח מקיף כדי לבודד את ההשפעה הישירה המדויקת מגורמים אחרים. לפני השילוב של FedCM, ההטמעה אפשרה למשתמשים אורחים לבצע תשלום באמצעות כתובות אימייל מגובבות שהמשתמשים הסכימו לשתף לצורך זיהוי. האתגר בביצוע ניתוח כזה היה להעריך אם אפשר לשייך המרה של משתמש ל-FedCM, או אם המשתמש היה משלים רכישה באמצעות תשלום כאורח. ההשערה של Seznam היא שהשיפורים בשימוש ב-FedCM תרמו לשיעור ההמרה הגבוה יותר הזה.
סיכום
חברת Seznam הטמיעה בהצלחה את FedCM, והיא מספקת תהליך הרשאה חלופי לצד פתרון OAuth הקיים שלה. למרות ש-Seznam נתקלה בכמה אתגרים שקשורים לתמיכה בספקי זהויות, להגדרות DNS פרטיות, להתאמה אישית של טקסט הגילוי הנאות, לאימות המקור של הצד המסתמך ולתצוגת הדומיין שגלוי למשתמשים, מאז ההטמעה של ה-API הוא עבר שיפורים משמעותיים. צוות FedCM שילב משוב מ-Seznam וממשתמשים מוקדמים אחרים, וכך יצר כלים טובים יותר להתמודדות עם האתגרים האלה. בשלב הבא, Seznam מתכננת להטמיע תמיכה ב-FedCM בכמה ספקי זהויות