ตั้งแต่ 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 ใน 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();
หากผู้ใช้เปลี่ยนบัญชีของตนในป๊อปอัปด้วยเหตุผลบางอย่าง (เช่น 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¶m_foo=BAR¶m_ETC=MOAR¶m_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¶m_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_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
![ข้อความเปิดเผยข้อมูลในโหมดวิดเจ็ต](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-widget.jpg?authuser=0000&hl=th)
![ข้อความเปิดเผยข้อมูลในโหมดปุ่ม](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-button.jpg?authuser=0000&hl=th)
หากต้องการใช้ 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 การเปิดเผยข้อมูลทั้งหมด](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-without-disclosure-widget.jpg?authuser=0000&hl=th)
แม้ว่าการตอบกลับจากบัญชีต่างๆ จะเป็นดังนี้ก็ตาม
ปลายทาง
ไม่มีรหัสไคลเอ็นต์ที่ตรงกับ 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 ไม่รองรับในเว็บไซต์นี้
ช่วงทดลองใช้จากต้นทาง: 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
ด้วยโทเค็นของคุณเอง