این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

به‌روزرسانی‌های FedCM: آزمایش‌های اولیه برای بسته API Continuation و اعطای خودکار API دسترسی به حافظه

Eiji Kitamura

از Chrome 126، توسعه‌دهندگان می‌توانند یک نسخه آزمایشی اصلی را برای مجموعه‌ای از ویژگی‌های مدیریت اعتبار فدرال API (FedCM) دسک‌تاپ که برخی از موارد استفاده از مجوز را فعال می‌کنند، شروع کنند. این بسته شامل Continuation API و Parameters API است که تجربه‌ای مشابه جریان مجوز OAuth را که شامل گفتگوی مجوز ارائه‌شده توسط ارائه‌دهنده هویت (IdP) است، فعال می‌کند. این بسته همچنین شامل تغییرات دیگری مانند Fields API، چندین configURL و برچسب‌های حساب سفارشی است. از Chrome 126، ما همچنین یک نسخه آزمایشی اصلی را برای Storage Access API (SAA) معرفی می‌کنیم که اگر کاربر با استفاده از FedCM در گذشته با موفقیت وارد سیستم شده باشد، درخواست‌های SAA را به‌طور خودکار اعطا می‌کند.

آزمایش اولیه: بسته نرم افزاری API ادامه FedCM

بسته نرم افزاری API Continuation FedCM از چندین افزونه FedCM تشکیل شده است:

Continuation API
API پارامترها
Fields API
چندین configURL
برچسب های حساب سفارشی

Continuation API

کاربر در حال ورود به RP است و سپس از طریق حالت دکمه مجوز می دهد.

می‌توانید نسخه آزمایشی API را در Glitch بررسی کنید.

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

به طور معمول، نقطه پایانی ادعای ID یک رمز مورد نیاز برای احراز هویت را برمی‌گرداند.

{
  "token": "***********"
}

با این حال، با Continuation API، نقطه پایانی ادعای ID می‌تواند یک ویژگی continue_on برگرداند که شامل یک مسیر مطلق یا یک مسیر نسبی به نقطه پایانی ادعای ID است.

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

به محض اینکه مرورگر پاسخ continue_on را دریافت کرد، یک پنجره بازشو باز می شود و کاربر را به مسیر مشخص شده هدایت می کند.

پس از تعامل کاربر با صفحه، برای مثال دادن مجوز بیشتر برای اشتراک‌گذاری اطلاعات اضافی با RP، صفحه IdP می‌تواند با فراخوانی IdentityProvider.resolve() فراخوانی navigator.credentials.get() اصلی را حل کند و یک توکن را به عنوان آرگومان برگرداند.

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

سپس مرورگر به خودی خود پنجره بازشو را می بندد و توکن را به تماس گیرنده API برمی گرداند.

اگر کاربر درخواست را رد کرد، می توانید با فراخوانی IdentityProvider.close() پنجره را ببندید.

IdentityProvider.close();

اگر به دلایلی کاربر حساب خود را در پنجره بازشو تغییر داده باشد (مثلاً IdP یک عملکرد "تغییر کاربر" یا در موارد تفویض اختیار ارائه می دهد)، فراخوانی حل یک آرگومان دوم اختیاری را می گیرد که چیزی شبیه به:

