איך לפתור את הבעיה של בקשות מקור קשורות
מפתחות גישה קשורים לאתר ספציפי, וניתן להשתמש בהם רק כדי להיכנס לאתר שבו הם נוצרו.
המזהה הזה מצוין במזהה הצד הנסמך (מזהה RP). לדוגמה, למפתחות גישה שנוצרו לדומיין example.com, המזהה יכול להיות www.example.com או example.com.
מזהים של RP מונעים שימוש במפתחות גישה כפרטי כניסה יחידים לאימות בכל מקום, אבל הם יוצרים בעיות בנושאים הבאים:
- אתרים עם כמה דומיינים: משתמשים לא יכולים להשתמש באותו מפתח גישה כדי להיכנס לדומיינים שונים שמוגדרים למדינות שונות (לדוגמה,
example.comו-example.co.uk) ומנוהלים על ידי אותה חברה. - דומיינים ממותגים: משתמשים לא יכולים להשתמש באותם פרטי כניסה בדומיינים שונים שבהם נעשה שימוש על ידי מותג אחד (לדוגמה,
acme.comו-acmerewards.com). - אפליקציות לנייד: לרוב לאפליקציות לנייד אין דומיין משלהם, ולכן קשה לנהל את פרטי הכניסה שלהן.
יש פתרונות זמניים שמבוססים על איחוד שירותי אימות הזהות, ואחרים שמבוססים על iframes, אבל הם לא נוחים במקרים מסוימים. בקשות מקור קשורות יכולות להציע פתרון.
פתרון
באמצעות בקשות מקור קשורות, אתרים יכולים לציין מקורות שמורשים להשתמש במזהה הגורם המוגבל שלו.
כך המשתמשים יוכלו להשתמש שוב באותו מפתח גישה בכמה אתרים שאתם מנהלים.
כדי להשתמש בבקשות ממקורות קשורים, צריך להציג קובץ JSON מיוחד בכתובת URL ספציפית https://{RP ID}/.well-known/webauthn. אם example.com רוצה לאפשר למקורות הנוספים להשתמש בו כמזהה RP, הוא צריך להציג את הקובץ הבא בכתובת https://example.com/.well-known/webauthn:
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
בפעם הבאה שאחד מהאתרים האלה יבצע קריאה ליצירת מפתח גישה (navigator.credentials.create) או לאימות (navigator.credentials.get) שמשתמש ב-example.com בתור מזהה RP, הדפדפן יבחין במזהה RP שלא תואם למקור המבקש. אם הדפדפן תומך בבקשות למקורות קשורים, הוא מחפש קודם קובץ webauthn בכתובת https://{RP ID}/.well-known/webauthn. אם הקובץ קיים, הדפדפן בודק אם מקור הבקשה נכלל ברשימת ההיתרים בקובץ הזה. אם כן, הוא ממשיך לשלבים של יצירת מפתח הגישה או האימות.
אם הדפדפן לא תומך בבקשות מקורות קשורות, הוא יוצר אירוע SecurityError.
תמיכה בדפדפנים
- Chrome: נתמך החל מ-Chrome 128.
- Safari: נתמך החל מ-macOS 15 בטא 3, ובניידים iOS 18 בטא 3.
- Firefox: Awaiting position.
איך מגדירים בקשות מקור קשורות
בדוגמה הבאה נעשה שימוש בשני אתרים, https://ror-1.glitch.me ו-https://ror-2.glitch.me.
כדי לאפשר למשתמשים להיכנס באמצעות אותו מפתח גישה בשני האתרים האלה, המערכת משתמשת בבקשות מקור קשורות כדי לאפשר ל-ror-2.glitch.me להשתמש ב-ror-1.glitch.me בתור מזהה RP שלו.
הדגמה (דמו)
https://ror-2.glitch.me מטמיע בקשות מקורות קשורות כדי להשתמש ב-ror-1.glitch.me כמזהה RP, כך שגם ror-1 וגם ror-2 משתמשים ב-ror-1.glitch.me כמזהה RP כשיוצרים מפתח גישה או מבצעים אימות באמצעותו.
הטמענו גם מסד נתונים משותף של מפתחות גישה באתרים האלה.
בודקים את חוויית המשתמש הבאה:
- אפשר ליצור מפתח גישה ולבצע אימות באמצעותו ב-
ror-2, גם אם מזהה ה-RP שלו הואror-1(ולאror-2). - אחרי שיוצרים מפתח גישה ב-
ror-1או ב-ror-2, אפשר לבצע אימות באמצעותו גם ב-ror-1וגם ב-ror-2. מכיוון ש-ror-2מציין אתror-1כמזהה RP, שליחת בקשה ליצירת מפתח גישה או לבקשת אימות מכל אחד מהאתרים האלה זהה לשליחת הבקשה ב-ror-1. מזהה RP הוא הגורם היחיד שמקשר בקשה למקור. - אחרי שיוצרים מפתח גישה ב-
ror-1או ב-ror-2, Chrome יכול למלא אותו באופן אוטומטי גם ב-ror-1וגם ב-ror-2. - לפרטי הכניסה שנוצרים בכל אחד מהאתרים האלה יהיה מזהה RP של
ror-1.
הצגת הקוד:
- אפשר לראות את הגדרת הקובץ
./well-known/webauthnב-codebase ror-1. - הצגת
RP_ID_RORמופעים בבסיס הקוד ror-2.
שלב 1: הטמעת מסד נתונים של חשבון משותף
כדי שהמשתמשים יוכלו להיכנס באמצעות אותו מפתח גישה ב-site-1 וב-site-2, צריך ליצור מסד נתונים של חשבונות שמשותף לשני האתרים האלה.
שלב 2: מגדירים את קובץ ה-JSON של well-known/webauthn באתר-1
קודם כול, מגדירים את site-1.com כך שיאפשר ל-site-2.com להשתמש בו בתור מזהה RP. כדי לעשות זאת, יוצרים את קובץ ה-JSON של webauthn:
{
"origins": [
"https://site-2.com"
]
}
אובייקט ה-JSON חייב לכלול מפתח בשם 'origins' שהערך שלו הוא מערך של מחרוזת אחת או יותר שמכילות מקורות אינטרנט.
מגבלה חשובה: אפשר להוסיף עד 5 תוויות
כל רכיב ברשימה הזו עובד כדי לחלץ את התוויות של eTLD + 1.
לדוגמה, התוויות eTLD + 1 של example.co.uk ו-example.de הן גם example. אבל התווית eTLD + 1 של example-rewards.com היא example-rewards.
ב-Chrome, מספר התוויות המקסימלי הוא 5.
שלב 3: הצגת קובץ ה-JSON של well-known/webauthn באתר-1
לאחר מכן, מציגים את קובץ ה-JSON בכתובת site-1.com/.well-known/webauthn.
לדוגמה, ב-Express:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
כאן אנחנו משתמשים ב-express res.json, שכבר מגדיר את content-type הנכון ('application/json');
שלב 4: מציינים את מזהה הגורם המוגבל (RP) הרצוי באתר 2
בקוד של site-2, מגדירים את site-1.com כמזהה RP בכל מקום שבו יש צורך:
- בזמן היצירה של פרטי הכניסה:
- מגדירים את
site-1.comבתור מזהה RP ביצירת פרטי הכניסהoptions, שמועברים לקריאה שלnavigator.credentials.createבחזית, ובדרך כלל נוצרים בצד השרת. - מגדירים את
site-1.comכמזהה RP הצפוי, כשמריצים אימותים של פרטי הכניסה לפני שמשמרים אותם במסד הנתונים.
- מגדירים את
- לאחר האימות:
- מגדירים את
site-1.comכמזהה RP באימותoptionsשמועברים לקריאה שלnavigator.credentials.getמצד הלקוח, ובדרך כלל נוצרים בצד השרת. - מגדירים את
site-1.comכמזהה RP צפוי שצריך לאמת בשרת, כי מריצים אימותים של פרטי כניסה לפני אימות המשתמש.
- מגדירים את
פתרון בעיות
שיקולים נוספים
שיתוף מפתחות גישה בין אתרים ואפליקציות לנייד
בקשות מקור קשורות מאפשרות למשתמשים לעשות שימוש חוזר במפתח גישה במספר אתרים. כדי לאפשר למשתמשים להשתמש שוב במפתח גישה באתר ובאפליקציה לנייד, צריך להשתמש בשיטות הבאות:
- ב-Chrome: Digital Asset Links. מידע נוסף זמין במאמר הוספת תמיכה בקישורים לנכסים דיגיטליים.
- ב-Safari: דומיינים משויכים.
שיתוף סיסמאות בין אתרים
בקשות מקור קשורות מאפשרות למשתמשים לעשות שימוש חוזר במפתח גישה באתרים שונים. הפתרונות לשיתוף סיסמאות בין אתרים משתנים בין מנהלי הסיסמאות השונים. במנהל הסיסמאות של Google, משתמשים בקישורים לנכסים דיגיטליים . ב-Safari יש מערכת שונה.
התפקיד של מנהלי פרטי הכניסה ושל סוכני המשתמשים
זהו נושא שמעבר להיקף שלכם כמפתחים של האתר, אבל חשוב לזכור שבטווח הארוך מזהה ה-RP לא אמור להיות מושג גלוי למשתמשים בסוכן המשתמש או במנהל פרטי הכניסה שבו המשתמשים משתמשים. במקום זאת, סוכני משתמשים ומנהלים של פרטי כניסה צריכים להראות למשתמשים איפה נעשה שימוש בפרטי הכניסה שלהם. ייקח זמן ליישם את השינוי הזה. פתרון זמני יכול להיות הצגה של האתר הנוכחי ושל אתר הרישום המקורי.