หน้านี้ได้รับการแปลโดย Cloud Translation API

ข้อมูลอัปเดตจาก FedCM: ช่วงทดลองใช้จากต้นทางสำหรับแพ็กเกจ Continuation API และการให้สิทธิ์ API การเข้าถึงพื้นที่เก็บข้อมูลโดยอัตโนมัติ

Eiji Kitamura

ตั้งแต่ Chrome 126 เป็นต้นไป นักพัฒนาซอฟต์แวร์จะเริ่มเรียกใช้ช่วงทดลองใช้จากต้นทางสำหรับแพ็กเกจฟีเจอร์ Federated Credential Management API (FedCM) ในเดสก์ท็อปที่เปิดใช้กรณีการใช้งานการให้สิทธิ์ได้ แพ็กเกจดังกล่าวประกอบด้วย Continuation API และ Parameters API ซึ่งจะเปิดใช้ประสบการณ์ที่เหมือนกับขั้นตอนการให้สิทธิ์ OAuth ซึ่งเกี่ยวข้องกับกล่องโต้ตอบสิทธิ์ของผู้ให้บริการข้อมูลประจำตัว (IdP) แพ็กเกจนี้ยังรวมการเปลี่ยนแปลงอื่นๆ เช่น Fields API, configURL หลายรายการ และป้ายกำกับบัญชีที่กำหนดเอง จาก Chrome 126 เราจะเปิดตัวช่วงทดลองใช้จากต้นทางสำหรับ Storage Access API (SAA) ซึ่งจะส่งคำขอ SAA โดยอัตโนมัติหากผู้ใช้เคยเข้าสู่ระบบด้วย FedCM สำเร็จ

ช่วงทดลองใช้จากต้นทาง: แพ็กเกจ FedCM Continuation API

แพ็กเกจ FedCM Continuation API ประกอบด้วยส่วนขยาย FedCM หลายรายการ ได้แก่

API ความต่อเนื่อง
API พารามิเตอร์
API ฟิลด์
configURL หลายรายการ
ป้ายกำกับบัญชีที่กำหนดเอง

API ความต่อเนื่อง

ผู้ใช้กำลังลงชื่อเข้าใช้ RP แล้วให้สิทธิ์ผ่านโหมดปุ่ม

คุณสามารถดูการสาธิตของ API ใน Glitch

Continuation API จะอนุญาตให้ปลายทางการยืนยันรหัสของ IdP แสดง URL ที่ FedCM แสดงผลเพื่ออนุญาตให้ผู้ใช้ดำเนินการตามขั้นตอนการลงชื่อเข้าใช้แบบหลายขั้นตอนต่อได้ วิธีนี้ช่วยให้ IdP สามารถขอผู้ใช้ให้สิทธิ์ฝ่ายที่มีอำนาจ (RP) นอกเหนือจากสิ่งที่ทำได้ใน UI ของ FedCM ที่มีอยู่ เช่น การเข้าถึงทรัพยากรฝั่งเซิร์ฟเวอร์ของผู้ใช้

โดยปกติแล้ว ปลายทางการยืนยันรหัสจะแสดงโทเค็นที่จำเป็นสำหรับการตรวจสอบสิทธิ์

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

แต่เมื่อใช้ Continuation 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();

หมายเหตุ: Continuation API จะได้รับอนุญาตเฉพาะเมื่อมีการโต้ตอบของผู้ใช้ (การคลิกอย่างชัดแจ้ง) ดังนั้น ผู้ใช้จะต้องเลือกบัญชีในโหมดวิดเจ็ต (ที่มี mediation: 'required') หรือในโหมดปุ่ม (ซึ่งจะต้องเปิดใช้งานผู้ใช้เสมอ) แต่ไม่อนุญาตให้ใช้ป๊อปอัปสำหรับ mediation: silent API จะตรวจสอบการเปิดใช้งานผู้ใช้แบบชั่วคราวสำหรับโหมดวิดเจ็ต mediation: optional หากมีการเรียกใช้การตรวจสอบสิทธิ์อีกครั้งโดยอัตโนมัติ ไม่เช่นนั้น จะไม่มีการเปิดหน้าต่างป๊อปอัป และคำสัญญาจะถูกปฏิเสธ

หากผู้ใช้เปลี่ยนบัญชีในป๊อปอัปด้วยเหตุผลบางอย่าง (เช่น IdP มีฟังก์ชัน "เปลี่ยนผู้ใช้" หรือในกรณีการมอบสิทธิ์) การเรียกใช้การแก้ไขจะใช้อาร์กิวเมนต์ที่ 2 ที่ระบุหรือไม่ก็ได้ โดยให้มีเงื่อนไขดังนี้

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

API พารามิเตอร์

Parameters API ช่วยให้ RP ระบุพารามิเตอร์เพิ่มเติมไปยังปลายทางการยืนยันรหัสได้ เมื่อใช้ 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_ นำหน้า ในตัวอย่างด้านบน พร็อพเพอร์ตี้ของพารามิเตอร์มี 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 ผู้ให้บริการข้อมูลประจำตัวจะทำสิ่งต่อไปนี้ได้

