החל מ-Chrome 122, ה-Disconnect API ל-Federated Credential Management API (FedCM) זמין. Disconnect API מאפשר לצדדים נסמכים לנתק את המשתמשים שלהם מהחשבון של ספק הזהויות בלי להסתמך על קובצי cookie של צד שלישי. בנוסף, יש כמה עדכונים לגבי הטיפול ב-SameSite ב-FedCM.
Disconnect API
כשמשתמש יוצר חשבון בצד נסמך (RP – האתר שמשתמש בספק הזהויות לצורך אימות) דרך איחוד שירותי אימות הזהות, ספק הזהויות (IdP – השירות שמספק אימות ומידע על החשבון לצדדים אחרים) בדרך כלל מתעד את החיבור בשרת שלו. החיבור המאוחסן מאפשר ל-IdP לעקוב אחרי ספקי ה-RP שהמשתמש נכנס אליהם ולבצע אופטימיזציה של חוויית המשתמש. לדוגמה, כדי לספק חוויה טובה יותר כשהמשתמש יחזור ל-RP מאוחר יותר, חשבון המשתמש ב-IdP מטופל כחשבון חוזר. כך אפשר להשתמש בתכונות כמו אימות מחדש אוטומטי ולחצנים מותאמים אישית שמציגים את החשבון שבו נעשה שימוש.
לפעמים, ספקי IdP מציעים ממשק API כדי לנתק את החשבון מ-RP. עם זאת, תהליך ניתוק מחייב אימות ודורש את קובצי ה-cookie של ה-IdP. בעולם ללא קובצי cookie של צד שלישי, כשהמשתמש נכנס ל-RP, אין ממשק API לדפדפן שדרכו ה-RP יכול להתנתק מה-IdP. יכול להיות שיהיו כמה חשבונות IdP מאותו IdP שמקושרים ל-RP נתון, ולכן תהליך הניתוק דורש לדעת איזה חשבון מנותק.
Disconnect API מאפשר למשתמש לנתק את חשבון ה-IdP מה-RP בדפדפן וגם בשרת ה-IdP, על ידי שליחת אות לנקודת הקצה שצוינה. המשתמש צריך לעבור איחוד שירותי אימות הזהות באמצעות Federated Credential 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 בהגדרות הדפדפן.
כשנקודת הקצה לניתוק של ה-IdP מחזירה תשובה, ה-RP וה-IdP מנותקים בדפדפן וההבטחה מתקבלת. חשבונות המשתמשים שמנותקים מפורטים בתגובה מנקודת הקצה לניתוק.
הגדרת קובץ תצורה של IdP
כדי לתמוך ב-Disconnect API, ה-IdP חייב לתמוך בנקודת קצה לניתוק ולספק את המאפיין disconnect_endpoint
ואת הנתיב שלו בקובץ התצורה של ה-IdP.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
ניתוק החשבון בנקודת הקצה לניתוק
כשמפעילים את IdentityCredential.disconnect()
, הדפדפן שולח בקשת POST
חוצת-מקור עם קובצי cookie וסוג תוכן של application/x-www-form-urlencoded
לנקודת הקצה הזו לניתוק, עם הפרטים הבאים:
נכס | תיאור |
---|---|
account_hint |
רמז לחשבון ה-IdP. |
client_id |
מזהה הלקוח של RP. |
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
. - מנתקים את חשבון המשתמש מרשימת החשבונות המקושרים של RP.
- משיבים לדפדפן עם הערך של
account_id
של המשתמש שזוהה בפורמט JSON.
דוגמה למטען ייעודי (payload) של JSON בתגובה:
{
"account_id": "account456"
}
אם ה-IdP רוצה שהדפדפן ינתק במקום זאת את כל החשבונות המשויכים ל-RP, צריך להעביר מחרוזת שלא תואמת למספר חשבון כלשהו, למשל "*"
.
בדיקת /.well-known/web-identity
מופסקת עכשיו כשה-RP וה-IdP נמצאים באותו אתר
כשמפתחים מערכת FedCM, דומיינים של שרת RP לבדיקה או ל-staging יכולים להיות תת-דומיינים של שרת ה-IdP בסביבת הייצור. לדוגמה, שרת ה-IdP בסביבת הייצור נמצא בכתובת idp.example
, ושרת ה-RP בסביבת ה-staging ושרת ה-IdP בסביבת ה-staging נמצאים בכתובת staging.idp.example
. עם זאת, מכיוון שקובץ ה-well-known צריך להיות ממוקם ברמה הבסיסית (root) של ה-eTLD+1 של שרת ה-IdP, הוא צריך להיות ב-idp.example/.well-known/web-identity
והוא השרת בסביבת הייצור. מכיוון שלא תמיד אפשר למפתחים להציב קבצים בסביבת הייצור במהלך הפיתוח, הם לא יכולים לבדוק את FedCM.
החל מ-Chrome 122, אם דומיין ה-RP זהה לדומיין ה-IdP, Chrome מדלג על בדיקת הקובץ המוכר. כך המפתחים יוכלו לבדוק בתרחיש כזה.
עכשיו אפשר להגדיר את סטטוס ההתחברות באותו אתר בנכסי משנה
בעבר, ב-Chrome היה אפשר להגדיר רק את סטטוס ההתחברות (לדוגמה, באמצעות הכותרת Set-Login: logged-in
) כשהבקשה היא מאותו מקור עם כל ההורים. כך נמנעו כניסות באמצעות בקשות fetch()
באותו אתר שמגדירות את סטטוס ההתחברות.
לדוגמה, נניח שיש אתר שמאפשר למשתמשים להזין את שם המשתמש והסיסמה שלהם ב-idp.example
, אבל פרטי הכניסה מתפרסמים ב-login.idp.example
באמצעות fetch()
. לא ניתן היה לתעד את סטטוס ההתחברות בדפדפן באמצעות Login Status API כי שני הדומיינים הם מאותו מקור ומאותו אתר.
בעקבות השינוי הזה, הרפינו את הדרישה ש-Login Status API יהיה באותו אתר עם כל ההורים, וכך בדוגמה שלמעלה אפשר להגדיר את סטטוס ההתחברות של login.idp.example
באמצעות כותרת HTTP (Set-Login:
logged-in
).
סיכום
בעזרת Disconnect API, FedCM יכול עכשיו לנתק את ה-RP מה-IdP בלי להסתמך על קובצי cookie של צד שלישי. כדי לעשות זאת, צריך להפעיל את הפונקציה IdentityCredential.disconnect()
ב-RP. באמצעות הפונקציה הזו, הדפדפן שולח בקשה לנקודת הקצה לניתוק של ה-IdP כדי שה-IdP יוכל לסיים את החיבור בשרת ואז בדפדפן.
הודענו שהבדיקה /.well-known/web-identity
מועברת אם ה-RP וה-IdP נמצאים באותו אתר, למטרות בדיקה. בנוסף, עכשיו אפשר להגדיר את סטטוס ההתחברות באמצעות כותרת תגובה של HTTP מהמשאב המשני של ה-IdP באותו אתר.