FedCM के अपडेट: Continuation API बंडल और Storage Access API के लिए ऑरिजिन ट्रायल की सुविधा अपने-आप अनुमति देना

Eiji Kitamura

Chrome 126 से, डेवलपर डेस्कटॉप फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट एपीआई (FedCM) की सुविधाओं के एक बंडल के लिए, ऑरिजिन ट्रायल शुरू कर सकते हैं. इससे उन्हें इस्तेमाल के कुछ मामलों में अनुमति देने की सुविधा मिलती है. बंडल में Continuation API और पैरामीटर एपीआई शामिल होता है, जो OAuth की पुष्टि करने के फ़्लो जैसा अनुभव चालू करता है. इसमें आइडेंटिटी प्रोवाइडर (आईडीपी) से मिला अनुमति वाला डायलॉग शामिल होता है. इस बंडल में फ़ील्ड एपीआई, एक से ज़्यादा कॉन्फ़िगरेशन यूआरएल, और कस्टम खाता लेबल जैसे दूसरे बदलाव भी शामिल हैं. Chrome 126 में, हम Storage Access API (SAA) के लिए ऑरिजिन ट्रायल भी शुरू कर रहे हैं. यह SAA में किए गए अनुरोधों को तब अपने-आप स्वीकार करता है, जब उपयोगकर्ता ने FedCM का इस्तेमाल करके पहले भी लॉग इन किया हो.

ऑरिजिन ट्रायल: FedCM Continuation API बंडल

FedCM Continuation API के बंडल में कई FedCM एक्सटेंशन होते हैं:

• कंटिन्युएशन एपीआई
• पैरामीटर एपीआई
• फ़ील्ड एपीआई
• एक से ज़्यादा configURL
• कस्टम खाता लेबल

कंटिन्यूएशन एपीआई

कोई उपयोगकर्ता आरपी में साइन इन करके, बटन मोड का इस्तेमाल करके अनुमति दे रहा है.

glitch पर एपीआई का डेमो देखा जा सकता है.

कंटिन्युएशन एपीआई, आईडीपी के आईडी दावे के एंडपॉइंट को वैकल्पिक तौर पर एक यूआरएल दिखाता है, जिसे FedCM रेंडर करके उपयोगकर्ता को एक से ज़्यादा चरणों में साइन इन करने की प्रोसेस जारी रखने की अनुमति देता है. इससे आईडीपी (IdP) को, उपयोगकर्ता से अनुरोध करने की अनुमति मिलती है कि वह भरोसेमंद पक्ष (आरपी) को वह अनुमतियां दे जो 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 रिस्पॉन्स मिलते ही, एक नई पॉप-अप विंडो खुलती है और उपयोगकर्ता को तय किए गए पाथ पर ले जाती है.

जब उपयोगकर्ता पेज के साथ इंटरैक्ट कर लेता है, जैसे कि आरपी के साथ अतिरिक्त जानकारी शेयर करने की अनुमति देना, तो आईडीपी पेज, ओरिजनल navigator.credentials.get() कॉल को हल करने के लिए IdentityProvider.resolve() को कॉल कर सकता है. साथ ही, आर्ग्युमेंट के तौर पर टोकन दे सकता है.

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);
});

इसके बाद ब्राउज़र, पॉप-अप को बंद कर देगा और एपीआई कॉलर को टोकन लौटा देगा.

अगर उपयोगकर्ता अनुरोध अस्वीकार कर देता है, तो IdentityProvider.close() को कॉल करके विंडो को बंद किया जा सकता है.

IdentityProvider.close();

ध्यान दें: पॉप-अप इस तरह काम करता है: noopener, noreferrer के बारे में बताया गया था (इसलिए, window.opener शून्य है). इसलिए, पैरंट विंडो (आरपी) और पॉप-अप विंडो (आईडीपी), दोनों के लिए एक-दूसरे से इंटरैक्ट करने का कोई तरीका नहीं है. बातचीत करने के लिए, एक बार किया जाने वाला IdentityProvider.resolve() कॉल होना चाहिए. इससे पॉप-अप भी बंद हो जाता है.