IdentityProvider.resolve(token, {accountId: '1234');

API پارامترها

Parameters API به RP اجازه می دهد تا پارامترهای اضافی را به نقطه پایانی ادعای ID ارائه دهد. با Parameters API، RP ها می توانند پارامترهای اضافی را به IdP ارسال کنند تا مجوزهایی را برای منابعی فراتر از ورود به سیستم اولیه درخواست کنند. کاربر این مجوزها را از طریق یک جریان UX کنترل شده با IdP که از طریق Continuation API راه اندازی می شود، مجاز می کند.

برای استفاده از API، پارامترهایی را به ویژگی params به عنوان یک شی در فراخوانی navigator.credentials.get() اضافه کنید.

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

نام خصوصیات در شی params با param_ اضافه می شود. در مثال بالا، ویژگی params شامل IDP_SPECIFIC_PARAM به عنوان '1' ، foo به عنوان 'BAR' ، ETC به عنوان 'MOAR' و scope به عنوان 'calendar.readonly photos.write' است. این به عنوان param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write در متن HTTP درخواست ترجمه می‌شود:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

مجوزها را به صورت پویا دریافت کنید

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

برای درخواست مجوز به صورت پویا با FedCM، IdP می تواند:

navigator.credentials.get() را با پارامترهای مورد نیازی که IdP می تواند بفهمد، مانند scope فراخوانی کنید.
نقطه پایانی ادعای شناسه تأیید می‌کند که کاربر قبلاً وارد سیستم شده است و با URL continue_on پاسخ می‌دهد.
مرورگر یک پنجره بازشو با صفحه مجوز IdP باز می کند که از آن درخواست مجوز اضافی می کند که با محدوده های درخواستی مطابقت دارد.
هنگامی که از طریق IdentityProvider.resolve() توسط IdP مجاز شد، پنجره بسته می شود و فراخوانی navigator.credentials.get() اصلی RP یک توکن مربوطه یا یک کد مجوز دریافت می کند تا RP بتواند آن را با یک توکن دسترسی مناسب مبادله کند.

Fields API

Fields API به RP اجازه می دهد تا ویژگی های حساب را برای درخواست از IdP اعلام کند تا مرورگر بتواند یک UI افشای مناسب را در گفتگوی FedCM ارائه دهد. این مسئولیت IdP است که فیلدهای درخواستی را در توکن برگشتی قرار دهد. این را در نظر بگیرید که یک "نمایه پایه" در OpenID Connect در مقابل "scopes" در OAuth درخواست کنید.

برای استفاده از Fields API، در فراخوانی navigator.credentials.get() پارامترهایی را به ویژگی fields به عنوان یک آرایه اضافه کنید. فیلدها می‌توانند فعلاً حاوی 'name' ، 'email' و 'picture' باشند، اما می‌توان آن‌ها را برای گنجاندن مقادیر بیشتری در آینده گسترش داد.

یک درخواست با fields به شکل زیر است:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

درخواست HTTP به نقطه پایانی ادعای شناسه شامل پارامتر fields مشخص شده با RP، با پارامتر disclosure_text_shown در صورتی که کاربر بازگشتی نباشد، true ، و فیلدهایی که مرورگر در پارامتر disclosure_shown_for برای کاربر فاش کرده است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

اگر RP نیاز به دسترسی به هر گونه داده اضافی از IdP، مانند دسترسی به یک تقویم دارد، باید با یک پارامتر سفارشی همانطور که در بالا ذکر شد مدیریت شود. IdP یک URL continue_on را برای درخواست مجوز برمی‌گرداند.

اگر fields یک آرایه خالی باشد، درخواست به شکل زیر خواهد بود:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

اگر fields یک آرایه خالی باشد، عامل کاربر رابط کاربری افشا را رد می کند.

پیام افشا در حالت ویجت نمایش داده نمی شود. در جریان دکمه، رابط کاربری افشا به طور کامل نادیده گرفته می شود.

این مورد حتی اگر پاسخ از نقطه پایانی حساب‌ها حاوی شناسه مشتری نباشد که با RP در approved_clients مطابقت داشته باشد.

در این مورد، disclosure_text_shown ارسال شده به نقطه پایانی اعلام شناسه در بدنه HTTP نادرست است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

چندین configURL

چندین configURL به IdP ها اجازه می دهد تا چندین فایل پیکربندی را برای یک IdP با مشخص کردن accounts_endpoint و login_url در فایل شناخته شده مانند فایل های پیکربندی در خود جای دهند.

اگر accounts_endpoint و login_url به فایل شناخته شده اضافه شوند، provider_urls نادیده گرفته می شود تا IdP بتواند چندین فایل پیکربندی را پشتیبانی کند. اگر اینطور نیست، provider_urls همچنان به کار خود ادامه می دهد تا با نسخه قبلی سازگار باشد.

فایل معروفی که از چندین configURL پشتیبانی می کند می تواند به شکل زیر باشد:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

این به ما امکان می دهد:

سازگاری عقب و جلو را با فایل‌های شناخته شده موجود و نسخه قبلی مرورگرهایی که قبلاً در طبیعت مستقر شده‌اند، حفظ کنید.
تعداد دلخواه فایل های پیکربندی داشته باشید—تا زمانی که همه آنها به یک accounts_endpoint و login_url اشاره کنند.
هیچ فرصتی برای آنتروپی برای اضافه شدن به درخواست واکشی اعتباری ارائه شده به accounts_endpoint وجود ندارد، زیرا باید در سطح ".well-known" مشخص شود.

پشتیبانی از چندین configURL اختیاری است و پیاده سازی های موجود FedCM می توانند ثابت بمانند.

برچسب های حساب سفارشی

برچسب‌های حساب سفارشی به IdP‌های FedCM اجازه می‌دهند حساب‌ها را حاشیه‌نویسی کنند تا RPها بتوانند با تعیین برچسب در یک فایل پیکربندی، آن‌ها را فیلتر کنند. فیلتر کردن مشابهی با استفاده از Domain Hint API و Login Hint API با مشخص کردن آنها در فراخوانی navigator.credentials.get() امکان پذیر بوده است، اما برچسب های حساب سفارشی می توانند کاربران را با تعیین فایل پیکربندی فیلتر کنند، که به ویژه در هنگام استفاده از چندین configURL مفید است. برچسب‌های حساب سفارشی نیز از این جهت متفاوت هستند که از سرور IdP ارائه می‌شوند، برخلاف RP، مانند نکات ورود به سیستم یا دامنه.

مثال

یک IdP به ترتیب از دو configURL برای مصرف کننده و شرکت پشتیبانی می کند. فایل پیکربندی مصرف‌کننده دارای برچسب 'consumer' و فایل پیکربندی سازمانی دارای برچسب 'enterprise' است.

با چنین تنظیماتی، فایل شناخته شده شامل accounts_endpoint و login_url است تا چندین configURL را مجاز کند.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

هنگامی که accounts_endpoint در فایل شناخته شده ارائه می شود، provider_urls نادیده گرفته می شوند. RP می تواند مستقیماً به فایل های پیکربندی مربوطه در فراخوانی navigator.credentials.get() اشاره کند.

فایل پیکربندی مصرف‌کننده در https://idp.example/fedcm.json است که شامل ویژگی accounts است که 'consumer' با استفاده از include مشخص می‌کند.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

فایل پیکربندی سازمانی در https://idp.example/enterprise/fedcm.json قرار دارد، که شامل ویژگی accounts است که با استفاده از include 'enterprise' را مشخص می‌کند.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

نقطه پایانی مشترک IdP حساب‌ها (در این مثال https://idp.example/accounts ) فهرستی از حساب‌ها را برمی‌گرداند که شامل یک ویژگی labels با labels اختصاص داده شده در یک آرایه برای هر حساب است. در زیر یک نمونه پاسخ برای کاربری است که دو حساب دارد. یکی برای مصرف کننده و دیگری برای شرکت است:

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

هنگامی که یک RP می‌خواهد به کاربران 'enterprise' اجازه ورود به سیستم را بدهد، می‌توانند configURL 'enterprise' 'https://idp.example/enterprise/fedcm.json' در فراخوانی navigator.credentials.get() مشخص کنند:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

در نتیجه، فقط شناسه حساب '4567' برای ورود کاربر در دسترس است. شناسه حساب '123' به‌طور بی‌صدا توسط مرورگر پنهان می‌شود تا حسابی به کاربر ارائه نشود که توسط IdP در این سایت پشتیبانی نمی‌شود.

توجه:

برچسب ها رشته هستند. اگر آرایه labels یا فیلد include چیزی باشد که رشته نیست، نادیده گرفته می‌شود.
اگر هیچ برچسبی در configURL مشخص نشده باشد، همه حساب ها در انتخابگر حساب FedCM نمایش داده می شوند.
اگر هیچ برچسبی برای یک حساب مشخص نشده باشد، تنها در صورتی در انتخابگر حساب نمایش داده می شود که configURL نیز برچسبی را مشخص نکرده باشد.
اگر هیچ حسابی با برچسب درخواستی در جریان ویجت مطابقت نداشته باشد (شبیه به Domain Hint API)، گفتگوی FedCM یک اعلان ورود را نشان می دهد که به کاربر اجازه می دهد به یک حساب IdP وارد شود. برای جریان دکمه، پنجره بازشوی ورود مستقیماً باز می شود.

آزمایش اولیه: FedCM به عنوان یک سیگنال اعتماد برای Storage Access API

Chrome 126 در حال شروع آزمایش اولیه FedCM به عنوان یک سیگنال اعتماد برای Storage Access API است. با این تغییر، اعطای مجوز قبلی از طریق FedCM دلیل معتبری برای تأیید خودکار درخواست دسترسی به فضای ذخیره‌سازی توسط Storage Access APIها می‌شود.

این زمانی مفید است که یک iframe تعبیه‌شده بخواهد به منابع شخصی‌شده دسترسی پیدا کند: برای مثال، اگر idp.example در rp.example جاسازی شده باشد و نیاز به نشان دادن یک منبع شخصی‌شده داشته باشد. اگر مرورگر دسترسی به کوکی‌های شخص ثالث را محدود کند، حتی اگر کاربر با استفاده از idp.example با FedCM وارد rp.example شده باشد، iframe idp.example جاسازی‌شده نمی‌تواند منابع شخصی‌شده را درخواست کند زیرا درخواست‌ها شامل کوکی‌های شخص ثالث نمی‌شوند.

برای رسیدن به این هدف، idp.example باید از طریق iframe تعبیه‌شده در وب‌سایت، مجوز دسترسی به فضای ذخیره‌سازی را دریافت کند، و این فقط از طریق یک درخواست مجوز قابل دریافت است.

با FedCM به‌عنوان یک سیگنال اعتماد برای Storage Access API ، بررسی‌های مجوز API دسترسی به ذخیره‌سازی نه تنها اعطای مجوزی را که توسط یک درخواست دسترسی به ذخیره‌سازی داده می‌شود، بلکه اعطای مجوز ارائه شده توسط یک درخواست FedCM را نیز می‌پذیرد.

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

هنگامی که کاربر با FedCM وارد شد، تا زمانی که احراز هویت FedCM فعال باشد، مجوز به طور خودکار اعطا می شود. این بدان معناست که پس از قطع ارتباط کاربر، درخواست مجوز یک اعلان نشان می دهد.

در آزمایش مبدا شرکت کنید

با روشن کردن پرچم Chrome chrome://flags#fedcm-authz در Chrome 126 یا جدیدتر، می‌توانید بسته API Continuation FedCM را به صورت محلی امتحان کنید. همچنین می‌توانید با روشن کردن #fedcm-with-storage-access-api در Chrome 126 یا جدیدتر، FedCM را به‌عنوان یک سیگنال اعتماد برای Storage Access API به صورت محلی امتحان کنید.

این ویژگی‌ها به‌عنوان آزمایش‌های اولیه نیز در دسترس هستند. آزمایش‌های مبدأ به شما امکان می‌دهد ویژگی‌های جدید را امتحان کنید و در مورد قابلیت استفاده، عملی و اثربخشی آنها بازخورد بدهید. برای اطلاعات بیشتر، شروع به کار با آزمایش‌های اولیه را بررسی کنید.

برای امتحان نسخه آزمایشی اولیه بسته نرم افزاری FedCM Continuation ، دو نشانه آزمایشی مبدا ایجاد کنید:

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

اگر علاقه مند به فعال کردن Continuation API به همراه جریان دکمه هستید، آزمایش اولیه API Button Mode را نیز فعال کنید:

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

برای امتحان FedCM به عنوان یک سیگنال اعتماد برای آزمایش اولیه Storage Access API :

برای آزمایش اولیه ثبت نام کنید. توکن را در مبدا IdP جاسازی کنید .

نسخه آزمایشی اصلی بسته API Continuation و FedCM به عنوان یک سیگنال اعتماد برای آزمایش اولیه Storage Access API از Chrome 126 در دسترس هستند.

یک آزمایش اولیه شخص ثالث برای RP ثبت کنید

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

برای جاسازی توکن در یک وب سایت شخص ثالث، کد زیر را به کتابخانه جاوا اسکریپت IdP یا SDK که از مبدا IdP ارائه می شود، اضافه کنید.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

TOKEN_GOES_HERE با توکن خود جایگزین کنید.

Eiji Kitamura

آزمایش اولیه: بسته نرم افزاری API ادامه FedCM

بسته نرم افزاری API Continuation FedCM از چندین افزونه FedCM تشکیل شده است:

Continuation API
API پارامترها
Fields API
چندین configURL
برچسب های حساب سفارشی

Continuation API

کاربر در حال ورود به RP است و سپس از طریق حالت دکمه مجوز می دهد.

می‌توانید نسخه آزمایشی API را در Glitch بررسی کنید.

به طور معمول، نقطه پایانی ادعای ID یک رمز مورد نیاز برای احراز هویت را برمی‌گرداند.

{
  "token": "***********"
}

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

سپس مرورگر به خودی خود پنجره بازشو را می بندد و توکن را به تماس گیرنده API برمی گرداند.

اگر کاربر درخواست را رد کرد، می توانید با فراخوانی IdentityProvider.close() پنجره را ببندید.

IdentityProvider.close();

IdentityProvider.resolve(token, {accountId: '1234');

API پارامترها

برای استفاده از API، پارامترهایی را به ویژگی params به عنوان یک شی در فراخوانی navigator.credentials.get() اضافه کنید.

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

مجوزها را به صورت پویا دریافت کنید

برای درخواست مجوز به صورت پویا با FedCM، IdP می تواند:

navigator.credentials.get() را با پارامترهای مورد نیازی که IdP می تواند بفهمد، مانند scope فراخوانی کنید.
نقطه پایانی ادعای شناسه تأیید می‌کند که کاربر قبلاً وارد سیستم شده است و با URL continue_on پاسخ می‌دهد.
مرورگر یک پنجره بازشو با صفحه مجوز IdP باز می کند که از آن درخواست مجوز اضافی می کند که با محدوده های درخواستی مطابقت دارد.
هنگامی که از طریق IdentityProvider.resolve() توسط IdP مجاز شد، پنجره بسته می شود و فراخوانی navigator.credentials.get() اصلی RP یک توکن مربوطه یا یک کد مجوز دریافت می کند تا RP بتواند آن را با یک توکن دسترسی مناسب مبادله کند.

Fields API

یک درخواست با fields به شکل زیر است:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

درخواست HTTP به نقطه پایانی ادعای شناسه شامل پارامتر fields مشخص شده با RP، با پارامتر disclosure_text_shown در صورتی که کاربر بازگشتی نباشد، true است، و فیلدهایی که مرورگر در پارامتر disclosure_shown_for برای کاربر فاش کرده است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

اگر fields یک آرایه خالی باشد، درخواست به شکل زیر خواهد بود:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

اگر fields یک آرایه خالی باشد، عامل کاربر رابط کاربری افشا را رد می کند.

این مورد حتی اگر پاسخ از نقطه پایانی حساب‌ها حاوی شناسه مشتری نباشد که با RP در approved_clients مطابقت داشته باشد.

در این مورد، disclosure_text_shown ارسال شده به نقطه پایانی اعلام شناسه در بدنه HTTP نادرست است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

چندین configURL

فایل معروفی که از چندین configURL پشتیبانی می کند می تواند به شکل زیر باشد:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

این به ما امکان می دهد:

سازگاری عقب و جلو را با فایل‌های شناخته شده موجود و نسخه قبلی مرورگرهایی که قبلاً در طبیعت مستقر شده‌اند، حفظ کنید.
تعداد دلخواه فایل های پیکربندی داشته باشید—تا زمانی که همه آنها به یک accounts_endpoint و login_url اشاره کنند.
هیچ فرصتی برای آنتروپی برای اضافه شدن به درخواست واکشی اعتباری ارائه شده به accounts_endpoint وجود ندارد، زیرا باید در سطح ".well-known" مشخص شود.

پشتیبانی از چندین configURL اختیاری است و پیاده سازی های موجود FedCM می توانند ثابت بمانند.

برچسب های حساب سفارشی

مثال

با چنین تنظیماتی، فایل شناخته شده شامل accounts_endpoint و login_url است تا چندین configURL را مجاز کند.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

توجه:

برچسب ها رشته هستند. اگر آرایه labels یا فیلد include چیزی باشد که رشته نیست، نادیده گرفته می‌شود.
اگر هیچ برچسبی در configURL مشخص نشده باشد، همه حساب ها در انتخابگر حساب FedCM نمایش داده می شوند.
اگر هیچ برچسبی برای یک حساب مشخص نشده باشد، تنها در صورتی در انتخابگر حساب نمایش داده می شود که configURL نیز برچسبی را مشخص نکرده باشد.
اگر هیچ حسابی با برچسب درخواستی در جریان ویجت مطابقت نداشته باشد (شبیه به Domain Hint API)، گفتگوی FedCM یک اعلان ورود را نشان می دهد که به کاربر اجازه می دهد به یک حساب IdP وارد شود. برای جریان دکمه، پنجره بازشوی ورود مستقیماً باز می شود.

آزمایش اولیه: FedCM به عنوان یک سیگنال اعتماد برای Storage Access API

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

در آزمایش مبدا شرکت کنید

برای امتحان نسخه آزمایشی اولیه بسته نرم افزاری FedCM Continuation ، دو نشانه آزمایشی مبدا ایجاد کنید:

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

اگر علاقه مند به فعال کردن Continuation API به همراه جریان دکمه هستید، آزمایش اولیه API Button Mode را نیز فعال کنید:

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

برای امتحان FedCM به عنوان یک سیگنال اعتماد برای آزمایش اولیه Storage Access API :

برای آزمایش اولیه ثبت نام کنید. توکن را در مبدا IdP جاسازی کنید .

یک آزمایش اولیه شخص ثالث برای RP ثبت کنید

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

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

TOKEN_GOES_HERE با توکن خود جایگزین کنید.

Eiji Kitamura

آزمایش اولیه: بسته نرم افزاری API ادامه FedCM

بسته نرم افزاری API Continuation FedCM از چندین افزونه FedCM تشکیل شده است:

Continuation API
API پارامترها
Fields API
چندین configURL
برچسب های حساب سفارشی

Continuation API

کاربر در حال ورود به RP است و سپس از طریق حالت دکمه مجوز می دهد.

می‌توانید نسخه آزمایشی API را در Glitch بررسی کنید.

به طور معمول، نقطه پایانی ادعای ID یک رمز مورد نیاز برای احراز هویت را برمی‌گرداند.

{
  "token": "***********"
}

با این حال ، با API ادامه ، نقطه پایانی ادعای شناسه می تواند یک ویژگی continue_on که شامل یک مسیر مطلق یا یک مسیر نسبی به نقطه پایانی ادعای شناسه است ، برگرداند.

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

به محض اینکه مرورگر پاسخ continue_on را دریافت کرد ، یک پنجره پنجره جدید باز می شود و کاربر را به مسیر مشخص شده منتقل می کند.

پس از تعامل کاربر با صفحه ، به عنوان مثال با اعطای مجوز بیشتر برای به اشتراک گذاشتن اطلاعات اضافی با RP ، صفحه IDP می تواند با IdentityProvider.resolve() تماس بگیرد تا navigator.credentials.get() تماس بگیرید و یک نشانه را به عنوان یک استدلال برگردانید.

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

مرورگر سپس به خودی خود پنجره را می بندد و نشانه را به تماس گیرنده API باز می گرداند.

اگر کاربر درخواست را رد کند ، می توانید با تماس با IdentityProvider.close() پنجره را ببندید.

IdentityProvider.close();

اگر به دلایلی کاربر حساب خود را در پنجره تغییر داده است (به عنوان مثال IDP یک عملکرد "کاربر سوئیچ" یا در موارد هیئت ارائه می دهد) ، تماس حل و فصل یک آرگومان دوم اختیاری را می دهد که اجازه می دهد چیزی مانند:

IdentityProvider.resolve(token, {accountId: '1234');

پارامترهای API

پارامترهای API به RP اجازه می دهد تا پارامترهای اضافی را به نقطه پایانی ادعای شناسه ارائه دهد. با استفاده از پارامترهای API ، RPS می تواند پارامترهای اضافی را به IDP منتقل کند تا مجوز منابع فراتر از ورود به سیستم اساسی را درخواست کند. کاربر این مجوزها را از طریق یک جریان UX تحت کنترل IDP که از طریق API ادامه کار راه اندازی می شود ، مجاز می کند.

برای استفاده از API ، پارامترها را به عنوان یک شیء در تماس navigator.credentials.get() به ویژگی params اضافه کنید.

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

نام ویژگی ها در شیء params با param_ پیش بینی شده است. در مثال بالا ، ویژگی Params شامل IDP_SPECIFIC_PARAM به عنوان '1' ، foo به عنوان 'BAR' و ETC به عنوان 'MOAR' و scope به عنوان 'calendar.readonly photos.write' است. این به صورت param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write در بدنه http درخواست ترجمه می شود:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

مجوزها را به صورت پویا دریافت کنید

به طور کلی ، برای کاربران ، درخواست مجوز در صورت نیاز ، به جای اینکه توسعه دهنده احساس کند که ساده ترین اجرای آنها است ، بسیار مفید است. به عنوان مثال ، درخواست اجازه دسترسی به دوربین هنگامی که کاربر قصد دارد عکس بگیرد ، ترجیح می دهد به محض فرود کاربر در وب سایت مجوز درخواست کند. همین عمل در مورد منابع سرور نیز صدق می کند. مجوزها را فقط در صورت نیاز به کاربر درخواست کنید. این "مجوز پویا" نامیده می شود.

برای درخواست مجوز به صورت پویا با FEDCM ، IDP می تواند:

تماس با navigator.credentials.get() با پارامترهای لازم که IDP می تواند درک کند ، مانند scope .
انتهای ادعای ID تأیید می کند که کاربر قبلاً وارد سیستم شده است و با URL continue_on پاسخ می دهد.
مرورگر با صفحه اجازه IDP یک پنجره بازشو را باز می کند و درخواست مجوز دیگری را می دهد که مطابق با دامنه های درخواست شده باشد.
هنگامی که از طریق IdentityProvider.resolve() توسط IDP مجاز است ، پنجره بسته شده است و navigator.credentials.get() تماس یک نشانه مربوط یا یک کد مجوز را دریافت می کند تا RP بتواند آن را با یک نشانه دسترسی مناسب مبادله کند.

API زمینه

API Fields به RP اجازه می دهد تا ویژگی های حساب را از IDP درخواست کند تا مرورگر بتواند UI افشای مناسب را در گفتگوی FEDCM ارائه دهد. این مسئولیت IDP است که زمینه های درخواست شده را در نشانه برگشتی قرار دهید. این درخواست "نمایه اصلی" را در OpenID Connect در مقابل "Scopes" در OAUTH در نظر بگیرید.

برای استفاده از زمینه های API ، پارامترهایی را به عنوان آرایه در تماس navigator.credentials.get() به ویژگی fields اضافه کنید. این زمینه ها می توانند در حال حاضر شامل 'name' ، 'email' و 'picture' باشند ، اما می توانند در آینده شامل مقادیر بیشتری شوند.

درخواست با fields به این شکل است:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

درخواست HTTP به نقطه پایانی ادعای شناسه شامل پارامتر fields مشخص شده RP است ، با پارامتر disclosure_text_shown true شده است اگر این یک کاربر برگشتی نباشد ، و زمینه هایی که مرورگر در یک پارامتر disclosure_shown_for برای کاربر افشا کرده است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

اگر RP نیاز به دسترسی به هرگونه داده اضافی از IDP ، مانند دسترسی به یک تقویم داشته باشد ، همانطور که در بالا ذکر شد ، باید با یک پارامتر سفارشی اداره شود. IDP یک URL continue_on را برای درخواست مجوز برمی گرداند.

اگر fields یک آرایه خالی باشد ، درخواست به این شکل خواهد بود:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

اگر fields یک آرایه خالی باشد ، نماینده کاربر UI افشای اطلاعات را رد می کند.

پیام افشای اطلاعات در حالت ویجت نمایش داده نمی شود. در جریان دکمه ، UI افشاگری کاملاً پرش می شود.

این مورد حتی اگر پاسخ از نقطه پایانی حساب ها حاوی شناسه مشتری نباشد که با RP در approved_clients مطابقت داشته باشد.

در این حالت ، disclosure_text_shown ارسال شده به نقطه پایانی ادعای شناسه در بدنه HTTP نادرست است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

چندین پیکربندی

پیکربندی های متعدد به IDP ها اجازه می دهند تا با مشخص کردن accounts_endpoint و login_url در پرونده مشهور همانند پرونده های پیکربندی ، چندین پرونده پیکربندی را برای یک IDP قرار دهند.

اگر accounts_endpoint و login_url به پرونده مشهور اضافه شوند ، provider_urls نادیده گرفته می شوند تا IDP بتواند از چندین پرونده پیکربندی پشتیبانی کند. اگر اینگونه نباشند ، provider_urls همچنان به کار می روند تا سازگار با عقب باشد.

پرونده مشهور که از چندین پیکربندی پشتیبانی می کند می تواند به این شکل باشد:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

این به ما امکان می دهد:

سازگاری به عقب و جلو را با پرونده های مشهور موجود و نسخه قبلی مرورگرهایی که قبلاً در طبیعت مستقر شده اند ، حفظ کنید.
تعداد دلخواه فایلهای پیکربندی را داشته باشید - تا زمانی که همه به همان accounts_endpoint و login_url اشاره کنند.
هیچ فرصتی برای اضافه کردن آنتروپی به درخواست واکشی اعتبار داده شده به accounts_endpoint ندارید ، زیرا باید در سطح ".well شناخته شده" مشخص شود.

پشتیبانی از چندین پیکربندی اختیاری است و اجرای FEDCM موجود می تواند یکسان باشد.

برچسب های حساب سفارشی

برچسب های حساب سفارشی به IDP های FEDCM اجازه می دهند تا حساب ها را حاشیه نویسی کنند تا RPS بتواند با مشخص کردن برچسب در یک پرونده پیکربندی ، آنها را فیلتر کند. فیلتر مشابه با استفاده از API Domain Hint و API ورود به سیستم با مشخص کردن آنها در navigator.credentials.get() تماس گرفته شده است ، اما برچسب های حساب سفارشی می توانند با مشخص کردن فایل پیکربندی ، کاربران را فیلتر کنند ، که به ویژه در هنگام استفاده از چندین پیکربندی مفید است. برچسب های حساب سفارشی نیز از نظر ارائه شده از سرور IDP ، بر خلاف RP ، مانند نشانه های ورود یا دامنه ، متفاوت هستند.

مثال

یک IDP به ترتیب از دو پیکربندی برای مصرف کننده و شرکت پشتیبانی می کند. فایل پیکربندی Consumer دارای برچسب 'consumer' است و پرونده پیکربندی سازمانی دارای برچسب 'enterprise' است.

با چنین تنظیماتی ، پرونده مشهور شامل accounts_endpoint و login_url است تا امکان پیکربندی های متعدد فراهم شود.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

هنگامی که accounts_endpoint در پرونده مشهور ارائه می شود ، provider_urls نادیده گرفته می شوند. RP می تواند مستقیماً در پرونده های پیکربندی مربوطه در تماس navigator.credentials.get() اشاره کند.

پرونده پیکربندی مصرف کننده در https://idp.example/fedcm.json است که شامل خاصیت accounts است که با استفاده از این include 'consumer' را مشخص می کند.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

پرونده پیکربندی سازمانی در https://idp.example/enterprise/fedcm.json است ، که شامل ویژگی accounts است که با استفاده از include 'enterprise' را مشخص می کند.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

نقطه پایانی حساب های IDP مشترک (در این مثال https://idp.example/accounts ) لیستی از حساب ها را باز می گرداند که شامل یک ویژگی برچسب با labels اختصاص یافته در یک آرایه برای هر حساب است. در زیر پاسخ مثالی برای کاربر است که دو حساب دارد. یکی برای مصرف کننده و دیگری برای شرکت:

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

هنگامی که یک RP می خواهد به کاربران 'enterprise' اجازه ورود به سیستم را بدهد ، می توانند 'enterprise' Configurl 'https://idp.example/enterprise/fedcm.json' را در navigator.credentials.get() تماس بگیرند:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

در نتیجه ، فقط شناسه حساب '4567' برای ورود کاربر در دسترس است. شناسه حساب '123' به ساکت توسط مرورگر پنهان شده است تا کاربر با حسابی که توسط IDP در این سایت پشتیبانی نمی شود ، ارائه نشود.

توجه:

برچسب ها رشته هستند. اگر آرایه labels یا include قسمت شامل چیزی باشد که رشته ای نباشد ، نادیده گرفته می شود.
اگر هیچ برچسب در پیکربندی مشخص نشده باشد ، تمام حساب ها در انتخاب حساب FEDCM نمایش داده می شوند.
اگر هیچ برچسب برای یک حساب کاربری مشخص نشده باشد ، در صورتی که پیکربندی نیز برچسب را مشخص نمی کند ، فقط در انتخاب حساب نمایش داده می شود.
اگر هیچ حساب مطابق با برچسب درخواست شده در جریان ویجت (مشابه با API Domain Hint) باشد ، گفتگوی FEDCM سریع ورود به سیستم را نشان می دهد ، که به کاربر اجازه می دهد تا وارد یک حساب IDP شود. برای جریان دکمه ، پنجره ورود به سیستم مستقیماً باز می شود.

آزمایش مبدا: FEDCM به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره سازی

Chrome 126 آزمایش اصلی FEDCM را به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره سازی آغاز می کند. با این تغییر ، کمک هزینه مجوز قبلی از طریق FEDCM به یک دلیل معتبر برای تأیید خودکار درخواست دسترسی به ذخیره سازی توسط API های دسترسی به ذخیره سازی تبدیل می شود.

این زمانی مفید است که یک Iframe تعبیه شده بخواهد به منابع شخصی دسترسی پیدا کند: به عنوان مثال ، اگر IDP.example در RP.example تعبیه شده باشد و نیاز به نشان دادن یک منبع شخصی دارد. اگر مرورگر دسترسی به کوکی های شخص ثالث را محدود کند ، حتی اگر کاربر با استفاده از idp.example با FEDCM به RP.Example وارد شود ، IDP.EXAMPLE IFRAME قادر به درخواست منابع شخصی نیست زیرا درخواست ها شامل کوکی های شخص ثالث نمی شوند.

برای دستیابی به این هدف ، idp.example باید از طریق iframe تعبیه شده در وب سایت ، مجوز دسترسی به ذخیره سازی را دریافت کند ، و این تنها از طریق سریع مجوز قابل دستیابی است.

با استفاده از FEDCM به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره سازی ، چک های مجوز API ذخیره سازی نه تنها کمک هزینه مجوز را که توسط یک سریع دسترسی به ذخیره سازی داده می شود ، می پذیرند ، بلکه همچنین کمک هزینه مجوز داده شده توسط یک فدراسیون FEDCM.

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

پس از ورود کاربر با FEDCM ، تا زمانی که احراز هویت FEDCM فعال باشد ، مجوز به صورت خودکار اعطا می شود. این بدان معناست که پس از قطع کاربر ، درخواست مجوز سریع نشان می دهد.

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

می توانید بسته نرم افزاری API ادامه FEDCM را با روشن کردن یک کروم پرچم Chrome chrome://flags#fedcm-authz در Chrome 126 یا بالاتر امتحان کنید. همچنین می توانید FEDCM را به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره سازی محلی با روشن کردن #fedcm-with-storage-access-api در Chrome 126 یا بعد از آن امتحان کنید.

این ویژگی ها همچنین به عنوان آزمایشات Origin در دسترس هستند. آزمایشات مبدا به شما امکان می دهد ویژگی های جدید را امتحان کرده و در مورد قابلیت استفاده ، عملی و اثربخشی آنها بازخورد دهید. برای اطلاعات بیشتر ، شروع به کار با محاکمه Origin را بررسی کنید.

برای امتحان کردن آزمایش مبداء بسته نرم افزاری API ادامه FEDCM ، دو نشانه آزمایشی مبدا ایجاد کنید:

ثبت نام در دادگاه. نشانه را به منشأ IDP تعبیه کرد .
ثبت نام در محاکمه Origin را با کادر انتخاب تطبیق شخص ثالث بررسی کنید. دستورالعمل ها را در ثبت نام یک محاکمه مبدا شخص ثالث برای RP دنبال کنید تا نشانه RP را تعبیه کند.

اگر شما علاقه مند به فعال کردن API ادامه به همراه جریان دکمه هستید ، آزمایش Origin Origin Mode Button را نیز فعال کنید:

ثبت نام در محاکمه مبدا به عنوان شخص ثالث. دستورالعمل ها را در ثبت نام یک محاکمه مبدا شخص ثالث برای RP دنبال کنید تا نشانه RP را تعبیه کند.

برای امتحان کردن FEDCM به عنوان یک سیگنال اعتماد برای آزمایش API API Origin :

ثبت نام در دادگاه مبدا. نشانه را به منشأ IDP تعبیه کرد .

آزمایش منشأ بسته نرم افزاری API و FEDCM به عنوان یک سیگنال اعتماد برای آزمایش API Origin Access Access از Chrome 126 در دسترس است.

ثبت نام منشأ شخص ثالث را برای RP ثبت کنید

به صفحه ثبت نام محاکمه مبدا بروید.
روی دکمه Register کلیک کنید و فرم را برای درخواست یک نشانه پر کنید.
منشأ IDP را به عنوان Origin وارد کنید.
تطبیق شخص ثالث را برای تزریق نشانه با JavaScript در سایر ریشه ها بررسی کنید.
روی ارسال کلیک کنید.
نشانه صادر شده را در یک وب سایت شخص ثالث قرار داده است.

برای تعبیه نشانه در وب سایت شخص ثالث ، کد زیر را به کتابخانه جاوا اسکریپت IDP یا SDK که از منشأ IDP سرو می شود ، اضافه کنید.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

TOKEN_GOES_HERE با نشانه خود جایگزین کنید.

Eiji Kitamura

از Chrome 126 ، توسعه دهندگان می توانند یک آزمایش اصلی را برای مجموعه ای از ویژگی های API مدیریت اعتبار فدرال دسک تاپ (FEDCM) شروع کنند که برخی از موارد استفاده مجوز را امکان پذیر می کند. بسته نرم افزاری شامل API ادامه و API پارامترهای API است که یک تجربه مانند مجوز OAUTH را شامل می شود که شامل یک گفتگوی مجوز ارائه دهنده هویت (IDP) است. این بسته نرم افزاری همچنین شامل تغییرات دیگری مانند API فیلدها ، چندین پیکربندی و برچسب های حساب سفارشی است. از Chrome 126 ، ما همچنین یک آزمایش اصلی را برای API دسترسی به ذخیره سازی (SAA) معرفی می کنیم که اگر کاربر در گذشته با موفقیت در استفاده از FEDCM وارد شده باشد ، درخواست های SAA را درخواست می کند.

محاکمه مبدا: بسته نرم افزاری API ادامه FEDCM

بسته API ادامه FEDCM شامل چندین پسوند FEDCM است:

API ادامه
پارامترهای API
API زمینه
چندین پیکربندی
برچسب های حساب سفارشی

API ادامه

کاربر در حال ورود به RP است و سپس از طریق حالت دکمه مجاز است.

می توانید نسخه ی نمایشی API را در Glitch بررسی کنید.

API ادامه ، اجازه می دهد تا نقطه پایانی ادعای IDP به صورت اختیاری URL را که FEDCM ارائه می دهد بازگرداند تا به کاربر اجازه دهد جریان ورود به سیستم چند مرحله ای را ادامه دهد. این امر به IDP اجازه می دهد تا از کاربر بخواهد مجوزهای متکی به طرف (RP) را فراتر از آنچه در FEDCM UI موجود امکان پذیر است ، مانند دسترسی به منابع سمت سرور کاربر ، اعطا کند.

به طور معمول ، نقطه پایانی ادعای شناسه نشانه مورد نیاز برای تأیید اعتبار را برمی گرداند.

{
  "token": "***********"
}

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

مرورگر سپس به خودی خود پنجره را می بندد و نشانه را به تماس گیرنده API باز می گرداند.

اگر کاربر درخواست را رد کند ، می توانید با تماس با IdentityProvider.close() پنجره را ببندید.

IdentityProvider.close();

IdentityProvider.resolve(token, {accountId: '1234');

پارامترهای API

برای استفاده از API ، پارامترها را به عنوان یک شیء در تماس navigator.credentials.get() به ویژگی params اضافه کنید.

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

مجوزها را به صورت پویا دریافت کنید

برای درخواست مجوز به صورت پویا با FEDCM ، IDP می تواند:

تماس با navigator.credentials.get() با پارامترهای لازم که IDP می تواند درک کند ، مانند scope .
انتهای ادعای ID تأیید می کند که کاربر قبلاً وارد سیستم شده است و با URL continue_on پاسخ می دهد.
مرورگر با صفحه اجازه IDP یک پنجره بازشو را باز می کند و درخواست مجوز دیگری را می دهد که مطابق با دامنه های درخواست شده باشد.
هنگامی که از طریق IdentityProvider.resolve() توسط IDP مجاز است ، پنجره بسته شده است و navigator.credentials.get() تماس یک نشانه مربوط یا یک کد مجوز را دریافت می کند تا RP بتواند آن را با یک نشانه دسترسی مناسب مبادله کند.

API زمینه

درخواست با fields به این شکل است:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

اگر fields یک آرایه خالی باشد ، درخواست به این شکل خواهد بود:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

اگر fields یک آرایه خالی باشد ، نماینده کاربر UI افشای اطلاعات را رد می کند.

این مورد حتی اگر پاسخ از نقطه پایانی حساب ها حاوی شناسه مشتری نباشد که با RP در approved_clients مطابقت داشته باشد.

در این حالت ، disclosure_text_shown ارسال شده به نقطه پایانی ادعای شناسه در بدنه HTTP نادرست است:

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

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

چندین پیکربندی

پرونده مشهور که از چندین پیکربندی پشتیبانی می کند می تواند به این شکل باشد:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

این به ما امکان می دهد:

سازگاری به عقب و جلو را با پرونده های مشهور موجود و نسخه قبلی مرورگرهایی که قبلاً در طبیعت مستقر شده اند ، حفظ کنید.
تعداد دلخواه فایلهای پیکربندی را داشته باشید - تا زمانی که همه به همان accounts_endpoint و login_url اشاره کنند.
هیچ فرصتی برای اضافه کردن آنتروپی به درخواست واکشی اعتبار داده شده به accounts_endpoint ندارید ، زیرا باید در سطح ".well شناخته شده" مشخص شود.

پشتیبانی از چندین پیکربندی اختیاری است و اجرای FEDCM موجود می تواند یکسان باشد.

برچسب های حساب سفارشی

مثال

با چنین تنظیماتی ، پرونده مشهور شامل accounts_endpoint و login_url است تا امکان پیکربندی های متعدد فراهم شود.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

پرونده پیکربندی سازمانی در https://idp.example/enterprise/fedcm.json است ، که شامل ویژگی accounts است که با استفاده include 'enterprise' را مشخص می کند.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

توجه:

برچسب ها رشته هستند. اگر آرایه labels یا include قسمت شامل چیزی باشد که رشته ای نباشد ، نادیده گرفته می شود.
اگر هیچ برچسب در پیکربندی مشخص نشده باشد ، تمام حساب ها در انتخاب حساب FEDCM نمایش داده می شوند.
اگر هیچ برچسب برای یک حساب کاربری مشخص نشده باشد ، در صورتی که پیکربندی نیز برچسب را مشخص نمی کند ، فقط در انتخاب حساب نمایش داده می شود.
اگر هیچ حساب مطابق با برچسب درخواست شده در جریان ویجت (مشابه با API Domain Hint) باشد ، گفتگوی FEDCM سریع ورود به سیستم را نشان می دهد ، که به کاربر اجازه می دهد تا وارد یک حساب IDP شود. برای جریان دکمه ، پنجره ورود به سیستم مستقیماً باز می شود.

آزمایش مبدا: FEDCM به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره سازی

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

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

برای امتحان کردن آزمایش مبداء بسته نرم افزاری API ادامه FEDCM ، دو نشانه آزمایشی مبدا ایجاد کنید:

ثبت نام در دادگاه. نشانه را به منشأ IDP تعبیه کرد .
ثبت نام در محاکمه Origin را با کادر انتخاب تطبیق شخص ثالث بررسی کنید. دستورالعمل ها را در ثبت نام یک محاکمه مبدا شخص ثالث برای RP دنبال کنید تا نشانه RP را تعبیه کند.

اگر شما علاقه مند به فعال کردن API ادامه به همراه جریان دکمه هستید ، آزمایش Origin Origin Mode Button را نیز فعال کنید:

ثبت نام در محاکمه مبدا به عنوان شخص ثالث. دستورالعمل ها را در ثبت نام یک محاکمه مبدا شخص ثالث برای RP دنبال کنید تا نشانه RP را تعبیه کند.

برای امتحان کردن FEDCM به عنوان یک سیگنال اعتماد برای آزمایش API API Origin :

ثبت نام در دادگاه مبدا. نشانه را به منشأ IDP تعبیه کرد .

آزمایش منشأ بسته نرم افزاری API و FEDCM به عنوان یک سیگنال اعتماد برای آزمایش API Origin Access Access از Chrome 126 در دسترس است.

ثبت نام منشأ شخص ثالث را برای RP ثبت کنید

به صفحه ثبت نام محاکمه مبدا بروید.
روی دکمه Register کلیک کنید و فرم را برای درخواست یک نشانه پر کنید.
منشأ IDP را به عنوان Origin وارد کنید.
تطبیق شخص ثالث را برای تزریق نشانه با JavaScript در سایر ریشه ها بررسی کنید.
روی ارسال کلیک کنید.
نشانه صادر شده را در یک وب سایت شخص ثالث قرار داده است.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

TOKEN_GOES_HERE با نشانه خود جایگزین کنید.