به روز رسانی FedCM: قطع API و دو به روز رسانی

Eiji Kitamura

از Chrome 122، Disconnect API for Federated Credential Management API (FedCM) در دسترس است. Disconnect API به طرف‌های متکی اجازه می‌دهد تا بدون اتکا به کوکی‌های شخص ثالث، ارتباط کاربران خود را از حساب ارائه‌دهنده هویت قطع کنند. همچنین، چند به روز رسانی برای مدیریت همان سایت FedCM وجود دارد.

قطع API

هنگامی که یک کاربر یک حساب کاربری بر روی یک طرف متکی (RP - سایتی که از ارائه دهنده هویت برای احراز هویت استفاده می کند) از طریق فدراسیون هویت ایجاد می کند، ارائه دهنده هویت (IdP - سرویسی که احراز هویت و اطلاعات حساب را به طرف های دیگر ارائه می دهد) معمولاً اتصال را در آن ثبت می کند. سرور اتصال ذخیره شده به IdP اجازه می دهد تا RP هایی را که کاربر به آن وارد شده است پیگیری کند و تجربه خود را بهینه کند. به عنوان مثال، برای داشتن تجربه بهتر زمانی که کاربر بعداً به RP بازمی‌گردد، حساب کاربری با IdP به عنوان یک حساب برگشتی در نظر گرفته می‌شود که به ویژگی‌هایی مانند احراز هویت مجدد خودکار و دکمه‌های شخصی‌سازی شده برای نمایش حساب استفاده‌شده اجازه می‌دهد.

گاهی اوقات، IdP ها یک API برای قطع ارتباط حساب از یک RP ارائه می دهند. با این حال، یک جریان قطع تایید شده است و به کوکی های IdP نیاز دارد. در دنیای بدون کوکی‌های شخص ثالث، وقتی کاربر از RP بازدید می‌کند، هیچ API مرورگری برای قطع ارتباط RP از IdP وجود ندارد. از آنجایی که ممکن است چندین حساب IdP از یک IdP یکسان به یک RP معین مرتبط باشد، جریان قطع ارتباط مستلزم دانستن اینکه کدام حساب قطع شده است.

Disconnect API به کاربر این امکان را می دهد تا با ارسال سیگنال به نقطه پایانی مشخص شده، حساب IdP را از RP در مرورگر و همچنین سرور IdP جدا کند. کاربر باید از طریق فدراسیون هویت با استفاده از API مدیریت اعتبار فدرال (FedCM) عبور کرده باشد. هنگامی که کاربر قطع می شود، دفعه بعد که سعی می کند با استفاده از IdP به RP وارد شود، به عنوان یک کاربر جدید در نظر گرفته می شود.

IdP را از RP جدا کنید

اگر کاربر قبلاً با استفاده از IdP از طریق FedCM وارد RP شده باشد، این رابطه توسط مرورگر به صورت محلی به عنوان فهرست حساب‌های متصل حفظ می‌شود. RP ممکن است با فراخوانی تابع IdentityCredential.disconnect() قطع ارتباط را آغاز کند. این تابع را می توان از یک فریم RP سطح بالا فراخوانی کرد. RP باید یک configURL ، clientId که در زیر IdP استفاده می‌کند، و یک accountHint برای IdP که قطع شود، ارسال کند. یک اشاره حساب می تواند یک رشته دلخواه باشد تا زمانی که نقطه پایانی قطع ارتباط بتواند حساب را شناسایی کند، برای مثال یک آدرس ایمیل یا شناسه کاربری که لزوماً با شناسه حسابی که نقطه پایان لیست حساب ارائه کرده است مطابقت ندارد:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() یک Promise برمی گرداند. این قول ممکن است به دلایل زیر استثناء ایجاد کند:

• کاربر با استفاده از IdP از طریق FedCM به سیستم RP وارد نشده است.
• API از داخل یک iframe بدون خط‌مشی مجوزهای FedCM فراخوانی می‌شود.
• configURL نامعتبر است یا نقطه پایانی قطع ارتباط را ندارد.
• بررسی خط مشی امنیت محتوا (CSP) ناموفق بود.
• یک درخواست قطع ارتباط معلق وجود دارد.
• کاربر FedCM را در تنظیمات مرورگر غیرفعال کرده است.

هنگامی که نقطه پایانی قطع اتصال IdP پاسخی را برمی‌گرداند ، RP و IdP در مرورگر قطع می‌شوند و وعده حل می‌شود. حساب های کاربری در حال قطع ارتباط در پاسخ از نقطه پایانی قطع ارتباط مشخص شده است.

توجه: اگر پاسخ معتبری از نقطه پایانی قطع ارتباط دریافت نشود یا شناسه حساب دریافتی با هیچ حسابی در لیست حساب‌های متصل مطابقت نداشته باشد، عامل کاربر همه حساب‌های منطبق با RP و IdP را از فهرست حساب‌های متصل حذف می‌کند.

فایل پیکربندی IdP را تنظیم کنید

برای پشتیبانی از Disconnect API، IdP باید یک نقطه پایانی قطع را پشتیبانی کند و ویژگی disconnect_endpoint و مسیر آن را در فایل پیکربندی IdP خود ارائه دهد.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

