אפשר להשתמש שוב במפתחות גישה באתרים שלך באמצעות בקשות מקור קשורות

Maud Nalpas

הבעיה שפתרון הבקשות הקשורות למקור פותר

מפתחות גישה מקושרים לאתר ספציפי, וניתן להשתמש בהם רק כדי להיכנס לאתר שעבורו הם נוצרו.

המזהה הזה מצוין במזהה הצד הנסמך (מזהה RP). לדוגמה, למפתחות גישה שנוצרו לדומיין example.com, המזהה יכול להיות www.example.com או example.com.

מזהים של RP מונעים שימוש במפתחות גישה כפרטי כניסה יחידים לאימות בכל מקום, אבל הם יוצרים בעיות בנושאים הבאים:

• אתרים עם כמה דומיינים: משתמשים לא יכולים להשתמש באותו מפתח גישה כדי להיכנס לדומיינים שונים שמוגדרים למדינות שונות (לדוגמה, example.com ו-example.co.uk) ומנוהלים על ידי אותה חברה.
• דומיינים ממותגים: משתמשים לא יכולים להשתמש באותם פרטי כניסה בדומיינים שונים שבהם מותג אחד משתמש (לדוגמה, acme.com ו-acmerewards.com).
• אפליקציות לנייד: לרוב לאפליקציות לנייד אין דומיין משלהם, ולכן קשה לנהל את פרטי הכניסה שלהן.

יש פתרונות זמניים שמבוססים על איחוד שירותי אימות הזהות, ואחרים שמבוססים על iframes, אבל הם לא נוחים במקרים מסוימים. בקשות מקור קשורות יכולות להציע פתרון.

הערה: מזהי RP מפרידים בין פרטי הכניסה של אתרים שונים, אבל ההגנה מפני פישינג מגיעה למעשה מאימות המקור של האתר בשדה CollectedClientData.

פתרון

באמצעות בקשות ממקורות קשורים, אפשר לציין באתר אילו מקורות מורשים להשתמש במזהה ה-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.

אזהרה: החל מאוגוסט 2024, בקשות מקור קשורות לא נתמכות ב-Firefox, וgetClientCapabilities עדיין לא זמין כדי לזהות את התכונה החסרה ולהטמיע חלופה. אם מטמיעים בקשות ממקורות קשורים, משתמשי Firefox לא יוכלו ליצור מפתח גישה (או להיכנס באמצעותו) בדומיינים שבהם רוצים להשתמש באתר אחר בתור מזהה RP, ויופיע השגיאה SecurityError.

איך מגדירים בקשות מקור קשורות

בדוגמה הבאה נעשה שימוש בשני אתרים, 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.

בזכות בקשות מקורות קשורות, המשתמשים יכולים להשתמש באותם פרטי כניסה של מפתח גישה ב-ror-1 וב-ror-2. Chrome ימלא אוטומטית גם את פרטי הכניסה.

הצגת הקוד:

• אפשר לעיין בקובץ ./well-known/webauthn שמוגדר ב-ror-1 codebase.
• תוכלו לראות את המופעים של 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.

אזהרה: אם הרשימה כוללת יותר מדי תוויות (יותר מ-5), המערכת תתעלם מהרכיבים העודפים.

שלב 3: הצגת קובץ ה-JSON של well-known/webauthn באתר-1

לאחר מכן, מציגים את קובץ ה-JSON בקטע site-1.com/.well-known/webauthn.

זהירות: הקובץ חייב להיכלל ב-content-type‏ application/json ולהכיל אובייקט JSON אחד עם רשימה של מקורות מותרים. הפורמט הנכון של הקובץ הוא: /.well-known/webauthn (לא כולל את הסיומת .json).

לדוגמה, ב-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 צפוי שצריך לאמת בשרת, כי מריצים אימותים של פרטי כניסה לפני אימות המשתמש.

הערה: מה קורה עם origin? וגם ה-RP name? בקוד של site-2, הערך הצפוי של origin צריך להישאר ללא שינוי (https://site-2.com), כי הוא מציין את המקור הצפוי של הבקשה. בהתאם לשם RP (rp.name), הוא לא בשימוש בפועל. אפשר להשאיר אותו ריק.

פתרון בעיות

הודעת שגיאה ב-Chrome במהלך יצירת פרטי הכניסה. השגיאה הזו מתקבלת אם לא ניתן למצוא את הקובץ ‎.well-known/webauthn בכתובת ‎https://{RP ID}/.well-known/webauthn.

הודעת השגיאה ב-Chrome במהלך יצירת פרטי הכניסה. השגיאה הזו מתקבלת אם ניתן למצוא את הקובץ ‎well-known/webauthn.‎, אבל הוא לא מציג את המקור שממנו מנסים ליצור פרטי כניסה.

שיקולים נוספים

שיתוף מפתחות גישה בין אתרים ואפליקציות לנייד

בקשות מקור קשורות מאפשרות למשתמשים לעשות שימוש חוזר במפתח גישה במספר אתרים. כדי לאפשר למשתמשים להשתמש שוב במפתח גישה באתר ובאפליקציה לנייד, צריך להשתמש בשיטות הבאות:

• ב-Chrome: Digital Asset Links. מידע נוסף זמין במאמר הוספת תמיכה בקישורים לנכסים דיגיטליים.
• ב-Safari: דומיינים משויכים.

שיתוף סיסמאות בין אתרים

בקשות מקור קשורות מאפשרות למשתמשים לעשות שימוש חוזר במפתח גישה באתרים שונים. הפתרונות לשיתוף סיסמאות בין אתרים משתנים בין מנהלי הסיסמאות השונים. במנהל הסיסמאות של Google, משתמשים בקישורי נכסים דיגיטליים . ב-Safari יש מערכת שונה.

התפקיד של מנהלי פרטי הכניסה ושל סוכני המשתמשים

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