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

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

Eiji Kitamura

ตั้งแต่ Chrome 126 เป็นต้นไป นักพัฒนาซอฟต์แวร์จะเริ่มเรียกใช้ช่วงทดลองใช้จากต้นทางสำหรับแพ็กเกจ ฟีเจอร์ Federated Credential Management API (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 สำหรับโหมดวิดเจ็ต mediation: optional ที่ API ตรวจสอบ การเปิดใช้งานผู้ใช้ชั่วคราวหากมีการตรวจสอบสิทธิ์อีกครั้งโดยอัตโนมัติ หรือไม่เช่นนั้น ไม่มีหน้าต่างป๊อปอัปเปิด และคำสัญญาถูกปฏิเสธ

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

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

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

มี FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับการเข้าถึงพื้นที่เก็บข้อมูล 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

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

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