ध्यान दें: Continuation API सिर्फ़ तब काम करता है, जब उपयोगकर्ता से इंटरैक्शन होता हो (अश्लील क्लिक). इसलिए, उपयोगकर्ता को अपना खाता विजेट मोड (mediation: 'required' के साथ) या बटन मोड में चुनना होगा, जिसके लिए हमेशा उपयोगकर्ता को ऐक्टिवेट करना पड़ता है. हालांकि, mediation: silent के लिए पॉप-अप की अनुमति नहीं है. अगर अपने-आप दोबारा पुष्टि करने की सुविधा ट्रिगर होती है, तो mediation: optional विजेट मोड के लिए, एपीआई यह जांच करता है कि उपयोगकर्ता कुछ समय के लिए ही काम करेगा या नहीं. ऐसा न करने पर, कोई पॉप-अप विंडो नहीं खुलती है और प्रॉमिस अस्वीकार कर दिया जाता है.

अगर किसी वजह से उपयोगकर्ता ने पॉप-अप में अपना खाता बदल दिया है (उदाहरण के लिए, आईडीपी (IdP) "उपयोगकर्ता स्विच करें" फ़ंक्शन देता है या डेलिगेशन की प्रोसेस में ऐसा होता है, तो रिज़ॉल्व होने पर दूसरा आर्ग्युमेंट इस तरह की अनुमति देता है. हालांकि, ऐसा करना ज़रूरी नहीं है:

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

पैरामीटर एपीआई

पैरामीटर एपीआई की मदद से, आरपी, आईडी दावे के एंडपॉइंट में ज़्यादा पैरामीटर दे सकता है. पैरामीटर एपीआई की मदद से, आरपी, आईडीपी को अतिरिक्त पैरामीटर पास कर सकता है. इससे बेसिक साइन-इन के अलावा, अन्य संसाधनों के लिए भी अनुमतियां मांगी जा सकती हैं. उपयोगकर्ता, इन अनुमतियों को आईडीपी (IdP) से कंट्रोल किए जाने वाले UX फ़्लो की मदद से अनुमति देगा. यह फ़्लो कंटिन्युएशन एपीआई की मदद से लॉन्च किया जाता है.

एपीआई का इस्तेमाल करने के लिए, 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 के तौर पर किया जाएगा:

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) ये काम कर सकता है:

1. navigator.credentials.get() को ऐसे ज़रूरी पैरामीटर के साथ कॉल करें जिन्हें आईडीपी समझ सके, जैसे कि scope.
2. आईडी से जुड़े दावे का एंडपॉइंट से इस बात की पुष्टि होती है कि उपयोगकर्ता ने पहले से साइन इन किया हुआ है. इसके बाद, जवाब continue_on यूआरएल के साथ दिया जाता है.
3. ब्राउज़र, आईडीपी (IdP) के अनुमति वाले पेज पर एक पॉप-अप विंडो खोलता है. इसमें, अनुरोध किए गए दायरों से मेल खाने वाली अतिरिक्त अनुमति मांगी जाती है.
4. आईडीपी (IdP) से IdentityProvider.resolve() के ज़रिए अनुमति मिलने के बाद, विंडो बंद हो जाती है और आरपी के ओरिजनल navigator.credentials.get() कॉल को कोई ज़रूरी टोकन या ऑथराइज़ेशन कोड मिलता है. इससे आरपी उसे सही ऐक्सेस टोकन से बदल पाता है.

फ़ील्ड एपीआई

Fields API, आरपी को आईडीपी से अनुरोध करने के लिए खाते के एट्रिब्यूट का एलान करने देता है, ताकि ब्राउज़र FedCM डायलॉग में सही जानकारी देने वाला यूज़र इंटरफ़ेस (यूआई) रेंडर कर सके. अनुरोध किए गए फ़ील्ड को वापस किए गए टोकन में शामिल करना आईडीपी की ज़िम्मेदारी है. ऐसा करने के लिए, OAuth में "स्कोप" के बजाय OpenID Connect में "बेसिक प्रोफ़ाइल" का अनुरोध करें.

विजेट मोड में जानकारी ज़ाहिर करने वाला मैसेज.

बटन मोड में जानकारी ज़ाहिर करने वाला मैसेज.

फ़ील्ड एपीआई का इस्तेमाल करने के लिए, 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',
});

