ממשק API לניהול פרטי כניסה מאוחד

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

מה זה FedCM?

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

סטטוס הטמעה

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

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

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

למה צריך את FedCM?

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

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

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

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

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

משתמש נכנס לגורם מוגבל באמצעות FedCM

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

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

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

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

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

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

הוגדרת כ-IdP

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

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

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

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

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

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

הגורמים המוגבלים (RP) שלך הם של צד שלישי

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

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

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

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

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

כניסה לצד נסמך

משתמש נכנס לגורם מוגבל באמצעות FedCM

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

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

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

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

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

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

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

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

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

מפת דרכים

אנחנו פועלים להשקת מספר שינויים ב-FedCM.

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

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

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

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

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

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

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

שימוש ב-FedCM API

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

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

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

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