إدارة مفاتيح المرور على نطاقات وتطبيقات متعددة باستخدام معرّف الجهة الاعتمادية

Eiji Kitamura

في WebAuthn ومفاتيح المرور، يحدّد معرّف الجهة المعتمِدة (RP ID) نطاق بيانات الاعتماد حسب اسم النطاق. عند إنشاء مفتاح مرور، يربطه المتصفّح بمعرّف RP محدّد. بعد ذلك، يمنع المتصفّح استخدام مفتاح المرور هذا على نطاق لا يتطابق مع المعرّف أو لا يندرج ضمن نطاقه. يضمن تحديد معرّف RP بشكلٍ صحيح تجربة سلسة لاستخدام مفتاح المرور على مستوى النطاقات الفرعية ومصادر المواقع الإلكترونية المختلفة وتطبيقات الأجهزة الجوّالة التابعة للطرف الأول.

أساسيات رقم تعريف الجهة المحظورة

معرّف الجهة المعتمِدة (RP ID) هو سلسلة فريدة تحدّد خدمتك أو موقعك الإلكتروني. يجب أن يكون معرّف الجهة المحظورة سلسلة نطاق. يمكن أن يكون اسم المضيف الحالي نفسه أو نطاقًا أصليًا أوسع، شرط أن يكون eTLD+1 أو أعلى. لا يمكنك استخدام عناوين IP واللاحقات العامة (eTLD) كمعرّف RP.

على سبيل المثال، إذا كنت تستضيف الخادم على 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 هو نطاق رفيع المستوى فعال)
https://myapp.pages.dev ‫myapp.pages.dev (pages.dev هو نطاق رفيع المستوى فعال)
http://localhost localhost (استثناء من شرط استخدام HTTPS)

يربط المتصفّح مفاتيح المرور بمعرّف الجهة الاعتمادية بشكل مشفّر عند إنشائها. لاستخدام بيانات اعتماد، يجب أن يتطابق مصدر طلب المصادقة مع معرّف الجهة المعتمدة.

عند استخدام 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)، يكون الإعداد على مستوى مواقع إلكترونية متعددة. لا تتوافق أرقام تعريف الجهات المحظورة العادية مع عمليات الإعداد على مستوى المواقع الإلكترونية.

لمشاركة مفاتيح المرور بين مواقع إلكترونية مختلفة، استخدِم طلبات المصدر المرتبط (ROR). تتيح لك ميزة "الربط بين المواقع الإلكترونية والتطبيقات" مشاركة مفاتيح المرور بين مواقع إلكترونية مختلفة لأنّ العميل (المتصفّح) يتعرّف على مصادر مختلفة كجزء من الخدمة المنطقية نفسها.

متطلبات ROR:

  • اختيار معرّف طرف معتمد واحد: يجب اختيار معرّف طرف معتمد واحد واستخدامه في جميع المواقع الإلكترونية.
  • استضافة ملف إعداد: يجب أن يستضيف نطاق معرّف 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 ملف رابط التنقل إلى مواد العرض الرقمية (DAL) على نطاق معرّف الجهة الاعتمادية لربطه بالتطبيق.

  • الاستضافة: استضِف الملف على https://<RP ID>/.well-known/assetlinks.json.
  • إثبات الملكية: أثبِت ملكية origin في clientDataJSON. بالنسبة إلى Android، تكون هذه السمة سلسلة مثل android:apk-key-hash:<hash>.

مثال على طبقة الوصول إلى البيانات لرقم تعريف الجهة المحظورة 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 ملف 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"]
    }
}

لمزيد من المعلومات، يمكنك الاطّلاع على الاتصال بخدمة باستخدام مفاتيح المرور في مستندات Apple Developer.

ملخّص

يحدّد معرّف الجهة الاعتمادية المكان الذي يمكن للمستخدمين الوصول إلى مفاتيح المرور فيه. ضَع النقاط التالية في الاعتبار أثناء التنفيذ:

  • التسلسل الهرمي والنطاقات الفرعية: يجب أن يكون معرّف الجهة المسؤولة سلسلة نطاق (eTLD+1 أو أعلى). يتيح استخدام نطاق أوسع مثل example.com إمكانية استخدام مفاتيح المرور في جميع النطاقات الفرعية (مثل login.example.com وshop.example.com).
  • حلول على مستوى المواقع الإلكترونية: استخدِم طلبات المصدر المرتبط (ROR) للخدمات التي تشمل نطاقات eTLD+1 متعددة. يتطلّب ذلك توفُّر معرّف RP واحد وملف إعداد في /.well-known/webauthn.
  • التكامل مع الأجهزة الجوّالة: يمكنك إنشاء علاقة تم التحقّق منها بين موقعك الإلكتروني وتطبيقاتك على الأجهزة الجوّالة باستخدام ملف روابط التنقل إلى مواد العرض الرقمية (DAL) في /.well-known/assetlinks.json على Android وملف apple-app-site-association (AASA) في /.well-known/apple-app-site-association على iOS.

مزيد من المعلومات