आईडी दावे के एंडपॉइंट के लिए एचटीटीपी अनुरोध में, आरपी के हिसाब से तय किया गया fields पैरामीटर शामिल होता है. अगर यह लौटने वाला उपयोगकर्ता नहीं है, तो 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

ध्यान दें: फ़िलहाल, Chrome में अपवाद के तौर पर कुछ भी नहीं लिखा जा सकता है. ऐसा तब तक होता है, जब तक आरपी से, fields: ['name', 'email', 'picture'] या fields: [] के बारे में कुछ भी नहीं पूछा जाता. आने वाले समय में, Chrome में यूज़र इंटरफ़ेस (यूआई) को इस तरह से बनाया जाएगा कि वह अलग-अलग कॉम्बिनेशन के बारे में पूछ सके. साथ ही, वह उन वैल्यू के सबसेट को स्वीकार करना शुरू कर देगा.

अगर आरपी को आईडीपी (IdP) के किसी अतिरिक्त डेटा का ऐक्सेस चाहिए, जैसे कि कैलेंडर का ऐक्सेस, तो इस प्रोसेस को ऊपर बताए गए कस्टम पैरामीटर की मदद से मैनेज किया जाना चाहिए. आईडीपी, अनुमति का अनुरोध करने के लिए, 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 खाली कलेक्शन है, तो उपयोगकर्ता एजेंट जानकारी देने वाले यूज़र इंटरफ़ेस (यूआई) को छोड़कर आगे बढ़ जाएगा.

जानकारी देने वाला मैसेज, विजेट मोड में नहीं दिखता. बटन के फ़्लो में, जानकारी देने वाले यूज़र इंटरफ़ेस (यूआई) को पूरी तरह से स्किप कर दिया गया है.

ऐसा तब भी होगा, जब खाते के एंडपॉइंट से मिले जवाब में, ऐसा क्लाइंट आईडी न हो जो approved_clients में आरपी से मेल खाता हो.

इस मामले में, आईडी दावे के एंडपॉइंट को भेजा गया disclosure_text_shown, एचटीटीपी के मुख्य हिस्से में गलत है:

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

एक से ज़्यादा कॉन्फ़िगरेशन यूआरएल, आईडीपी को किसी आईडीपी की कई कॉन्फ़िगरेशन फ़ाइलें शामिल करने की अनुमति देते हैं. इसके लिए, सबसे लोकप्रिय फ़ाइल में 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"
}

इसकी मदद से, हम ये काम कर पाते हैं:

1. मौजूदा लोकप्रिय फ़ाइलों और जंगल में पहले से डिप्लॉय किए गए ब्राउज़र के पुराने वर्शन के साथ पीछे और आगे की संगतता बनाए रखें.
2. कॉन्फ़िगरेशन फ़ाइलों की मनमुताबिक संख्या चुनें. बशर्ते, वे सभी एक ही accounts_endpoint और login_url पर ले जाती हों.
3. एंट्रॉपी को accounts_endpoint पर क्रेडेंशियल के तौर पर फ़ेच करने के अनुरोध में नहीं जोड़ा जा सकता, क्योंकि इसे ".well-known" लेवल पर तय किया जाना ज़रूरी है.

एक से ज़्यादा configURL के साथ काम करना ज़रूरी नहीं है और FedCM को लागू करने की मौजूदा सुविधाएं पहले जैसी ही रह सकती हैं.

कस्टम खाता लेबल

कस्टम खाता लेबल FedCM आईडीपी को खातों को एनोटेट करने की अनुमति देते हैं. इससे आरपी, कॉन्फ़िगरेशन फ़ाइल में लेबल तय करके उन्हें फ़िल्टर कर पाते हैं. डोमेन हिंट एपीआई और लॉगिन संकेत एपीआई का इस्तेमाल करके भी, इसी तरह की फ़िल्टर की जा सकती हैं. इसके लिए, उन्हें navigator.credentials.get() कॉल में शामिल किया गया है. हालांकि, कस्टम खाता लेबल, कॉन्फ़िगरेशन फ़ाइल के बारे में बताकर उपयोगकर्ताओं को फ़िल्टर कर सकते हैं. यह खास तौर पर तब काम आता है, जब कई कॉन्फ़िगरेशन यूआरएल का इस्तेमाल किया जाता है. कस्टम खाता लेबल इस मामले में भी अलग होते हैं कि वे आईडीपी सर्वर से मिलते हैं, न कि आरपी से, लॉगिन करने या डोमेन के संकेत जैसे.

