מובילים בתעשייה במגוון תחומים מבינים כמה חשוב להגן על הפרטיות תוך כדי מתן חוויה מצוינת לכל המשתמשים שלהם. חברת 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 אל ה-RP.
מאמץ ההטמעה
ב-Seznam ציינו שההטמעה של FedCM הייתה פשוטה, והיא תאמה לגישה הקיימת שלהם. המחקר וההטמעה של ה-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'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
כדי לפתור את השגיאה הזו, צריך להפעיל את התכונה הניסיונית #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 מגיעה מצד שלישי מורשה, ולא מתוקף שמשתמש ב-client_id.
ב-Seznam יש מקרה קצה: כששותפי RP נרשמים ב-Seznam, הם לא מבקשים את נתוני המקור של ה-RP. המשמעות היא שלא ניתן לאמת את המקור של ספק הזהויות.
האינטגרציה של Seznam עם FedCM מבוססת על פתרון 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 בכמה ספקי זהויות.