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

Eiji Kitamura

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

מידע בסיסי על מזהה הגורם המוגבל

מזהה הצד המסתמך (RP ID) הוא מחרוזת ייחודית שמזהה את השירות או האתר שלכם. מזהה הגורם המוגבל (RP) חייב להיות מחרוזת דומיין. זה יכול להיות שם המארח הנוכחי המדויק או דומיין אב רחב יותר, בתנאי שהוא eTLD+1 או גבוה יותר. אי אפשר להשתמש בכתובות IP ובסיומות ציבוריות (eTLD) כמזהה RP.

הערה: מידע נוסף על המושגים eTLD+1 וסיומת ציבורית זמין במאמר 'אותו אתר' ו'אותו מקור'.

לדוגמה, אם השרת שלכם מתארח ב-https://www.example.com, אתם יכולים להשתמש ב-example.com או ב-www.example.com כמזהה RP שלו, בהתאם לצרכים הספציפיים. בטבלה הבאה מוצגות דוגמאות למזהי RP מותרים בהתאם למארח המקור:

מארח המקור	מזהה הגורם המוגבל המותר (eTLD+1)
https://login.example.com	example.com או login.example.com
https://example.com:8080	example.com (מספרי ניוד לא נכללים)
https://mobile.example.co.jp	example.co.jp או mobile.example.co.jp
https://sub.project.org.uk	project.org.uk או sub.project.org.uk
https://user.github.io	user.github.io (github.io הוא eTLD)
https://myapp.pages.dev	myapp.pages.dev (pages.dev הוא eTLD)
http://localhost	localhost (חריגה מדרישת ה-HTTPS)

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

כשמשתמשים ב-eTLD+1 כמזהה RP, מפתח הגישה פועל בכל תתי הדומיינים שקשורים זה לזה. לדוגמה, מזהה RP‏ example.com מתאים ל-https://login.example.com ול-https://shop.example.com. מזהה RP ID ספציפי יותר, כמו login.example.com, פועל במקור המדויק שלו אבל לא ב-https://shop.example.com.

מזהה הגורם המוגבל בהקשרים של אתרים שונים

אם השירות שלכם משתרע על כמה eTLD+1 (לדוגמה, example.com ו-example.co.jp), מדובר בהגדרה חוצת-אתרים. מזהי RP רגילים לא תומכים בהגדרות חוצות אתרים.

כדי לשתף מפתחות גישה בין אתרים שונים, משתמשים ב-Related Origin Requests (ROR). התכונה ROR מאפשרת לשתף מפתחות גישה בין אתרים שונים, כי הלקוח (הדפדפן) מזהה מקורות שונים כחלק מאותו שירות לוגי.

דרישות ל-ROR:

• בחירת מזהה RP אחד: אתם צריכים לבחור מזהה RP אחד ולהשתמש בו בכל האתרים.
• אירוח קובץ הגדרות: בדומיין של מזהה RP הראשי צריך לארח קובץ הגדרות בכתובת /.well-known/webauthn שבו מפורטים המקורות המורשים.
• שמירה על עקביות: גם אם המשתמש נמצא ב-https://www.example.co.jp, ה-rpId בקריאה ל-WebAuthn חייב להיות הראשי (לדוגמה, example.com) גם ביצירה וגם באימות.

דוגמה ל-ROR עבור מזהה הגורם המוגבל example.com: https://example.com/.well-known/webauthn

{
  "origins": [
    "https://www.example.co.jp",
    "https://shop.example"
  ]
}

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

מזהה הגורם המוגבל באפליקציות לנייד

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

‫Android: Digital Asset Links

‫Credential Manager ב-Android דורש קובץ Digital Asset Link ‏(DAL) בדומיין של מזהה ה-RP כדי לשייך אותו לאפליקציה.

• אירוח: מארחים את הקובץ ב-https://<RP ID>/.well-known/assetlinks.json.
• אימות: מאמתים את origin ב-clientDataJSON. ב-Android, זהו מחרוזת כמו android:apk-key-hash:<hash>.

דוגמה ל-DAL עבור מזהה RP‏ example.com (מתארח בכתובת https://example.com/.well-known/assetlinks.json)

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.google.credentialmanager.sample",
      "sha256_cert_fingerprints": [
        "4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
      ]
    }
  }
]

למידע נוסף, ראו הגדרת Digital Asset Links בין האפליקציה לאתר

‫iOS: דומיינים משויכים

בפלטפורמות של אפל נדרש קובץ apple-app-site-association (AASA) בדומיין של מזהה ה-RP כדי לשייך אותו לאפליקציה.

• קובץ AASA: מארח https://<RP_ID>/.well-known/apple-app-site-association.
• זכויות שימוש: מוסיפים webcredentials:<app info> לזכויות השימוש באפליקציה.

דוגמה לקובץ AASA עבור מזהה של גורם מוגבל example.com: https://example.com/.well-known/apple-app-site-association:

{
  "webcredentials":
    {
      "apps": ["EXAMPLE123.com.example.passkey"]
    }
}

מידע נוסף זמין במאמר Connecting to a service with passkeys (חיבור לשירות באמצעות מפתחות גישה) במסמכי העזרה של אפל למפתחים.

סיכום

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

• היררכיה ותת-דומיינים: מזהה ה-RP חייב להיות מחרוזת דומיין (eTLD+1 או גבוה יותר). שימוש בדומיין רחב יותר כמו example.com מאפשר למפתחות גישה לפעול בכל תתי הדומיינים (לדוגמה, login.example.com ו-shop.example.com).
• פתרונות חוצי אתרים: משתמשים בבקשות ממקורות קשורים (ROR) לשירותים שפועלים בכמה דומיינים ברמה העליונה (eTLD) + 1. לשם כך נדרש מזהה RP וקובץ הגדרה בכתובת /.well-known/webauthn.
• שילוב בנייד: כדי ליצור קשר מאומת בין האתר שלכם לבין האפליקציות לנייד, צריך להשתמש בקובץ Digital Asset Links‏ (DAL) בנתיב /.well-known/assetlinks.json ב-Android, ובקובץ apple-app-site-association‏ (AASA) בנתיב /.well-known/apple-app-site-association ב-iOS.

מידע נוסף

• הודעות למפתחים של Chrome
• כאן אפשר לקרוא על פתרונות לניהול זהויות שזמינים ב-Chrome