उदाहरण

आईडीपी (IdP) में उपभोक्ता और एंटरप्राइज़ के लिए, दो कॉन्फ़िगरेशन यूआरएल इस्तेमाल किए जा सकते हैं. उपभोक्ता कॉन्फ़िगरेशन फ़ाइल में '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 को अनदेखा कर दिया जाता है. आरपी, 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": "[e-mail]",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "[e-mail]",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

जब आरपी, 'enterprise' उपयोगकर्ताओं को साइन इन करने की अनुमति देना चाहता है, तो वह navigator.credentials.get() कॉल में 'enterprise' कॉन्फ़िगरेशन यूआरएल 'https://idp.example/enterprise/fedcm.json' तय कर सकता है:

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 डायलॉग में एक लॉगिन प्रॉम्प्ट दिखता है. इसकी मदद से, उपयोगकर्ता आईडीपी खाते में लॉग इन कर सकता है. बटन के फ़्लो के लिए, लॉगिन पॉप-अप विंडो सीधे खुल जाती है.

ऑरिजिन ट्रायल: Storage Access API के लिए ट्रस्ट सिग्नल के तौर पर FedCM

Chrome 126, Storage Access API के लिए ट्रस्ट सिग्नल के तौर पर FedCM का ऑरिजिन ट्रायल शुरू कर रहा है. इस बदलाव के बाद, FedCM से पहले दी गई अनुमति, स्टोरेज ऐक्सेस करने वाले एपीआई से स्टोरेज के ऐक्सेस के अनुरोध को अपने-आप मंज़ूरी देने की मान्य वजह बन जाती है.

यह तब काम आता है, जब एम्बेड किया गया कोई iframe, पसंद के मुताबिक बनाए गए संसाधनों को ऐक्सेस करना चाहता है: उदाहरण के लिए, अगर idp.example को rp.example में एम्बेड किया गया है और उसे मनमुताबिक बनाए गए संसाधन दिखाने हों. अगर ब्राउज़र तीसरे पक्ष की कुकी के ऐक्सेस पर पाबंदी लगाता है, भले ही उपयोगकर्ता ने FedCM के साथ idp.example का इस्तेमाल करके rp.example में साइन इन किया हो, तो एम्बेड किया गया idp.example iframe, पसंद के मुताबिक बनाए गए संसाधनों के लिए अनुरोध नहीं कर पाएगा. ऐसा इसलिए, क्योंकि अनुरोधों में तीसरे पक्ष की कुकी शामिल नहीं होंगी.

ऐसा करने के लिए, idp.example को वेबसाइट पर एम्बेड किए गए iframe के ज़रिए, स्टोरेज ऐक्सेस करने की अनुमति लेनी होगी. यह अनुमति, सिर्फ़ अनुमति वाले प्रॉम्प्ट के ज़रिए ही मिल सकती है.

स्टोरेज ऐक्सेस एपीआई के लिए ट्रस्ट सिग्नल के तौर पर FedCM का इस्तेमाल करके, 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 की पुष्टि करने की सुविधा चालू रहती है. इसका मतलब है कि उपयोगकर्ता के डिवाइस के डिसकनेक्ट होने पर, अनुमति मांगने का अनुरोध दिखेगा.

ध्यान दें: एम्बेड किए गए आईडीपी iframe को, स्टोरेज का ऐक्सेस अपने-आप मिलने की अनुमति देने के लिए, भले ही आपने FedCM को iframe में शुरू न किया हो. इसके लिए, आरपी को FedCM identity-credentials-get की अनुमतियों की नीति को साफ़ तौर पर जोड़ना होगा.

ऑरिजिन ट्रायल में हिस्सा लें