เรียก navigator.credentials.get() พร้อมพารามิเตอร์ที่จำเป็นซึ่ง IdP เข้าใจได้ เช่น scope
ปลายทางการยืนยันรหัสจะยืนยันว่าผู้ใช้ได้ลงชื่อเข้าใช้แล้ว และตอบกลับด้วย URL ของ continue_on
เบราว์เซอร์จะเปิดหน้าต่างป๊อปอัปที่มีหน้าสิทธิ์ของ IdP ซึ่งขอสิทธิ์เพิ่มเติมที่ตรงกับขอบเขตที่ขอ
เมื่อ IdP ให้สิทธิ์ผ่าน IdentityProvider.resolve() แล้ว หน้าต่างจะปิดลงและการเรียกใช้ navigator.credentials.get() เดิมของ RP จะได้รับโทเค็นที่เกี่ยวข้องหรือรหัสการให้สิทธิ์เพื่อให้ RP แลกเปลี่ยนโทเค็นกับโทเค็นเพื่อการเข้าถึงที่เหมาะสมได้

API ช่อง

Fields API ช่วยให้ RP ประกาศแอตทริบิวต์ของบัญชีเพื่อขอจาก IdP เพื่อให้เบราว์เซอร์แสดงผล UI การเปิดเผยข้อมูลที่เหมาะสมในกล่องโต้ตอบ FedCM ได้ IdP มีหน้าที่รวมช่องที่จำเป็นต้องขอในโทเค็นที่แสดงผล พิจารณาถึงการขอ "โปรไฟล์พื้นฐาน" ใน OpenID Connect เทียบกับ "ขอบเขต" ใน OAuth

หากต้องการใช้ Fields API ให้เพิ่มพารามิเตอร์ลงในพร็อพเพอร์ตี้ fields เป็นอาร์เรย์ในการเรียกใช้ navigator.credentials.get() ปัจจุบันช่องนี้อาจมี '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 เป็นอาร์เรย์ว่างเปล่า User Agent จะข้าม 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

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 ที่มีอยู่จะยังคงเหมือนเดิม

ป้ายกำกับบัญชีที่กำหนดเอง

ป้ายกำกับบัญชีที่กำหนดเองช่วยให้ FedCM IdP ใส่คำอธิบายประกอบบัญชีเพื่อให้ RP กรองบัญชีเหล่านั้นได้โดยการระบุป้ายกำกับในไฟล์การกำหนดค่า ผู้ใช้สามารถกรองที่คล้ายกันได้โดยใช้ Domain Hint API และ Login Hint API โดยการระบุในการเรียกใช้ navigator.credentials.get() แต่ป้ายกำกับบัญชีที่กำหนดเองสามารถกรองผู้ใช้ได้โดยการระบุไฟล์การกำหนดค่า ซึ่งมีประโยชน์มากเมื่อใช้ configURLs หลายรายการ นอกจากนี้ ป้ายกำกับบัญชีที่กำหนดเองยังมีความแตกต่างจากมาจากเซิร์ฟเวอร์ IdP ซึ่งต่างจาก RP เช่น การเข้าสู่ระบบหรือการแนะนำโดเมน

ตัวอย่าง

IdP รองรับ configURL 2 รายการสำหรับผู้ใช้ทั่วไปและ Enterprise ตามลำดับ ไฟล์การกำหนดค่าผู้บริโภคมีป้ายกำกับ '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 ที่ระบุ 'enterprise' โดยใช้ include

