איך לפתור את הבעיה של בקשות מקור קשורות
מפתחות גישה מקושרים לאתר ספציפי, ואפשר להשתמש בהם רק כדי להיכנס לחשבון באתר שבשבילו הם נוצרו.
הנתון הזה מצוין בצד הנסמך
המזהה (מזהה 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: בהמתנה למיקום.
איך להגדיר בקשות מקור קשורות
ההדגמה הבאה משתמשת בדוגמה של שני אתרים, https://ror-1.glitch.me ו-https://ror-2.glitch.me.
כדי לאפשר למשתמשים להיכנס באמצעות אותו מפתח גישה בשני האתרים האלה, נעשה שימוש בבקשות מקור קשורות כדי לאפשר ל-ror-2.glitch.me להשתמש ב-ror-1.glitch.me כמזהה הגורם המוגבל שלו.
הדגמה (דמו)
בכתובת https://ror-2.glitch.me מוטמעת 'בקשות מקור קשורות' כדי להשתמש ב-ror-1.glitch.me כמזהה הגורם המוגבל, כך שגם ב-ror-1 וגם ב-ror-2 נעשה שימוש ב-ror-1.glitch.me כמזהה גורם מוגבל בזמן יצירת מפתח גישה או באימות שלו.
בנוסף, הטמענו באתרים האלה מסד נתונים משותף של מפתחות גישה.
חשוב לשים לב לחוויית המשתמש הבאה:
- אפשר ליצור מפתח גישה ולאמת באמצעותו ב-
ror-2– אפילו שמזהה הגורם המוגבל שלו הוא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 ב-site-1
קודם צריך להגדיר את site-1.com כך שתאפשר ל-site-2.com להשתמש בו
מזהה הגורם המוגבל. כדי לעשות זאת, יוצרים את קובץ ה-webauthn JSON:
{
"origins": [
"https://site-2.com"
]
}
אובייקט ה-JSON חייב להכיל מקורות בעלי שם של מפתח שהערך שלהם הוא מערך של או יותר מחרוזות שמכילות מקורות אינטרנט.
מגבלה חשובה: עד 5 תוויות
כל אחד מהרכיבים ברשימה הזו יעובד כדי לחלץ את ה-eTLD + תווית אחת.
לדוגמה, התוויות eTLD + 1 של example.co.uk ו-example.de הן שתיהן
example. אבל התווית eTLD + 1 של example-rewards.com היא example-rewards.
ב-Chrome, אפשר להוסיף עד 5 תוויות.
שלב 3: הצגת קובץ ה-JSON עם ה- .well-known/webauthn ב-site-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);
});
כאן אנחנו משתמשים במאפיין האקספרס res.json, שכבר מגדיר את
content-type ('application/json'); נכון
שלב 4: מציינים את מזהה הגורם המוגבל (RP) הרצוי באתר 2
ב-codebase של 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: נכסים דיגיטליים קישורים. מידע נוסף זמין בכתובת הוספת תמיכה בקישורים לנכסים דיגיטליים.
- ב-Safari: דומיינים משויכים.
שיתוף סיסמאות בין אתרים
בקשות מקור קשורות מאפשרות למשתמשים לעשות שימוש חוזר במפתח גישה באתרים שונים. הפתרונות לשיתוף סיסמאות בין אתרים שונים בכל מנהלי הסיסמאות. במנהל הסיסמאות של Google, משתמשים בקישורים לנכסים דיגיטליים . ל-Safari יש מערכת אחרת.
התפקיד של מנהלי פרטי הכניסה וסוכני משתמשים
היקף ההרשאות הזה חורג מהיקף ההרשאות שלכם כמפתחי אתרים, אבל חשוב לזכור שככל הנראה המונח, מזהה הגורם המוגבל (RP) לא יכול להיות קונספט גלוי למשתמש בסוכן המשתמש מנהל פרטי הכניסה שהמשתמשים שלכם משתמשים בהם. במקום זאת, סוכני משתמש ופרטי כניסה המנהלים צריכים להראות למשתמשים איפה נעשה שימוש בפרטי הכניסה שלהם. השינוי הזה תהליך ההטמעה יכול להימשך זמן מה. פתרון זמני הוא להציג גם את האתר הנוכחי ואתר הרישום המקורי.