Chrome 126 या उसके बाद के वर्शन पर, Chrome फ़्लैग chrome://flags#fedcm-authz को चालू करके, FedCM Continuation API बंडल को स्थानीय तौर पर आज़माया जा सकता है. Chrome 126 या इसके बाद के वर्शन पर #fedcm-with-storage-access-api को चालू करके, Storage Access API के लिए ट्रस्ट सिग्नल के तौर पर FedCM को स्थानीय तौर पर भी आज़माया जा सकता है.

ये सुविधाएं, ऑरिजिन ट्रायल के तौर पर भी उपलब्ध हैं. ऑरिजिन ट्रायल से आपको नई सुविधाएं आज़माने में मदद मिलती है. साथ ही, उनकी उपयोगिता, व्यावहारिकता, और उनके असर के बारे में सुझाव या राय दी जा सकती है. ज़्यादा जानकारी के लिए, ऑरिजिन ट्रायल का इस्तेमाल शुरू करना देखें.

FedCM Continuation API बंडल ऑरिजिन ट्रायल आज़माने के लिए, दो ऑरिजिन ट्रायल टोकन बनाएं:

• मुफ़्त में आज़माने की सुविधा के लिए रजिस्टर करें. आईडीपी (IdP) ऑरिजिन के लिए टोकन को एम्बेड करें.
• ऑरिजिन ट्रायल के लिए रजिस्टर करने के लिए, तीसरे पक्ष के मैचिंग चेकबॉक्स पर सही का निशान लगाएं. आरपी का टोकन एम्बेड करने के लिए, RP के लिए तीसरे पक्ष के ऑरिजिन ट्रायल को रजिस्टर करें में दिए गए निर्देशों का पालन करें.

अगर आपको बटन के फ़्लो के साथ-साथ Continuation API को चालू करना है, तो बटन मोड एपीआई के ऑरिजिन ट्रायल को भी चालू करें:

• ऑरिजिन ट्रायल के लिए तीसरे पक्ष के तौर पर रजिस्टर करें. आरपी का टोकन एम्बेड करने के लिए, आरपी के लिए तीसरे पक्ष के ऑरिजिन ट्रायल को रजिस्टर करें में दिए गए निर्देशों का पालन करें.

स्टोरेज ऐक्सेस एपीआई के ऑरिजिन ट्रायल के लिए, FedCM को ट्रस्ट सिग्नल के तौर पर इस्तेमाल करने के लिए:

• ऑरिजिन ट्रायल के लिए रजिस्टर करें. आईडीपी (IdP) ऑरिजिन के लिए टोकन को एम्बेड करें.

Storage Access API के ऑरिजिन ट्रायल के लिए, ट्रस्ट सिग्नल के तौर पर Continuation API बंडल ऑरिजिन ट्रायल और FedCM, Chrome 126 पर उपलब्ध हैं.

आरपी के लिए, तीसरे पक्ष का ऑरिजिन ट्रायल रजिस्टर करें

1. ऑरिजिन ट्रायल के रजिस्ट्रेशन पेज पर जाएं.
2. टोकन का अनुरोध करने के लिए, रजिस्टर करें बटन पर क्लिक करें और फ़ॉर्म भरें.
3. आईडीपी (IdP) के ऑरिजिन को वेब ऑरिजिन के तौर पर डालें.
4. अन्य ऑरिजिन पर JavaScript वाला टोकन इंजेक्ट करने के लिए, तीसरे पक्ष की मैचिंग की जांच करें.
5. सबमिट करें पर क्लिक करें.
6. जारी किए गए टोकन को तीसरे पक्ष की वेबसाइट पर जोड़ें.

किसी तीसरे पक्ष की वेबसाइट पर टोकन को एम्बेड करने के लिए, आईडीपी (IdP) की JavaScript लाइब्रेरी या उसके ऑरिजिन से इस्तेमाल किए जाने वाले SDK टूल में यहां दिया गया कोड जोड़ें.

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

TOKEN_GOES_HERE को अपने टोकन से बदलें.

ध्यान दें: अगर FedCM API को आरपी ने शुरू किया है, न कि आईडीपी (IdP) से लोड की गई स्क्रिप्ट के ज़रिए, तो आरपी को अपने ऑरिजिन को खुद रजिस्टर करना होगा. साथ ही, पहले पक्ष के ऑरिजिन ट्रायल को चलाना होगा.