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

Maud Nalpas

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

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

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

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

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

פתרון

באמצעות בקשות ממקורות קשורים, אתר יכול לציין אילו מקורות מורשים להשתמש במזהה ה-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 כמזהה Relying Party, הדפדפן יזהה מזהה Relying Party שלא תואם למקור הבקשה. אם הדפדפן תומך בבקשות ממקורות קשורים, הוא יחפש קודם קובץ webauthn בכתובת https://{RP ID}/.well-known/webauthn. אם הקובץ קיים, הדפדפן בודק אם המקור ששולח את הבקשה נמצא ב-allowlist. אם כן, המערכת תמשיך לשלבים של יצירת מפתח גישה או אימות.

אם הדפדפן לא תומך בבקשות ממקורות קשורים, הוא יציג שגיאה SecurityError.

תמיכה בדפדפנים

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

הגדרה של בקשות קשורות למקור

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

ב-codebase של site-2, מגדירים את site-1.com כמזהה RP בכל מקום שנדרש:

• כשיוצרים פרטי כניסה:
  • מגדירים את site-1.com כמזהה RP ביצירת פרטי הכניסה options שמועברים לקריאה החוזרת navigator.credentials.create של חזית האתר, ובדרך כלל נוצרים בצד השרת.
  • מגדירים את site-1.com כמזהה הצד המסתמך הצפוי, כשמריצים אימותים של פרטי הכניסה לפני ששומרים אותם במסד הנתונים.
• לאחר האימות:
  • מגדירים את site-1.com כמזהה RP באימות options שמועבר לקריאה של חזית העורף navigator.credentials.get, ובדרך כלל נוצר בצד השרת.
  • מגדירים את site-1.com כמזהה הצד המסתמך הצפוי שצריך לאמת בשרת, כי אתם מריצים אימותים של פרטי הכניסה לפני אימות המשתמש.

פתרון בעיות

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

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

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

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

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

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

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

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