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

Maud Nalpas

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

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

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

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

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

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

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

פתרון

ב- בקשות מקור קשורות, אתר יכול לציין מקורות שמורשים להשתמש במזהה הגורם המוגבל שלו.

כך המשתמשים יוכלו להשתמש שוב באותו מפתח גישה בכמה אתרים שאתם מנהלים.

כדי להשתמש בבקשות מקור קשורות, צריך להציג קובץ 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: בהמתנה למיקום.

אזהרה: החל מאוגוסט 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 כמזהה הגורם המוגבל, כך שגם ב-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.

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

הצגת הקוד:

• אפשר לראות את הגדרת הקובץ ./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 להשתמש בו מזהה הגורם המוגבל. כדי לעשות זאת, יוצרים את קובץ ה-JSON של webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

אובייקט ה-JSON חייב להכיל מקורות בעלי שם של מפתח שהערך שלהם הוא מערך של או יותר מחרוזות שמכילות מקורות אינטרנט.

מגבלה חשובה: עד 5 תוויות

כל רכיב ברשימה הזו עובד כדי לחלץ את התוויות של eTLD + 1. לדוגמה, התוויות eTLD + 1 של example.co.uk ו-example.de הן שתיהן example. אבל התווית eTLD + 1 של example-rewards.com היא example-rewards. ב-Chrome, אפשר להוסיף עד 5 תוויות.

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

שלב 3: הצגת קובץ ה-JSON עם ה- .well-known/webauthn ב-site-1

לאחר מכן, שולחים את קובץ ה-JSON דרך site-1.com/.well-known/webauthn.

זהירות: הקובץ חייב להיות מוצג עם סוג תוכן של 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

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

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

פתרון בעיות

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

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

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

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

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

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

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

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

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

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