اجازه استفاده مجدد از کلید عبور در سراسر سایت های خود با درخواست های مبدا مرتبط را بدهید

Maud Nalpas

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

این در شناسه طرف اتکاکننده (RP ID) مشخص شده است، که برای کلیدهای عبور ایجاد شده برای دامنه example.com می‌تواند www.example.com یا example.com باشد.

در حالی که شناسه‌های RP مانع از استفاده از کلیدهای عبور به عنوان یک اعتبارنامه واحد برای احراز هویت در همه جا می‌شوند، مشکلاتی را برای موارد زیر ایجاد می‌کنند:

• سایت‌هایی با چندین دامنه : کاربران نمی‌توانند از یک رمز عبور برای ورود به سیستم در دامنه‌های مختلف مختص به یک کشور (مثلاً example.com و example.co.uk ) که توسط یک شرکت مدیریت می‌شوند، استفاده کنند.
• دامنه‌های برندسازی‌شده : کاربران نمی‌توانند از یک اعتبارنامه در دامنه‌های مختلف مورد استفاده یک برند واحد (مثلاً acme.com و acmerewards.com ) استفاده کنند.
• برنامه‌های موبایل : برنامه‌های موبایل اغلب دامنه مخصوص به خود را ندارند و این امر مدیریت اعتبارنامه‌ها را چالش‌برانگیز می‌کند.

راه‌حل‌هایی مبتنی بر ادغام هویت و راه‌حل‌های دیگری مبتنی بر iframe وجود دارد، اما در برخی موارد نامناسب هستند. درخواست‌های مبدا مرتبط (Related Origin Requests) یک راه‌حل ارائه می‌دهند.

راه حل

با درخواست‌های مبدا مرتبط ، یک وب‌سایت می‌تواند مبداهایی را که مجاز به استفاده از شناسه 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 به عنوان شناسه‌ی RP استفاده می‌کند، ارسال کنند، مرورگر متوجه یک شناسه‌ی RP می‌شود که با مبدأ درخواست‌کننده مطابقت ندارد. اگر مرورگر از درخواست‌های مبدأ مرتبط پشتیبانی کند، ابتدا به دنبال یک فایل webauthn در https://{RP ID}/.well-known/webauthn . اگر فایل وجود داشته باشد، مرورگر بررسی می‌کند که آیا مبدأ درخواست‌کننده در allowlist قرار دارد یا خیر. در صورت مثبت بودن پاسخ، مراحل ایجاد کلید عبور یا احراز هویت ادامه می‌یابد.

اگر مرورگر از درخواست‌های مبدا مرتبط پشتیبانی نکند، SecurityError نمایش می‌دهد.

پشتیبانی مرورگر

تنظیم درخواست‌های مبدا مرتبط

نسخه آزمایشی زیر از دو سایت https://ror-1.glitch.me و https://ror-2.glitch.me استفاده می‌کند. برای اینکه کاربران بتوانند با یک رمز عبور در هر دو سایت وارد سیستم شوند، از درخواست‌های مبدا مرتبط (Related Origin Requests) استفاده می‌کند تا به 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 ایجاد می‌کنید، کروم می‌تواند آن را به طور خودکار در هر دو ror-1 و ror-2 وارد کند.
• اعتبارنامه‌ای که در هر یک از این سایت‌ها ایجاد می‌شود، دارای شناسه RP برابر با ror-1 خواهد بود.

کد را ببینید:

• فایل ./well-known/webauthn که در کدبیس ror-1 تنظیم شده است را ببینید.
• به رخدادهای RP_ID_ROR در کدبیس ror-2 مراجعه کنید.

مرحله ۱: پیاده‌سازی یک پایگاه داده حساب مشترک

اگر می‌خواهید کاربران شما بتوانند با یک رمز عبور یکسان در site-1 و site-2 وارد سیستم شوند، یک پایگاه داده حساب کاربری پیاده‌سازی کنید که در این دو سایت به اشتراک گذاشته شود.

مرحله ۲: فایل JSON با پسوند .well-known/webauthn را در site-1 تنظیم کنید.

