ממשק API לאינטרנט לאיחוד שירותי אימות הזהות תוך שמירה על פרטיות.
מה זה FedCM?
FedCM (ניהול מאוחד של פרטי כניסה) הוא גישה לשמירה על הפרטיות בשירותי אימות זהות מאוחדים (כמו 'כניסה באמצעות…') שלא מסתמכת על קובצי cookie של צד שלישי או על הפניות אוטומטיות לניווט.
סטטוס ההטמעה
- סטטוס הפלטפורמה של Chrome
- FedCM נשלח ב-Chrome 108.
- ההצעה של FedCM פתוחה לדיון ציבורי.
- FedCM עדיין לא נתמך בדפדפנים אחרים.
- Mozilla מטמיעה אב טיפוס ב-Firefox ו-Apple הביעה תמיכה כללית ורצונה לעבוד יחד על ההצעה של FedCM.
בהמשך, אנחנו מתכננים להציג מספר תכונות חדשות על סמך המשוב שקיבלנו מספק זהויות (IdP), מצדדים נסמכים (RP) ומספקי דפדפנים. אנחנו מקווים שספקי זהויות יאמצו את FedCM, אבל חשוב לזכור ש-FedCM הוא עדיין API בפיתוח פעיל.
כדי לצמצם את האתגרים בפריסת שינויים לא תואמים לאחור, יש לנו שתי המלצות לספקי זהויות:
- כדאי להירשם לניוזלטר שלנו כדי לקבל עדכונים על התפתחות ה-API.
- אנחנו ממליצים לספקי IdP להפיץ את FedCM API באמצעות ערכות SDK של JavaScript בזמן שה-API מתפתח, ולהניא ספקי RP מאירוח עצמאי של ערכות SDK. כך יהיה אפשר להבטיח שספקי זהויות (IdPs) יוכלו לבצע שינויים תוך כדי התפתחות ה-API, בלי שהם יצטרכו לבקש מכל הצדדים המסתמכים עליהם לפרוס מחדש.
למה אנחנו צריכים את FedCM?
בעשור האחרון, איחוד שירותי אימות הזהות שיחק תפקיד מרכזי בהעלאת רף האימות באינטרנט, מבחינת מהימנות, קלות השימוש (לדוגמה, כניסה יחידה ללא סיסמה) ואבטחה (לדוגמה, עמידות משופרת בפני פישינג והתקפות של מילוי פרטי כניסה).
באיחוד שירותי אימות הזהות, הגורם הנסמך מסתמך על IdP (ספק זהויות) כדי לספק למשתמש חשבון בלי לדרוש שם משתמש וסיסמה חדשים.
לצערנו, מנגנונים שהאיחוד של שירותי אימות הזהות מסתמך עליהם (iframe, הפניות אוטומטיות וקובצי cookie) משמשים לרעה למעקב אחר משתמשים באינטרנט. מאחר שסוכן המשתמש לא יכול להבחין בין איחוד שירותי אימות הזהות לבין מעקב, הפתרונות למניעת סוגי הניצול לרעה השונים מקשים על הפריסה של איחוד שירותי אימות הזהות.
Federated Credential Management API (FedCM) מספק הפשטה ספציפית לתרחישי שימוש לתהליכי אימות זהות מאוחדת באינטרנט. לשם כך, הוא חושף תיבת דו-שיח שמתווכחת על ידי הדפדפן ומאפשרת למשתמשים לבחור חשבונות מ-IdP כדי להתחבר לאתרים.
FedCM הוא שירות מרובה שלבים לשיפור הזהות באינטרנט. בשלב הראשון אנחנו מתמקדים בהפחתת ההשפעה של הגבלות על קובצי cookie של צד שלישי על זהות מאוחדת (בקטע 'תוכנית העבודה' מפורטות כמה פעולות נוספות).
מה צפוי להיות מושפע?
בעזרת הקהילה והמחקר שלנו, גילינו שיש כמה שילובים שקשורים לאיחוד שירותי אימות הזהות שמושפעים מההגבלות על קובצי cookie של צד שלישי:
- התנתקות מ-OpenID Connect
- ניהול סשנים ב-OpenID Connect
- חידוש אסימון רקע שמבוסס על iframe
- ווידג'טים של כניסה מבוססי-Iframe
המטרה הראשונה של FedCM היא לצמצם את ההשפעה של הגבלות על קובצי Cookie של צד שלישי על איחוד שירותי אימות הזהות, ואלה האזורים שאנחנו צופים שיושפע. אם יש תרחישי שימוש נוספים שלא מופיעים ברשימה, תוכלו להשתתף ולשתף משוב.
למי כדאי להשתמש ב-FedCM?
אנחנו צופים ש-FedCM יועיל לכם רק אם כל התנאים הבאים מתקיימים:
- אתם ספק זהויות (IdP).
- אתם מושפעים מהמגבלות על קובצי cookie של צד שלישי.
- ה-RPs הם אתרים של צד שלישי. אם ה-RPs הם אתרים שקשורים באופן משמעותי, יכול להיות שתהיה לך תועלת רבה יותר מקבוצות של אתרים קשורים.
אתם ספקי אימות הזהות (IdP)
FedCM דורש תמיכה מספק זהויות. צד נסמך לא יכול להשתמש ב-FedCM באופן עצמאי. אם אתם ישות מוגבלת, תוכלו לבקש מה-IdP לתת הוראות.
אתם מושפעים מהמגבלות על קובצי cookie של צד שלישי
כדאי להשתמש ב-FedCM רק אם השילוב הנוכחי שלכם מושפע מהמגבלות על קובצי cookie של צד שלישי.
אם אתם לא בטוחים שהאיחוד של שירותי אימות הזהות ימשיך לפעול כשקובצי ה-Cookie של הצד השלישי לא יהיו זמינים, תוכלו לבדוק את ההשפעה על אתר מסוים על ידי חסימת קובצי ה-Cookie של הצד השלישי ב-Chrome.
אם אין השפעה גלויה על איחוד שירותי אימות הזהות ללא קובצי Cookie של צד שלישי, אפשר להמשיך להשתמש בשילוב הנוכחי בלי FedCM.
אם אתם לא בטוחים מה צריך לבדוק, כדאי לקרוא מידע נוסף על התכונות הידועות שצפויות להשפיע עליהן ההגבלות על קובצי cookie של צד שלישי.
חשבונות ה-RP הם של צד שלישי
אם אתם ספקי זהויות שלגורם מוגבל (RP) יש קשר של צד ראשון ל-IdP, אנחנו צופים שקבוצות של אתרים קשורים יהיו אפשרות טובה יותר. קבוצות של אתרים קשורים (RWS) הן דרך שבה ארגון יכול להצהיר על קשרים בין אתרים, כדי שדפדפנים יאפשרו גישה מוגבלת לקובצי cookie של צד שלישי למטרות ספציפיות. כך קובצי Cookie של צד שלישי יכולים לפעול בין קבוצות של אתרים קשורים באופן משמעותי, גם אם קובצי Cookie של צד שלישי מוגבלים בדרכים אחרות.
איך המשתמשים יתקשרו עם FedCM?
המטרה העיקרית של FedCM היא לצמצם את ההשפעה של ההגבלות על קובצי cookie של צד שלישי. המשתמשים יכולים להפעיל או להשבית את FedCM בהגדרות המשתמש של Chrome.
FedCM תוכנן להיות פרוטוקול-נייטרלי, והוא מציע את הפונקציות הבאות שקשורות לאימות.
אפשר לנסות את ההדגמה שלנו כדי לראות איך זה עובד.
כניסה לחשבון של צד נסמך
כשהמשתמש מגיע לאתר של הצד הנסמך (RP), תיפתח תיבת דו-שיח של FedCM לכניסה אם המשתמש מחובר ל-IdP.
אם למשתמש אין חשבון ב-RP עם ה-IdP, תוצג תיבת דו-שיח להרשמה עם טקסט נוסף של גילוי נאות, כמו התנאים וההגבלות של ה-RP ומדיניות הפרטיות, אם הם זמינים.
המשתמש יכול להקיש על המשך כ... כדי להשלים את הכניסה. אם הפעולה בוצעה ללא שגיאות, הדפדפן שומר את העובדה שהמשתמש יצר חשבון מאוחד ב-RP עם ה-IdP.
שירותי RP אמורים לפעול בדפדפנים שלא תומכים ב-FedCM. למשתמשים צריכה להיות אפשרות להשתמש בתהליך כניסה קיים שאינו של FedCM. איך פועלת כניסה לחשבון ב-FedCM
הגדרות להפעלה או להשבתה של FedCM
המשתמשים יכולים להפעיל או להשבית את FedCM בהגדרות של Chrome ב-Android. עוברים אל הגדרות > הגדרות אתר > כניסה של צד שלישי, ומחליפים את מצב המתג.
הם יכולים לעשות את אותו הדבר גם ב-Chrome במחשב באמצעות מעבר אל chrome://settings/content/federatedIdentityApi.
תקופת הצינון של ההודעה
אם המשתמש סוגר את ממשק המשתמש באופן ידני, תתווסף רשומה באופן זמני לממשק המשתמש של ההגדרות, וממשק המשתמש לא יוצג באותו אתר למשך פרק זמן מסוים. ממשק המשתמש יופעל מחדש בסיום התקופה, אבל משך הזמן יגדל באופן אקספוננציאלי בכל סגירה חוזרת. לדוגמה, ב-Chrome:
| מספר הפעמים הרצופות שהעסק היה סגור | התקופה שבה בקשת FedCM מושבתת |
|---|---|
| 1 | שעתיים |
| 2 | יום אחד |
| 3 | שבוע אחד |
| 4+ | ארבעה שבועות |
בדפדפנים אחרים עשויות להיות תקופות זמן שונות של תקופת הצינון.
המשתמשים יכולים להפעיל מחדש FedCM ב-RP באופן ידני על ידי מעבר לדף ההגדרות או לחיצה על ממשק המשתמש של PageInfo (סמל נעילה לצד סרגל כתובות ה-URL) ואיפוס ההרשאה.
מפת דרכים
אנחנו עובדים על מספר שינויים ב-FedCM. פרטים נוספים זמינים במאמר עדכונים.
- יומן שינויים: עדכונים ב-Federated Credential Management API.
יש כמה דברים שאנחנו יודעים שעדיין צריך לעשות, כולל בעיות ששמענו עליהן מספקי זהויות (IdPs), גורמים מוגבלים (RP) וספקי דפדפנים. אנחנו מאמינים שאנחנו יודעים איך לפתור את הבעיות האלה:
- תמיכה ב-iframe ממקורות שונים: ספקי IdP יכולים להפעיל את FedCM מתוך iframe ממקורות שונים (עדכון).
- לחצן מותאם אישית: ספקי IdP יכולים להציג את הזהות של משתמש חוזר בלחצן הכניסה מתוך iframe חוצה-מקור בבעלות ה-IdP (עדכון).
- נקודת קצה למדדים: מספקת מדדי ביצועים ל-IdPs.
בנוסף, יש בעיות שעדיין לא נפתרו ואנחנו בודקים אותן באופן פעיל, כולל הצעות ספציפיות שאנחנו בודקים או יוצרים להן אב טיפוס:
- CORS: אנחנו מנהלים דיונים עם Apple ו-Mozilla כדי לשפר את המפרט של אחזור הנתונים של FedCM.
- Multiple-IdP API: אנחנו בוחנים דרכים לתמוך במספר IdPs כדי לאפשר קיום משותף עם בורר החשבונות של FedCM.
- IdP Sign-in Status API: ב-Mozilla זיהו בעיה בהתקפת תזמון, ואנחנו בודקים דרכים שבהן IdP יוכל להודיע לדפדפן באופן יזום על סטטוס הכניסה של המשתמש כדי לצמצם את הבעיה. (update)
- כניסה ל-IdP API: כדי לתמוך בתרחישים שונים, כשמשתמש לא נכנס ל-IdP, הדפדפן מספק ממשק משתמש שמאפשר לו להיכנס בלי לצאת מה-RP.
לבסוף, יש דברים שאנחנו עדיין צריכים לעשות, על סמך משוב מ-Mozilla, מ-Apple ומ-בודקי TAG. אנחנו בודקים את הפתרונות הטובים ביותר לשאלות הפתוחות הבאות:
- שיפור הבנת המשתמשים וכוונת ההתאמה של המשתמשים: כפי שציינו ב-Mozilla, אנחנו רוצים להמשיך לבחון ניסוחים שונים של חוויית המשתמש, אזורי שטח שונים וקריטריונים שונים.
- מאפייני זהות וגילוי נאות סלקטיבי: כפי שבודקי התגים שלנו ציינו, אנחנו רוצים לספק מנגנון לשיתוף סלקטיבי של יותר או פחות מאפייני זהות (כמו כתובות אימייל, טווחי גיל, מספרי טלפון וכו').
- שיפור מאפייני הפרטיות: כפי ש-Mozilla הציעה במסמך העמדה שלה בנושא סטנדרטים, אנחנו רוצים להמשיך לבחון מנגנונים שיעזרו לנו להבטיח פרטיות טובה יותר, כמו עיוורון של שירותי אימות הזהות (IdP) ומזהים מונחים.
- היחסים עם WebAuthn: כפי שהוצע על ידי Apple, אנחנו שמחים מאוד לראות את ההתקדמות במפתחות הגישה, ולספק חוויית שימוש עקבית ואחידה בין FedCM, סיסמאות, WebAuthn ו-WebOTP.
- סטטוס התחברות: כפי ש-Apple הציעה באמצעות ה-API סטטוס ההתחברות של Privacy CG, אנחנו משתפים את ההבנה שסטטוס ההתחברות של המשתמש הוא מידע מועיל שיכול לעזור לדפדפנים לקבל החלטות מושכלות, ואנחנו שמחים לראות אילו הזדמנויות עולות כתוצאה מכך. (עדכון)
- Enterprises ו-Education: כפי שאפשר לראות ב-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.
יצירת מעורבות ושיתוף משוב
- GitHub: קוראים את ההסבר, מדווחים על בעיות ומעקב אחרי הדיונים.
- תמיכה למפתחים: אפשר לשאול שאלות ולהצטרף לדיוני המאגר של תמיכה למפתחים של ארגז החול לפרטיות.
ציות לחוקי הפרטיות באינטרנט
השימוש ב-FedCM, כ-IdP או כ-RP, כרוך באחסון מידע בציוד המסוף של המשתמש או בגישה למידע שכבר מאוחסן בו, ולכן זוהי פעילות כפופה לחוקי הפרטיות הדיגיטלית באזור הכלכלי האירופי (EEA) ובבריטניה, שבדרך כלל מחייב הסכמה של המשתמש. באחריותכם לקבוע אם השימוש שלכם ב-FedCM חיוני כדי לספק שירות אונליין שהמשתמש ביקש במפורש, ולכן הוא פטור מדרישת ההסכמה. למידע נוסף, מומלץ לקרוא את השאלות הנפוצות בנושא תאימות הקשורות לפרטיות בארגז החול לפרטיות.