סקירה כללית על Federated Credential Management API

ממשק API לאינטרנט לאיחוד שירותי אימות הזהות תוך שמירה על פרטיות.

מהו FedCM?

FedCM (ניהול מאוחד של פרטי כניסה) הוא גישה לשמירה על הפרטיות בשירותי אימות זהות מאוחדים (כמו 'כניסה באמצעות…') שלא מסתמכת על קובצי cookie של צד שלישי או על הפניות אוטומטיות לנתיב אחר.

סטטוס ההטמעה

בהמשך, אנחנו מתכננים להציג מספר תכונות חדשות על סמך המשוב שקיבלנו מספק זהויות (IdP), מצדדים נסמכים (RP) ומספקי דפדפנים. אנחנו מקווים שספקי הזהויות יאמץ את FedCM, אבל חשוב לדעת ש-FedCM הוא עדיין ממשק API שנמצא בפיתוח פעיל.

כדי לצמצם את האתגרים של פריסה של שינויים שלא תואמים לאחור, יש לנו שתי המלצות לספקים של זהויות:

  • כדאי להירשם לניוזלטר שלנו כדי לקבל עדכונים על התפתחות ה-API.
  • אנחנו ממליצים לספקי IdP להפיץ את FedCM API באמצעות ערכות SDK של JavaScript בזמן שה-API מתפתח, ולהניא ספקי RP מאירוח עצמאי של ערכות SDK. כך תוכלו לוודא שספקי ה-IdP יוכלו לבצע שינויים ככל שה-API יתפתח, בלי לבקש מכל הגורמים המאמינים לפרוס מחדש.

למה אנחנו צריכים את FedCM?

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

באיחוד שירותי אימות הזהות, צד נסמך (RP) מסתמך על ספק זהויות (IdP) כדי לספק למשתמש חשבון בלי צורך בשם משתמש ובסיסמה חדשים.

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

Federated Credential Management API‏ (FedCM) מספק הפשטה ספציפית לתרחישי שימוש של תהליכי אימות זהות מאוחדת באינטרנט, על ידי חשיפת תיבת דו-שיח שמתווך על ידי הדפדפן ומאפשרת למשתמשים לבחור חשבונות מ-IdP כדי להתחבר לאתרים.

FedCM הוא תהליך רב-שלבי לשיפור הזהות באינטרנט. בשלב הראשון אנחנו מתמקדים בהפחתת ההשפעה של הגבלות על קובצי cookie של צד שלישי על זהות מאוחדת (בקטע 'תוכנית העבודה' מפורטות כמה צעדים נוספים).

מה צפוי להיות מושפע?

בעזרת הקהילה והמחקר שלנו, גילינו שיש כמה שילובים שקשורים לאיחוד שירותי אימות הזהות שמושפעים מההגבלות על קובצי cookie של צד שלישי:

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

FedCM כאות אמון ל-API אחרים

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

החל מגרסה Chrome 131, Storage Access API‏ (SAA) משתמש ב-FedCM בתור אות אמון. השילוב הזה שימושי לאתרים שמסתמכים גם על FedCM לאימות וגם על SAA כדי לאפשר ל-iframes ממקורות שונים לגשת לאחסון הנדרש.

כשמשתמש מבצע אימות באמצעות FedCM, עם הסכמה מצד RP, התוכן של ה-IdP שמוטמע באתר של RP יכול להפעיל את השיטה requestStorageAccess() כדי לקבל באופן אוטומטי גישה לאחסון של קובצי ה-cookie ברמה העליונה שלו, בלי צורך בהודעה נוספת למשתמש. ההרשאה תוענק באופן אוטומטי רק כל עוד המשתמש מחובר באמצעות FedCM וסטטוס הכניסה ב-FedCM פעיל. מידע נוסף זמין במסמכי העזרה של Storage Access API.

למי כדאי להשתמש ב-FedCM?

אנחנו צופים ש-FedCM יועיל לכם רק אם כל התנאים הבאים מתקיימים:

  1. אתם ספק זהויות (IdP).
  2. אתם מושפעים מהמגבלות על קובצי cookie של צד שלישי.
  3. ה-RPs הם אתרים של צד שלישי. אם ה-RPs הם אתרים שקשורים באופן משמעותי, יכול להיות שתהיה לך תועלת רבה יותר מקבוצות של אתרים קשורים.

אתם ספקי אימות הזהות (IdP)

כדי להשתמש ב-FedCM, צריך תמיכה מספק זהויות. צד נסמך לא יכול להשתמש ב-FedCM באופן עצמאי. אם אתם ספקי RP, תוכלו לבקש מה-IdP שלכם לקבל הוראות.

