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

Maud Nalpas
Maud Nalpas

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

הנתון הזה מצוין בצד הנסמך המזהה (מזהה 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.

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

ההדגמה הבאה משתמשת בדוגמה של שני אתרים, 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.
מתבצע מילוי אוטומטי של Chrome בשני האתרים.
בזכות בקשות מקור קשורות, המשתמשים יכולים להשתמש באותם פרטי כניסה של מפתח גישה ב-ror-1 וב-ror-2. Chrome גם ימלא את פרטי הכניסה באופן אוטומטי.

הצגת הקוד:

שלב 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 תוויות.

שלב 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);
});

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

פתרון בעיות

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

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

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

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

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

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

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

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