ابتدا، site-1.com طوری پیکربندی کنید که به site-2.com اجازه دهد از آن به عنوان شناسه RP استفاده کند. برای انجام این کار، فایل webauthn JSON خود را ایجاد کنید:

{
    "origins": [
        "https://site-2.com"
    ]
}

شیء JSON باید حاوی کلیدی به نام origins باشد که مقدار آن آرایه‌ای از یک یا چند رشته حاوی web origins باشد.

محدودیت مهم: حداکثر ۵ برچسب

هر عنصر از این لیست برای استخراج برچسب eTLD + 1 پردازش خواهد شد. برای مثال، برچسب‌های eTLD + 1 مربوط به example.co.uk و example.de هر دو example هستند. اما برچسب eTLD + 1 مربوط به example-rewards.com example-rewards است. در کروم، حداکثر تعداد برچسب‌ها 5 است.

مرحله ۳: فایل JSON با پسوند .well-known/webauthn خود را در site-1 قرار دهید.

سپس، فایل JSON خود را در مسیر site-1.com/.well-known/webauthn قرار دهید.

برای مثال، در اکسپرس:

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' ) را تنظیم می‌کند.

مرحله ۴: شناسه RP را در site-2 مشخص کنید

در کدبیس site-2 خود، site-1.com به عنوان شناسه RP در هر جایی که لازم است تنظیم کنید:

• پس از ایجاد اعتبارنامه:
  • در options ایجاد اعتبارنامه که به فراخوانی frontend تابع navigator.credentials.create ارسال می‌شوند و معمولاً در سمت سرور تولید می‌شوند، site-1.com به عنوان شناسه RP تنظیم کنید.
  • هنگام اجرای تأیید اعتبار قبل از ذخیره آن در پایگاه داده، site-1.com به عنوان شناسه RP مورد انتظار تنظیم کنید.
• پس از احراز هویت:
  • در options احراز هویت که به فراخوانی frontend تابع navigator.credentials.get ارسال می‌شوند و معمولاً سمت سرور تولید می‌شوند، site-1.com به عنوان شناسه RP تنظیم کنید.
  • site-1.com به عنوان شناسه RP مورد انتظار برای تأیید در سرور تنظیم کنید، زیرا قبل از تأیید اعتبار کاربر، تأیید اعتبار را انجام می‌دهید.

عیب‌یابی

ملاحظات دیگر

اشتراک‌گذاری رمزهای عبور در سایت‌ها و برنامه‌های تلفن همراه

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

• در کروم: پیوندهای دارایی دیجیتال . برای اطلاعات بیشتر به افزودن پشتیبانی برای پیوندهای دارایی دیجیتال مراجعه کنید .
• در سافاری: دامنه‌های مرتبط .

اشتراک‌گذاری رمزهای عبور در سایت‌های مختلف

درخواست‌های مبدا مرتبط به کاربران شما اجازه می‌دهد تا از یک رمز عبور در سایت‌های مختلف، دوباره استفاده کنند. راهکارهای اشتراک‌گذاری رمزهای عبور در سایت‌های مختلف، بین مدیران رمز عبور متفاوت است. برای مدیریت رمز عبور گوگل، از Digital Asset Links استفاده کنید. سافاری سیستم متفاوتی دارد.

نقش مدیران اعتبارنامه و نمایندگان کاربر

این فراتر از محدوده شما به عنوان یک توسعه‌دهنده سایت است، اما توجه داشته باشید که در درازمدت، شناسه RP نباید یک مفهوم قابل مشاهده برای کاربر در عامل کاربر یا مدیر اعتبارنامه‌ای باشد که کاربران شما از آن استفاده می‌کنند. در عوض، عامل‌های کاربر و مدیران اعتبارنامه باید به کاربران نشان دهند که اعتبارنامه‌هایشان کجا استفاده شده است. اجرای این تغییر زمان‌بر خواهد بود. یک راه حل موقت، نمایش همزمان وب‌سایت فعلی و سایت ثبت نام اصلی است.