אתם מושפעים מהמגבלות על קובצי cookie של צד שלישי

כדאי להשתמש ב-FedCM רק אם השילוב הנוכחי שלכם מושפע מהמגבלות על קובצי cookie של צד שלישי.

אם אתם לא בטוחים שהאיחוד של שירותי אימות הזהות ימשיך לפעול כשקובצי ה-Cookie של הצד השלישי לא יהיו זמינים, תוכלו לבדוק את ההשפעה על אתר מסוים על ידי חסימת קובצי ה-Cookie של הצד השלישי ב-Chrome.

אם אין השפעה ניתנת לזיהוי על איחוד שירותי אימות הזהות בלי קובצי cookie של צד שלישי, תוכלו להמשיך להשתמש בשילוב הנוכחי בלי FedCM.

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

חשבונות ה-RP הם של צד שלישי

אם אתם ספקי זהויות של RPs שיש להם קשר מאינטראקציה ישירה (first-party) ל-IdP, סביר להניח שקבוצות של אתרים קשורים יהיו אפשרות טובה יותר. קבוצות של אתרים קשורים (RWS) הן דרך שבה ארגון יכול להצהיר על קשרים בין אתרים, כדי שדפדפנים יאפשרו גישה מוגבלת לקובצי cookie של צד שלישי למטרות ספציפיות. כך קובצי cookie של צד שלישי יכולים לפעול בין קבוצות של אתרים קשורים באופן משמעותי, גם אם קובצי cookie של צד שלישי מוגבלים בדרכים אחרות.

איך המשתמשים יתקשרו עם FedCM?

המטרה העיקרית של FedCM היא לצמצם את ההשפעה של ההגבלות על קובצי cookie של צד שלישי. המשתמשים יכולים להפעיל או להשבית את FedCM בהגדרות המשתמש של Chrome.

FedCM תוכנן להיות פרוטוקול-נייטרלי, והוא מציע את הפונקציות הבאות שקשורות לאימות.

כדאי לצפות בהדגמה שלנו כדי לראות איך זה עובד.

כניסה לחשבון של צד נסמך

ל-FedCM יש שני מצבי ממשק משתמש:

מצב פסיבי. במצב פסיבי, ההנחיה של FedCM מופיעה ללא צורך באינטראקציה מהמשתמש. כשהמשתמש מגיע לאתר של הצד הנסמך (RP), תיפתח תיבת דו-שיח של כניסה ל-FedCM כשמתבצעת קריאה ל-navigator.credentials.get() והמשתמש מחובר ל-IdP \

משתמש נכנס לחשבון ב-RP באמצעות FedCM במצב פסיבי.

מצב פעיל. במצב פעיל, נדרשת אינטראקציה של משתמש (למשל, לחיצה על לחצן) כדי להפעיל הנחיה של FedCM.

משתמש נכנס לחשבון RP באמצעות FedCM במצב פעיל.

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

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

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

הגדרות להפעלה או להשבתה של FedCM

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

מחשב

המשתמשים יכולים להפעיל או להשבית את FedCM ל-Chrome במחשב בכתובת chrome://settings/content/federatedIdentityApi.

כדי להפעיל את FedCM בהגדרות Chrome במחשב, מפעילים את האפשרות 'כניסה לחשבון של צד שלישי'.

Android

כדי להפעיל או להשבית את FedCM ב-Chrome ל-Android, המשתמשים יכולים לעבור אל הגדרות ב-Chrome > הגדרות אתר > כניסה לחשבון של צד שלישי, ואז לשנות את המתג.

כדי להפעיל את FedCM בהגדרות Chrome בנייד, מפעילים את האפשרות 'כניסה של צד שלישי'.

תקופת הצינון של ההודעה

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

מספר הפעמים הרצופות שהעסק היה סגור פרק הזמן שבו ההנחיה של FedCM מושבתת
1 שעתיים
2 יום אחד
3 שבוע אחד
4+ ארבעה שבועות

בדפדפנים אחרים עשויות להיות תקופות זמן שונות של תקופת הצינון.

המשתמשים יכולים להפעיל מחדש את FedCM ב-RP באופן ידני על ידי מעבר אל דף ההגדרות או לחיצה על ממשק המשתמש של PageInfo (סמל מנעול לצד סרגל כתובת ה-URL) ואיפוס ההרשאה.

תוכנית עבודה

אנחנו עובדים על הוספת כמה שינויים ל-FedCM. לפרטים נוספים, ראו עדכונים.

  • יומן שינויים: עדכונים ב-Federated Credential Management API.