{
  "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 ที่กำหนดในอาร์เรย์ของแต่ละบัญชี ต่อไปนี้เป็นตัวอย่างคำตอบสำหรับผู้ใช้ที่มี 2 บัญชี ส่วนหนึ่งมีไว้สำหรับผู้บริโภค ส่วนอีกส่วนหนึ่งมีไว้สำหรับองค์กร

{
 "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 มีข้อมูลที่ไม่ใช่สตริง ระบบจะละเว้นข้อมูลดังกล่าว
หากไม่ได้ระบุป้ายกำกับใน configURL บัญชีทั้งหมดจะแสดงในตัวเลือกบัญชี FedCM
หากไม่มีการระบุป้ายกำกับสำหรับบัญชี ป้ายกำกับจะแสดงในตัวเลือกบัญชีก็ต่อเมื่อ configURL ไม่ได้ระบุป้ายกำกับด้วย
หากไม่มีบัญชีที่ตรงกับป้ายกำกับที่ขอในโฟลว์วิดเจ็ต (คล้ายกับ Domain Hint API) กล่องโต้ตอบ FedCM จะแสดงพรอมต์การเข้าสู่ระบบซึ่งอนุญาตให้ผู้ใช้เข้าสู่ระบบบัญชี IdP สําหรับโฟลว์ของปุ่ม หน้าต่างป๊อปอัปการเข้าสู่ระบบจะเปิดขึ้นโดยตรง

ช่วงทดลองใช้จากต้นทาง: FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API

Chrome 126 กำลังเริ่มการทดลองใช้ FedCM จากต้นทางเป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API การเปลี่ยนแปลงนี้ทำให้การให้สิทธิ์ก่อนหน้านี้ผ่าน FedCM กลายเป็นเหตุผลอันสมควรที่จะอนุมัติคำขอเข้าถึงพื้นที่เก็บข้อมูลจาก API การเข้าถึงพื้นที่เก็บข้อมูลโดยอัตโนมัติ

วิธีนี้มีประโยชน์เมื่อ iframe ที่ฝังไว้ต้องการเข้าถึงทรัพยากรที่ปรับให้เหมาะกับแต่ละบุคคล เช่น หาก idp.example ฝังอยู่ใน rp.example และจำเป็นต้องแสดงทรัพยากรที่ปรับเปลี่ยนในแบบของคุณ หากเบราว์เซอร์จำกัดการเข้าถึงคุกกี้ของบุคคลที่สาม แม้ว่าผู้ใช้จะลงชื่อเข้าใช้ rp.example โดยใช้ idp.example กับ FedCM ก็ตาม iframe idp.example ที่ฝังจะไม่สามารถขอทรัพยากรที่ปรับเปลี่ยนในแบบของคุณได้เนื่องจากคำขอไม่มีคุกกี้ของบุคคลที่สาม

ดังนั้น idp.example จะต้องได้รับสิทธิ์การเข้าถึงพื้นที่เก็บข้อมูลผ่าน iframe ที่ฝังอยู่ในเว็บไซต์ ซึ่งสามารถได้รับผ่านข้อความแจ้งสิทธิ์เท่านั้น

เมื่อใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API การตรวจสอบสิทธิ์ Storage Access 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 ยังทำงานอยู่ ซึ่งหมายความว่าเมื่อผู้ใช้ถูกตัดการเชื่อมต่อ คำขอสิทธิ์จะแสดงข้อความแจ้ง

เข้าร่วมช่วงทดลองใช้จากต้นทาง

คุณลองใช้แพ็กเกจ FedCM Continuation API ในเครื่องได้โดยเปิดธง Chrome chrome://flags#fedcm-authz ใน Chrome 126 ขึ้นไป นอกจากนี้ คุณยังลองใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API ในเครื่องได้โดยเปิด #fedcm-with-storage-access-api ใน Chrome 126 ขึ้นไป

ฟีเจอร์เหล่านี้มีให้บริการเป็นช่วงทดลองใช้จากต้นทางด้วย ช่วงทดลองใช้จากต้นทางช่วยให้คุณได้ลองใช้ฟีเจอร์ใหม่ๆ และแสดงความคิดเห็นเกี่ยวกับความสามารถในการใช้งาน การใช้งานจริง และประสิทธิภาพ ดูข้อมูลเพิ่มเติมได้ที่เริ่มต้นใช้งานช่วงทดลองใช้จากต้นทาง

หากต้องการลองทดลองใช้แพ็กเกจ FedCM Continuation API จากต้นทาง ให้สร้างโทเค็นช่วงทดลองใช้จากต้นทาง 2 รายการ ดังนี้

ลงทะเบียนทดลองใช้ ฝังโทเค็นไปยังต้นทาง IdP
ลงทะเบียนช่วงทดลองใช้จากต้นทางโดยเลือกช่องทำเครื่องหมายการจับคู่ของบุคคลที่สามไว้ ทำตามวิธีการในหัวข้อลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP เพื่อฝังโทเค็นสำหรับ RP

หากคุณสนใจที่จะเปิดใช้ Continuation API พร้อมกับโฟลว์ของปุ่ม ให้เปิดใช้งานการทดลองใช้ต้นทางของ API โหมดปุ่มด้วย ดังนี้

ลงทะเบียนช่วงทดลองใช้จากต้นทางในฐานะบุคคลที่สาม ทำตามวิธีการในลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP เพื่อฝังโทเค็นสำหรับ RP

หากต้องการลองใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับช่วงทดลองใช้ Storage Access API จากต้นทาง ให้ทำดังนี้

ลงทะเบียนช่วงทดลองใช้จากต้นทาง ฝังโทเค็นไปยังต้นทาง IdP

ช่วงทดลองใช้แพ็กเกจ Continuation API จากต้นทางและ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับช่วงทดลองใช้ Storage Access API จากต้นทางมีให้บริการใน Chrome 126

ลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP

ไปที่หน้าการลงทะเบียนช่วงทดลองใช้จากต้นทาง
คลิกปุ่มลงทะเบียนและกรอกแบบฟอร์มเพื่อขอโทเค็น
ป้อนต้นทางของ IdP เป็นต้นทางเว็บ
ตรวจสอบการจับคู่ของบุคคลที่สามเพื่อแทรกโทเค็นด้วย JavaScript ในต้นทางอื่นๆ
คลิกส่ง
ฝังโทเค็นที่ออกบนเว็บไซต์ของบุคคลที่สาม

หากต้องการฝังโทเค็นในเว็บไซต์ของบุคคลที่สาม ให้เพิ่มโค้ดต่อไปนี้ลงในไลบรารี JavaScript หรือ SDK ของ IdP ที่แสดงผลจากต้นทางของ IdP

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

แทนที่ TOKEN_GOES_HERE ด้วยโทเค็นของคุณเอง