مدیریت کلیدهای عبور در چندین دامنه و برنامه با RP ID

Eiji Kitamura

در WebAuthn و کلیدهای عبور، شناسه طرف متکی (RP ID) دامنه یک اعتبارنامه را با نام دامنه مشخص می‌کند. وقتی یک کلید عبور ایجاد می‌کنید، مرورگر آن را به یک شناسه RP خاص مرتبط می‌کند. سپس مرورگر از استفاده از آن کلید عبور در دامنه‌ای که با آن شناسه مطابقت ندارد یا در محدوده آن قرار نمی‌گیرد، جلوگیری می‌کند. تعریف صحیح شناسه RP شما، یک تجربه یکپارچه از کلید عبور را در زیر دامنه‌ها، سایت‌های مبدا و برنامه‌های تلفن همراه شخص اول تضمین می‌کند.

اصول اولیه RP ID

شناسه طرف اتکا (RP ID) یک رشته منحصر به فرد است که سرویس یا وب‌سایت شما را شناسایی می‌کند. شناسه RP باید یک رشته دامنه باشد. می‌تواند دقیقاً نام میزبان فعلی یا یک دامنه والد گسترده‌تر باشد، مشروط بر اینکه 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` یک 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 خاص‌تر مانند login.example.com روی مبدأ دقیق خود کار می‌کند اما روی https://shop.example.com کار نمی‌کند.

شناسه RP در زمینه‌های بین سایتی

اگر سرویس شما شامل چندین eTLD+1 باشد (مثلاً example.com و example.co.jp )، این یک پیکربندی بین سایتی است. شناسه‌های استاندارد RP از تنظیمات بین سایتی پشتیبانی نمی‌کنند.

برای اشتراک‌گذاری کلیدهای عبور بین سایت‌های مجزا، از درخواست‌های مبدا مرتبط (ROR) استفاده کنید. ROR به شما امکان می‌دهد کلیدهای عبور را بین سایت‌های مجزا به اشتراک بگذارید زیرا کلاینت (مرورگر) مبداهای مختلف را به عنوان بخشی از یک سرویس منطقی یکسان تشخیص می‌دهد.

الزامات ROR:

یک شناسه RP انتخاب کنید: شما باید یک شناسه RP انتخاب کنید و از آن در تمام سایت‌ها استفاده کنید.
میزبانی یک فایل پیکربندی: دامنه اصلی RP ID باید میزبان یک فایل پیکربندی در /.well-known/webauthn باشد که فهرستی از منابع مجاز را ارائه می‌دهد.
حفظ ثبات: حتی اگر کاربر در آدرس https://www.example.co.jp باشد، rpId در فراخوانی WebAuthn باید هم در هنگام ایجاد و هم در هنگام احراز هویت، شناسه اصلی (مثلاً example.com ) باشد.

مثال ROR برای شناسه RP، example.com : https://example.com/.well-known/webauthn

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

برای اطلاعات بیشتر در مورد جزئیات پیاده‌سازی درخواست‌های مبدا مرتبط، به بخش «اجازه استفاده مجدد از کلید عبور در سایت‌های شما با درخواست‌های مبدا مرتبط» مراجعه کنید.

شناسه RP در برنامه‌های تلفن همراه

برنامه‌های موبایل می‌توانند با اتصال به یک دامنه وب از کلیدهای عبور استفاده کنند. برای ایجاد این ارتباط، باید یک فایل تأیید هویت روی سرور خود داشته باشید.

اندروید: لینک‌های دارایی دیجیتال

مدیر اعتبارنامه اندروید برای ارتباط با برنامه به یک فایل پیوند دارایی دیجیتال (DAL) در دامنه RP ID نیاز دارد.

میزبانی: فایل را در https://<RP ID>/.well-known/assetlinks.json میزبانی کنید.
تأیید: origin در clientDataJSON تأیید کنید. برای اندروید، این رشته‌ای مانند 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"
      ]
    }
  }
]

برای اطلاعات بیشتر، به پیکربندی پیوندهای دارایی دیجیتال بین برنامه و وب‌سایت خود مراجعه کنید.

iOS: دامنه‌های مرتبط

پلتفرم‌های اپل برای ارتباط با برنامه به یک فایل apple-app-site-association (AASA) در دامنه RP ID نیاز دارند.

فایل AASA: میزبان https://<RP_ID>/.well-known/apple-app-site-association .
مجوزهای دسترسی: webcredentials:<app info> را به مجوزهای دسترسی برنامه اضافه کنید.

نمونه AASA برای RP ID example.com : https://example.com/.well-known/apple-app-site-association :

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

برای اطلاعات بیشتر، به بخش «اتصال به سرویس با کلیدهای عبور» در مستندات توسعه‌دهندگان اپل مراجعه کنید.

خلاصه

شناسه RP تعیین می‌کند که کاربران شما از کجا به کلیدهای عبور خود دسترسی پیدا می‌کنند. هنگام پیاده‌سازی، این نکات را در نظر داشته باشید:

سلسله مراتب و زیر دامنه‌ها : شناسه RP باید یک رشته دامنه (eTLD+1 یا بالاتر) باشد. استفاده از دامنه وسیع‌تری مانند example.com باعث می‌شود کلیدهای عبور در تمام زیر دامنه‌ها (مثلاً login.example.com و shop.example.com ) کار کنند.
راهکارهای بین سایتی : برای سرویس‌هایی که چندین eTLD+1 را پوشش می‌دهند، از درخواست‌های مبدا مرتبط (ROR) استفاده کنید. این کار به یک شناسه RP و یک فایل پیکربندی در /.well-known/webauthn نیاز دارد.
ادغام موبایل : با استفاده از یک فایل Digital Asset Links (DAL) در آدرس /.well-known/assetlinks.json برای اندروید و یک فایل apple-app-site-association (AASA) در آدرس /.well-known/apple-app-site-association برای iOS، یک رابطه تأیید شده بین وب‌سایت و برنامه‌های تلفن همراه خود ایجاد کنید.