مشکل Related Origin Requests حل می شود
رمز عبور به یک وب سایت خاص گره خورده است و فقط می تواند برای ورود به وب سایتی که برای آن ایجاد شده است استفاده شود.
این در شناسه شخص متکی (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
خواهد بود.
مشاهده کد:
- فایل
./well-known/webauthn
را ببینید که در پایگاه کد ror-1 تنظیم شده است. - مشاهده
RP_ID_ROR
در پایگاه کد ror-2 .
مرحله 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
ایجاد اعتبار که به فراخوانی frontendnavigator.credentials.create
ارسال میشود و معمولاً در سمت سرور ایجاد میشود، تنظیم کنید. -
site-1.com
به عنوان شناسه RP مورد انتظار تنظیم کنید، زیرا تأیید اعتبار را قبل از ذخیره آن در پایگاه داده خود اجرا می کنید.
-
- پس از احراز هویت:
-
site-1.com
بهعنوان شناسه RP درoptions
احراز هویت که به فراخوانی frontendnavigator.credentials.get
ارسال میشوند و معمولاً در سمت سرور ایجاد میشوند، تنظیم کنید. -
site-1.com
به عنوان شناسه RP مورد انتظار برای تأیید در سرور تنظیم کنید، زیرا قبل از تأیید اعتبار کاربر، تأیید اعتبار را اجرا می کنید.
-
عیب یابی
ملاحظات دیگر
کلیدهای عبور را در بین سایت ها و برنامه های تلفن همراه به اشتراک بگذارید
Related Origin Requests به کاربران شما این امکان را می دهد که از یک رمز عبور در چندین سایت استفاده مجدد کنند. برای اینکه به کاربران خود امکان استفاده مجدد از رمز عبور در یک وب سایت و یک برنامه تلفن همراه را بدهید، از تکنیک های زیر استفاده کنید:
- در کروم: پیوندهای دارایی دیجیتال . در افزودن پشتیبانی برای پیوندهای دارایی دیجیتال بیشتر بیاموزید.
- در سافاری: دامنه های مرتبط .
به اشتراک گذاری رمز عبور در سراسر سایت ها
Related Origin Requests به کاربران شما این امکان را می دهد که از یک رمز عبور در سراسر سایت ها استفاده مجدد کنند. راه حل های اشتراک گذاری رمز عبور در سایت ها بین مدیران رمز عبور متفاوت است. برای Google Password Manager، از پیوندهای دارایی دیجیتال استفاده کنید. سافاری سیستم متفاوتی دارد.
نقش مدیران اعتبار و عوامل کاربر
این فراتر از محدوده شما به عنوان یک توسعهدهنده سایت است، اما توجه داشته باشید که در بلندمدت، شناسه RP نباید یک مفهوم قابل مشاهده برای کاربر در عامل کاربر یا مدیر اعتباری که کاربران شما از آن استفاده میکنند باشد. در عوض، نمایندگان کاربر و مدیران اعتبار باید به کاربران نشان دهند که در کجا از اعتبار آنها استفاده شده است. اجرای این تغییر به زمان نیاز دارد. یک راه حل موقت نمایش هر دو وب سایت فعلی و سایت ثبت نام اصلی است.