דף זה תורגם על ידי Cloud Translation API.

עדכוני FedCM: ניתוק ה-API ושני עדכונים

Eiji Kitamura

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

ניתוק ה-API

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

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

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

מנתקים את ה-IdP מה-RP

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

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

הפונקציה IdentityCredential.disconnect() מחזירה Promise. ההבטחה הזו עלולה לגרום חריג, מהסיבות הבאות:

המשתמש לא נכנס ל-RP באמצעות IdP דרך FedCM.
ה-API מופעל מתוך iframe ללא מדיניות הרשאות של FedCM.
השדה configURL לא תקין או שחסרה בו נקודת הקצה של ניתוק.
הבדיקה של Content Security Policy (CSP) נכשלה.
יש בקשת ניתוק בהמתנה.
המשתמש השבית את FedCM בהגדרות הדפדפן.

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

הגדרת קובץ תצורה של IdP

כדי לתמוך ב-ניתוק API, ה-IdP צריך לתמוך בניתוק את נקודת הקצה של נקודת הקצה ולספק את המאפיין disconnect_endpoint ואת הנתיב שלו ב-IdP קובץ תצורה.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

ניתוק החשבון בנקודת הקצה (endpoint) של הניתוק

על ידי הפעלת IdentityCredential.disconnect(), הדפדפן שולח קוד חוצה-מקורות בקשת POST עם קובצי cookie וסוג תוכן של application/x-www-form-urlencoded לנקודת הקצה הזו של הניתוק באמצעות הבאים:

נכס	תיאור
`account_hint`	רמז לחשבון IdP.
`client_id`	מזהה הלקוח של הגורם המוגבל.

POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

עם קבלת הבקשה, שרת ה-IdP צריך:

להגיב לבקשה באמצעות CORS (משאב ממקורות שונים שיתוף).
צריך לוודא שהבקשה מכילה כותרת HTTP Sec-Fetch-Dest: webidentity.
מתאימים את הכותרת Origin למקור של הגורם המוגבל (RP) שנקבע לפי client_id. אפשר לדחות אותם אם הם לא תואמים.
צריך למצוא את החשבון שתואם ל-account_hint.
מנתקים את חשבון המשתמש מרשימת החשבונות המחוברים של הגורם המוגבל.
שליחת תשובה לדפדפן עם account_id של המשתמש שזוהה בקובץ JSON הפורמט.

אזהרה: לבקשת ה-CORS יש פרטי כניסה, כלומר התשובה Access-Control-Allow-Credentials: true יש לשלוח את הכותרת ואת התשובה Access-Control-Allow-Origin הכותרת חייבת לציין מקור מורשה באופן מפורש ולא להשתמש בתו כללי לחיפוש "*".

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://rp.example
Access-Control-Allow-Credentials: true

דוגמה למטען ייעודי (payload) של JSON עם תגובה:

{
  "account_id": "account456"
}

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

המערכת מדלגת על הבדיקה של `/.well-known/web-identity` כשה-RP וה-IdP הם באותו אתר

כשמפתחים מערכת FedCM, בדיקה או Staging של דומיינים של שרת RP עשויים להיות של שרת ה-IdP בסביבת הייצור. לדוגמה, שרת ה-IdP לסביבת הייצור נמצא ב-idp.example וגם שרת ה-Staging RP וגם שרת ה-IdP ה-Staging נמצאים ב-staging.idp.example. עם זאת, מכיוון שצריך למקם את הקובץ הידוע ברמה הבסיסית (root) של ה-eTLD+1 של שרת ה-IdP, הוא צריך להיות idp.example/.well-known/web-identity והוא שרת הייצור. מאז לא בטוח שמפתחים יכולים להציב קבצים בסביבת הייצור בזמן הפיתוח, זה מונע מהם לבדוק את FedCM.

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

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

בעבר, היה אפשר להגדיר ב-Chrome רק התחברות status (בשביל לדוגמה, באמצעות הכותרת Set-Login: logged-in) כאשר הבקשה היא אותו מקור עם כל ישויות האב. ולכן אי אפשר להתחבר דרך אותו אתר fetch() בקשות להגדרה של סטטוס התחברות.

לדוגמה, חשוב על אתר שמאפשר למשתמשים להזין את שם המשתמש שלהם הסיסמה ב-idp.example, אבל פרטי הכניסה פורסמו בכתובת login.idp.example עם fetch(). תיעוד סטטוס ההתחברות לדפדפן באמצעות סטטוס ההתחברות לא הייתה אפשרות להשתמש ב-API כי שני הדומיינים הם מאתרים שונים ומאותו אתר.

בעקבות השינוי הזה, הפכנו את הדרישה ל-Login Status API את אותו אתר עם כל ישויות האב, והופכים את הדוגמה שלמעלה לאפשר סטטוס ההתחברות של login.idp.example באמצעות כותרת HTTP (Set-Login: logged-in).

סיכום

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

הודענו שהמערכת מדלגת על בדיקה אחת (/.well-known/web-identity) כשהגורם המוגבל (RP) וה-IdP הם אותו אתר למטרות בדיקה. בנוסף, הגדרת פרטי התחברות את הסטטוס דרך כותרת תגובת HTTP מאותו משאב משנה של IdP באותו אתר ככל האפשר.