הבעיה שפתרון הבקשות הקשורות למקור פותר
מפתחות גישה קשורים לאתר ספציפי, וניתן להשתמש בהם רק כדי להיכנס לאתר שעבורו הם נוצרו.
המזהה הזה מצוין במזהה הצד הנסמך (מזהה RP). לדוגמה, למפתחות גישה שנוצרו לדומיין example.com, המזהה יכול להיות www.example.com
או example.com
.
מזהים של RP מונעים שימוש במפתחות גישה כפרטי כניסה יחידים לאימות בכל מקום, אבל הם יוצרים בעיות בנושאים הבאים:
- אתרים עם כמה דומיינים: משתמשים לא יכולים להשתמש באותו מפתח גישה כדי להיכנס לדומיינים שונים שמוגדרים למדינות שונות (לדוגמה,
example.com
ו-example.co.uk
) ומנוהלים על ידי אותה חברה. - דומיינים ממותגים: משתמשים לא יכולים להשתמש באותם פרטי כניסה בדומיינים שונים שבהם מותג אחד משתמש (לדוגמה,
acme.com
ו-acmerewards.com
). - אפליקציות לנייד: לרוב לאפליקציות לנייד אין דומיין משלהם, ולכן קשה לנהל את פרטי הכניסה שלהן.
יש פתרונות זמניים שמבוססים על איחוד שירותי אימות הזהות, ואחרים שמבוססים על iframes, אבל הם לא נוחים במקרים מסוימים. בקשות מקור קשורות יכולות להציע פתרון.
פתרון
באמצעות בקשות מקור קשורות, אפשר לציין באתר אילו מקורות מורשים להשתמש במזהה ה-RP שלו.
כך המשתמשים יוכלו להשתמש שוב באותו מפתח גישה בכמה אתרים שאתם מנהלים.
כדי להשתמש בבקשות ממקורות קשורים, צריך להציג קובץ 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
שמוגדר ב-בסיס הקוד של 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.
לדוגמה, התוויות של example.co.uk
ו-example.de
עם הסיומת eTLD + 1 הן 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 לא אמור להיות מושג גלוי למשתמשים בסוכן המשתמש או במנהל פרטי הכניסה שבו המשתמשים משתמשים. במקום זאת, סוכני משתמשים ומנהלי פרטי כניסה צריכים להציג למשתמשים איפה השתמשו בפרטי הכניסה שלהם. ייקח זמן ליישם את השינוי הזה. פתרון זמני יכול להיות הצגה של האתר הנוכחי ושל אתר הרישום המקורי.