אנחנו יודעים שיש עוד כמה דברים שצריך לעשות, כולל בעיות ששמענו עליהן מ-IdP, מ-RP ומספקי דפדפנים. אנחנו חושבים שאנחנו יודעים איך לפתור את הבעיות האלה:

  • תמיכה ב-iframe ממקורות שונים: ספקי IdP יכולים להפעיל את FedCM מתוך iframe ממקורות שונים (עדכון).
  • לחצן מותאם אישית: ספקי IdP יכולים להציג את הזהות של משתמש חוזר בלחצן הכניסה מתוך iframe חוצה-מקור בבעלות ה-IdP (עדכון).
  • נקודת קצה למדדים: מספקת מדדי ביצועים ל-IdPs.

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

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

  • שיפור הבנת המשתמשים והתאמת התכונה לכוונה: כפי שציינה Mozilla, אנחנו רוצים להמשיך לבחון נוסחאות שונות של חוויית המשתמש (UX) ואזורי תצוגה שונים, וגם קריטריונים להפעלה.
  • מאפייני זהות וחשיפת מידע באופן סלקטיבי: כפי שציינו בודקי התגים שלנו, אנחנו רוצים לספק מנגנון לשיתוף סלקטיבי של יותר או פחות מאפייני זהות (כמו כתובות אימייל, טווחי גיל, מספרי טלפון וכו').
  • שיפור מאפייני הפרטיות: כפי ש-Mozilla הציעה במסמך העמדה שלה בנושא סטנדרטים, אנחנו רוצים להמשיך לבחון מנגנונים שיעזרו לנו להבטיח פרטיות טובה יותר, כמו עיוורון של שירותי אימות הזהות (IdP) ומזהים מונחים.
  • הקשר ל-WebAuthn: כפי שהציעה Apple, אנחנו שמחים לראות את ההתקדמות בנושא מפתחות גישה ולעבוד על מתן חוויה עקבית ומותאמת בין FedCM, סיסמאות, WebAuthn ו-WebOTP.
  • סטטוס ההתחברות: כפי ש-Apple הציעה בAPI של סטטוס ההתחברות של קבוצת המומחים בנושא פרטיות, אנחנו מסכימים שסטטוס ההתחברות של המשתמש הוא פיסת מידע שימושית שיכולה לעזור לדפדפנים לקבל החלטות מושכלות, ואנחנו שמחים לראות את ההזדמנויות שייווצרו בעקבות זאת. (עדכון)
  • ארגונים וחינוך: כפי שצוין ב-FedID CG, עדיין יש הרבה תרחישים לדוגמה שלא מתאימים ל-FedCM ואנחנו רוצים לעבוד עליהם, כמו יציאה מהחשבון בערוץ קדמי (היכולת של IdP לשלוח אות ל-RP כדי לצאת מהחשבון) ותמיכה ב-SAML.
  • הקשר ל-mDLs/VCs וכו': אנחנו ממשיכים לעבוד כדי להבין איך הרכיבים האלה משתלבים ב-FedCM, למשל באמצעות Mobile Document Request API.

שימוש ב-FedCM API

כדי להשתמש ב-FedCM, צריך הקשר מאובטח (HTTPS או localhost) גם ב-IdP וגם ב-RP ב-Chrome.

כדי לשלב עם FedCM, צריך ליצור קובץ ידוע, קובץ תצורה ונקודות קצה לרשימת החשבונות, להנפקת טענות נכוֹנוּת (assertion) ולמטא-נתונים של לקוחות (אופציונלי). משם, FedCM חושף ממשקי API של JavaScript ש-RP יכולים להשתמש בהם כדי להיכנס באמצעות ה-IdP.

במדריך למפתחים של FedCM מוסבר איך משתמשים ב-FedCM API.

יצירת מעורבות ושיתוף משוב

ציות לחוקי הפרטיות באינטרנט

השימוש ב-FedCM, כ-IdP או כ-RP, כרוך באחסון מידע בציוד המסוף של המשתמש או בגישה למידע שכבר מאוחסן בו, ולכן זוהי פעילות כפופה לחוקי הפרטיות הדיגיטלית באזור הכלכלי האירופי (EEA) ובבריטניה, שבדרך כלל מחייב הסכמה של המשתמש. באחריותכם לקבוע אם השימוש שלכם ב-FedCM חיוני כדי לספק שירות אונליין שהמשתמש ביקש במפורש, ולכן הוא פטור מדרישת ההסכמה. מידע נוסף זמין בשאלות נפוצות בנושא תאימות בנושא פרטיות בארגז החול לפרטיות.