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

مود نالپاس
Maud Nalpas
X GitHub

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

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

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

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

راه‌حل‌هایی بر اساس فدراسیون هویت، و راه‌حل‌هایی بر اساس iframe وجود دارد، اما در برخی موارد ناخوشایند هستند. Related Origin Requests راه حلی ارائه می دهد.

راه حل

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

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

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

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

  • Chrome: از Chrome 128 پشتیبانی می‌شود.
  • سافاری: از macOS 15 beta 3 و در iOS 18 beta 3 موبایل پشتیبانی می‌شود.
  • فایرفاکس: در انتظار موقعیت

دمو زیر از نمونه دو سایت 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 درخواست های Related Origin را برای استفاده از 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 ایجاد می‌کنید، می‌تواند توسط Chrome در ror-1 و ror-2 به‌طور خودکار پر شود.
  • اعتبار ایجاد شده در هر یک از این سایت ها دارای شناسه RP از ror-1 خواهد بود.
کروم در هر دو سایت تکمیل خودکار می کند.
به لطف Related Origin Requests، کاربران می‌توانند از اعتبار کلید عبور یکسانی در ror-1 و ror-2 استفاده کنند. Chrome همچنین اعتبارنامه ها را به صورت خودکار تکمیل می کند.

مشاهده کد:

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

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

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

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

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

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

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

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

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

  • پس از ایجاد اعتبار:
    • 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 مورد انتظار برای تأیید در سرور تنظیم کنید، زیرا قبل از تأیید اعتبار کاربر، تأیید اعتبار را اجرا می کنید.

عیب یابی

پنجره بازشو پیام خطا در کروم.
پیام خطا در Chrome هنگام ایجاد اعتبار. اگر فایل ".well-known/webauthn" شما در "https://{RP ID}/.well-known/webauthn" یافت نشود، این خطا رخ می دهد.
پنجره بازشو پیام خطا در کروم.
پیام خطا در Chrome هنگام ایجاد اعتبار. اگر فایل ".well-known/webauthn" شما پیدا شود، این خطا رخ می دهد، اما مبدایی را که می خواهید از آن اعتبارنامه ایجاد کنید، فهرست نمی کند.

ملاحظات دیگر

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

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

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

Related Origin Requests به کاربران شما این امکان را می دهد که از یک رمز عبور در سراسر سایت ها استفاده مجدد کنند. راه حل های اشتراک گذاری رمز عبور در سایت ها بین مدیران رمز عبور متفاوت است. برای Google Password Manager، از پیوندهای دارایی دیجیتال استفاده کنید. سافاری سیستم متفاوتی دارد.

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

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