حساب را در نقطه پایانی قطع اتصال قطع کنید

با فراخوانی IdentityCredential.disconnect() ، مرورگر یک درخواست POST متقاطع را با کوکی ها و یک نوع محتوا از application/x-www-form-urlencoded به این نقطه پایانی قطع با اطلاعات زیر ارسال می کند:

ویژگی	شرح
account_hint	راهنمایی برای حساب IdP.
client_id	شناسه مشتری RP.

POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

پس از دریافت درخواست، سرور IdP باید:

1. با CORS (اشتراک گذاری منابع متقابل) به درخواست پاسخ دهید.
2. بررسی کنید که درخواست حاوی سرصفحه HTTP Sec-Fetch-Dest: webidentity باشد.
3. هدر Origin را با مبدا RP که توسط client_id تعیین می شود مطابقت دهید. اگر مطابقت نداشتند رد کنید.
4. حسابی را پیدا کنید که با account_hint مطابقت دارد.
5. حساب کاربری را از لیست حساب های متصل RP جدا کنید.
6. با استفاده از account_id کاربر شناسایی شده در قالب JSON به مرورگر پاسخ دهید.

اخطار: درخواست CORS دارای اعتبار است، به این معنی که Access-Control-Allow-Credentials: true باید ارسال شود و سرصفحه پاسخ Access-Control-Allow-Origin باید به جای استفاده از علامت "*" مبدأ مجاز را به صراحت نشان دهد. .

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://rp.example
Access-Control-Allow-Credentials: true
  

یک نمونه پاسخ JSON payload به این صورت است:

{
  "account_id": "account456"
}

اگر IdP بخواهد مرورگر به جای آن همه حساب‌های مرتبط با RP را قطع کند، رشته‌ای را ارسال کنید که با هیچ شناسه حسابی مطابقت ندارد، برای مثال "*" .

وقتی RP و IdP در یک سایت هستند، بررسی /.well-known/web-identity اکنون نادیده گرفته می شود.

هنگام توسعه یک سیستم FedCM، آزمایش یا مرحله بندی دامنه های سرور RP ممکن است زیر دامنه های سرور IdP تولیدی باشد. برای مثال، سرور IdP تولیدی در idp.example و هر دو سرور RP مرحله‌ای و سرور IdP مرحله‌ای در staging.idp.example هستند. با این حال، از آنجایی که فایل شناخته شده باید در ریشه eTLD+1 سرور IdP قرار گیرد، باید در idp.example/.well-known/web-identity و سرور تولید باشد. از آنجایی که برنامه‌نویسان لزوماً امکان قرار دادن فایل‌ها در محیط تولید را در حین توسعه ندارند، این امر مانع از آزمایش FedCM می‌شود.

با شروع از Chrome 122، اگر دامنه RP و دامنه IdP یکسان باشند، Chrome از بررسی فایل شناخته شده خودداری می کند. به این ترتیب توسعه دهندگان قادر خواهند بود در چنین سناریویی آزمایش کنند.

اکنون منابع فرعی می توانند وضعیت ورود به سایت را در همان سایت تنظیم کنند

قبلاً، Chrome فقط اجازه تنظیم وضعیت ورود به سیستم را می داد (به عنوان مثال، با استفاده از هدر Set-Login: logged-in ) زمانی که درخواست با همه اجداد یکسان باشد. این امر از ورود به سیستم از طریق درخواست‌های fetch() همان سایت که وضعیت ورود را تنظیم می‌کنند، جلوگیری می‌کند.

به عنوان مثال، به وب‌سایتی فکر کنید که به کاربران اجازه می‌دهد نام کاربری و رمز عبور خود را در idp.example وارد کنند، اما اعتبارنامه‌ها با fetch() در login.idp.example ارسال می‌شوند. ثبت وضعیت ورود به مرورگر با استفاده از Login Status API امکان پذیر نبود زیرا این دو دامنه دارای مبدا متقابل و یک سایت هستند.

با این تغییر، الزام API وضعیت ورود به سیستم را برای یکسان بودن سایت با همه اجداد کاهش داده ایم و مثال بالا را برای تنظیم وضعیت ورود به login.idp.example با استفاده از هدر HTTP امکان پذیر می کنیم ( Set-Login: logged-in ).

خلاصه

با استفاده از Disconnect API، FedCM اکنون می تواند بدون تکیه بر کوکی های شخص ثالث، RP را از IdP جدا کند. برای انجام این کار، IdentityCredential.disconnect() در RP فراخوانی کنید. با این عملکرد، مرورگر درخواستی را به نقطه پایانی قطع اتصال IdP ارسال می کند تا IdP بتواند اتصال را در سرور و سپس مرورگر قطع کند.

ما اعلام کرده‌ایم که برای اهداف آزمایشی وقتی RP و IdP یک سایت هستند، /.well-known/web-identity بررسی هویت وب حذف می‌شود. همچنین، تنظیم وضعیت ورود به سیستم از طریق هدر پاسخ HTTP از منبع فرعی IdP همان سایت اکنون امکان پذیر است.