इस पेज का अनुवाद Cloud Translation API से किया गया है.

FedCM की मदद से आइडेंटिटी सलूशन लागू करना

FedCM (फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट), पहचान की पुष्टि करने वाली सेवाओं (जैसे, "इससे साइन इन करें") के लिए, निजता बनाए रखने से जुड़ा एक सुझाव है. इसमें लोग अपनी निजी जानकारी ज़ाहिर किए बिना, पहचान करने वाली सेवा और साइट में लॉग इन कर सकते हैं.

FedCM को लागू करने में, IdP (आइडेंटिटी प्रोवाइडर) और RP (भरोसेमंद पार्टी) दोनों के लिए कई मुख्य चरण शामिल होते हैं.

FedCM को लागू करने के लिए, IdPs को यह तरीका अपनाना होगा:

well-known फ़ाइल बनाएं.
config फ़ाइल बनाएं.
ये एंडपॉइंट बनाएं:
- खाते का एंडपॉइंट
- आईडी एश्योरेशन एंडपॉइंट
- [ज़रूरी नहीं] एंडपॉइंट को डिसकनेक्ट करना
- [ज़रूरी नहीं] क्लाइंट मेटाडेटा एंडपॉइंट
- लॉगिन एंडपॉइंट
ब्राउज़र को उपयोगकर्ता के लॉगिन स्टेटस के बारे में बताएं.

अपनी साइट पर FedCM चालू करने के लिए, आरपी को यह तरीका अपनाना होगा:

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

ध्यान दें: हमारा सुझाव है कि एपीआई के बेहतर होने तक, आईडीपी, FedCM JavaScript API को ऐक्सेस करने के लिए लाइब्रेरी उपलब्ध कराएं. साथ ही, आरपी को एसडीके को खुद होस्ट करने से रोकें. इससे यह पक्का किया जा सकेगा कि एपीआई के अपडेट होने के साथ-साथ, आईडीपी भी बदलाव कर सकें. इसके लिए, उन्हें अपने सभी भरोसेमंद पक्षों से फिर से डिप्लॉय करने के लिए नहीं कहना पड़ेगा.

FedCM को आईडीपी (IdP) के तौर पर लागू करना

आईडीपी की ओर से FedCM को लागू करने के तरीके के बारे में ज़्यादा जानें.

.well-known फ़ाइल बनाना

ट्रैकर को एपीआई का गलत इस्तेमाल करने से रोकने के लिए, आईडीपी के eTLD+1 के /.well-known/web-identity से कोई जानी-पहचानी फ़ाइल भेजी जानी चाहिए.

अच्छी तरह से पहचानी जाने वाली फ़ाइल में ये प्रॉपर्टी शामिल हो सकती हैं:

प्रॉपर्टी	ज़रूरी है	ब्यौरा
`provider_urls`	ज़रूरी है	आईडीपी कॉन्फ़िगरेशन फ़ाइल के पाथ का कलेक्शन. अगर `accounts_endpoint` और `login_url` की वैल्यू दी गई है, तो इस पैरामीटर की वैल्यू को अनदेखा कर दिया जाएगा. हालांकि, इस पैरामीटर की वैल्यू देना ज़रूरी है.
`accounts_endpoint`	सुझाया गया, इसके लिए `login_url` की ज़रूरत है	खातों के एंडपॉइंट का यूआरएल. इससे एक से ज़्यादा कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि हर config फ़ाइल में एक ही `login_url` और `accounts_endpoint` यूआरएल का इस्तेमाल किया गया हो. ध्यान दें: यह पैरामीटर, Chrome 132 से काम करता है.
`login_url`	सुझाया गया, इसके लिए `accounts_endpoint` की ज़रूरत है	आईडीपी (IdP) में साइन इन करने के लिए, उपयोगकर्ता का लॉगिन पेज यूआरएल. इससे एक से ज़्यादा कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि हर config फ़ाइल में एक ही `login_url` और `accounts_endpoint` का इस्तेमाल किया गया हो. ध्यान दें: यह पैरामीटर, Chrome के 132 और इसके बाद के वर्शन में काम करता है.

उदाहरण के लिए, अगर आईडीपी एंडपॉइंट https://accounts.idp.example/ के तहत दिखाए जाते हैं, तो उन्हें https://idp.example/.well-known/web-identity पर आईडीपी कॉन्फ़िगरेशन फ़ाइल के साथ-साथ एक अच्छी तरह से जानी-पहचानी फ़ाइल भी दिखानी होगी. यहां एक लोकप्रिय फ़ाइल कॉन्टेंट का उदाहरण दिया गया है:

  {
    "provider_urls": ["https://accounts.idp.example/config.json"]
  }

आईडीपी, .well-known फ़ाइल में accounts_endpoint और login_url की जानकारी देकर, एक आईडीपी के लिए कई कॉन्फ़िगरेशन फ़ाइलें जोड़ सकते हैं.
यह सुविधा इन मामलों में मददगार हो सकती है:

किसी आईडीपी को टेस्ट और प्रोडक्शन के लिए, अलग-अलग कॉन्फ़िगरेशन के साथ काम करना चाहिए.
आईडीपी को हर क्षेत्र के लिए अलग-अलग कॉन्फ़िगरेशन के साथ काम करना चाहिए. उदाहरण के लिए, eu-idp.example और us-idp.example.

एक से ज़्यादा कॉन्फ़िगरेशन के साथ काम करने के लिए, IdP को accounts_endpoint और login_url की जानकारी देनी होगी. उदाहरण के लिए, टेस्ट और प्रोडक्शन एनवायरमेंट के बीच अंतर करने के लिए:

  {
    // This property is required, but will be ignored when IdP supports
    // multiple configs (when `accounts_endpoint` and `login_url` are
    // specified), as long as `accounts_endpoint` and `login_url` in
    // that config file match those in the well-known file.
    "provider_urls": [ "https://idp.example/fedcm.json" ],

    // Specify accounts_endpoint and login_url properties to support
    // multiple config files.
    // Note: The accounts_endpoint and login_url must be identical
    // across all config files. Otherwise,
    // the configurations won't be supported.
    "accounts_endpoint": "https://idp.example/accounts",
    "login_url": "https://idp.example/login"
  }

सलाह: FedCM का इस्तेमाल करते समय, टेस्टिंग या स्टेजिंग आरपी सर्वर डोमेन, प्रोडक्शन आईडीपी सर्वर के सबडोमेन हो सकते हैं. उदाहरण के लिए, प्रोडक्शन IdP सर्वर idp.example पर है और स्टैजिंग RP सर्वर और स्टैजिंग IdP सर्वर, दोनों staging.idp.example पर हैं. हालांकि, अच्छी तरह से पहचानी जाने वाली फ़ाइल, आईडीपी सर्वर के ईटीएलडी+1 के रूट में होनी चाहिए. इसलिए, यह idp.example/.well-known/web-identity में होनी चाहिए और यह प्रोडक्शन सर्वर होना चाहिए. डेवलपर के लिए, ऐप्लिकेशन डेवलप करने के दौरान, प्रोडक्शन एनवायरमेंट में फ़ाइलें डालना ज़रूरी नहीं है. इसलिए, वे FedCM की जांच नहीं कर पाते. अगर आरपी डोमेन और आईडीपी डोमेन एक ही हैं, तो Chrome 122 से Chrome, अच्छी तरह से जानी-पहचानी फ़ाइल की जांच को छोड़ सकता है. chrome://flags#fedcm-without-well-known-enforcement फ़्लैग को चालू करके, configURL की जांच को बायपास भी किया जा सकता है. यह तब काम आता है, जब आपके डेवलपमेंट एनवायरमेंट में ऐसे डीएनएस का इस्तेमाल किया जाता है जो सार्वजनिक तौर पर ऐक्सेस नहीं किया जा सकता.

आईडीपी कॉन्फ़िगरेशन फ़ाइल और एंडपॉइंट बनाना

आईडीपी कॉन्फ़िगरेशन फ़ाइल, ब्राउज़र के लिए ज़रूरी एंडपॉइंट की सूची उपलब्ध कराती है. आईडीपी को एक या एक से ज़्यादा कॉन्फ़िगरेशन फ़ाइलों के साथ-साथ ज़रूरी एंडपॉइंट और यूआरएल को होस्ट करना होगा. सभी JSON रिस्पॉन्स, application/json कॉन्टेंट-टाइप के साथ दिखाए जाने चाहिए.

कॉन्फ़िगरेशन फ़ाइल का यूआरएल, navigator.credentials.get() कॉल पर लागू होने वाली वैल्यू के आधार पर तय होता है.

  const credential = await navigator.credentials.get({
    identity: {
      context: 'signup',
      providers: [{
        configURL: 'https://accounts.idp.example/config.json',
        clientId: '********',
        nonce: '******'
      }]
    }
  });
  const { token } = credential;

उपयोगकर्ता को साइन इन करने की अनुमति देने के लिए, आरपी, कॉन्फ़िगरेशन फ़ाइल का यूआरएल FedCM API कॉल को भेजेगा:

  // Executed on RP's side:
  const credential = await navigator.credentials.get({
    identity: {
      context: 'signup',
      providers: [{
        // To allow users to sign in with an IdP using FedCM, RP specifies the IdP's config file URL:
        configURL: 'https://accounts.idp.example/fedcm.json',
        clientId: '********',
  });
  const { token } = credential;

ब्राउज़र, GET हेडर के बिना Origin हेडर या Referer हेडर के साथ कॉन्फ़िगरेशन फ़ाइल फ़ेच करेगा. अनुरोध में कुकी नहीं हैं और यह रीडायरेक्ट का पालन नहीं करता. इससे आईडीपी को यह जानने से रोका जा सकता है कि अनुरोध किसने किया है और कौनसा आरपी कनेक्ट करने की कोशिश कर रहा है. उदाहरण के लिए:

  GET /config.json HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Sec-Fetch-Dest: webidentity

चेतावनी: FedCM का इस्तेमाल करके ब्राउज़र से भेजे गए सभी अनुरोधों में, सीएसआरएफ़ हमलों को रोकने के लिए Sec-Fetch-Dest: webidentity हेडर शामिल होता है. इन आईडीपी एंडपॉइंट को इस हेडर के शामिल होने की पुष्टि करनी होगी:

खाते का एंडपॉइंट
आईडी एश्योरेशन एंडपॉइंट
एंडपॉइंट को डिसकनेक्ट करना

आईडीपी को ऐसा कॉन्फ़िगरेशन एंडपॉइंट लागू करना होगा जो JSON के साथ जवाब देता हो. JSON में ये प्रॉपर्टी शामिल हैं:

प्रॉपर्टी	ब्यौरा
`accounts_endpoint` (ज़रूरी)	खाते के एंडपॉइंट का यूआरएल.
`accounts.include` (वैकल्पिक)	कस्टम खाता लेबल स्ट्रिंग, जो यह तय करती है कि इस कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करने पर कौनसे खाते दिखाए जाएं. उदाहरण के लिए: `"accounts": {"include": "developer"}`. कोई आईडीपी, कस्टम खाता लेबल करने की सुविधा को इस तरह लागू कर सकता है: इस `accounts.include` पैरामीटर का इस्तेमाल करके, खास लेबल से जुड़ी कॉन्फ़िगरेशन फ़ाइल बनाएं. खातों के एंडपॉइंट में लेबल तय करें. उदाहरण के लिए, कोई आईडीपी, `"accounts": {"include": "developer"}` के साथ `"https://idp.example/developer-config.json"` config फ़ाइल लागू करता है. आईडीपी, खातों के एंडपॉइंट में `labels` पैरामीटर का इस्तेमाल करके, कुछ खातों को `"developer"` लेबल से भी मार्क करता है. जब कोई आरपी, `"https://idp.example/developer-config.json"` कॉन्फ़िगरेशन फ़ाइल के साथ `navigator.credentials.get()` को कॉल करता है, तो सिर्फ़ `"developer"` लेबल वाले खाते दिखाए जाएंगे.
`client_metadata_endpoint` (वैकल्पिक)	क्लाइंट मेटाडेटा एंडपॉइंट का यूआरएल.
`id_assertion_endpoint` (ज़रूरी)	आईडी एश्योरेशन एंडपॉइंट का यूआरएल.
`disconnect` (वैकल्पिक)	डिसकनेक्ट एंडपॉइंट का यूआरएल.
`login_url` (ज़रूरी)	आईडीपी (IdP) में साइन इन करने के लिए, उपयोगकर्ता का लॉगिन पेज यूआरएल.
`branding` (वैकल्पिक)	ब्रैंडिंग के अलग-अलग विकल्पों वाला ऑब्जेक्ट.
`branding.background_color` (वैकल्पिक)	ब्रैंडिंग का विकल्प, जो "इसी तौर पर जारी रखें..." बटन के बैकग्राउंड का रंग सेट करता है. सीएसएस के सही सिंटैक्स का इस्तेमाल करें. जैसे, `hex-color`, `hsl()`, `rgb()` या `named-color`.
`branding.color` (वैकल्पिक)	ब्रैंडिंग का विकल्प, जो "इस तौर पर जारी रखें..." बटन के टेक्स्ट का रंग सेट करता है. सीएसएस के सही सिंटैक्स का इस्तेमाल करें. जैसे, `hex-color`, `hsl()`, `rgb()` या `named-color`.
`branding.icons` (वैकल्पिक)	आइकॉन ऑब्जेक्ट का कलेक्शन. ये आइकॉन, साइन इन डायलॉग में दिखते हैं. आइकॉन ऑब्जेक्ट में दो पैरामीटर होते हैं: `url` (ज़रूरी है): आइकॉन इमेज का यूआरएल. इसमें SVG इमेज का इस्तेमाल नहीं किया जा सकता. `size` (ज़रूरी नहीं): आइकॉन के डाइमेंशन, जिन्हें ऐप्लिकेशन स्क्वेयर और सिंगल रिज़ॉल्यूशन मानता है. यह संख्या, पैसिव मोड में 25 पिक्सल से ज़्यादा या उसके बराबर और ऐक्टिव मोड में 40 पिक्सल से ज़्यादा या उसके बराबर होनी चाहिए.
`modes`	यह ऑब्जेक्ट, अलग-अलग मोड में FedCM यूज़र इंटरफ़ेस (यूआई) के दिखने के तरीके के बारे में जानकारी देता है: `active` `passive`
`modes.active`	ऐसा ऑब्जेक्ट जिसमें ऐसी प्रॉपर्टी होती हैं जिनकी मदद से, किसी खास मोड में FedCM के व्यवहार को पसंद के मुताबिक बनाया जा सकता है. `modes.active` और `modes.passive`, दोनों में यह पैरामीटर शामिल हो सकता है: `supports_use_other_account`: बूलियन वैल्यू, जो बताती है कि उपयोगकर्ता उस खाते से साइन इन कर सकता है या नहीं जिससे वह फ़िलहाल लॉग इन है. ऐसा तब होता है, जब आईडीपी एक से ज़्यादा खातों के साथ काम करता हो. ध्यान दें: 'दूसरे खाते का इस्तेमाल करें' सुविधा और ऐक्टिव मोड, Chrome 132 से काम करते हैं.
`modes.passive`

यहां आईडीपी से मिले रिस्पॉन्स बॉडी का उदाहरण दिया गया है:

  {
    "accounts_endpoint": "/accounts.example",
    "client_metadata_endpoint": "/client_metadata.example",
    "id_assertion_endpoint": "/assertion.example",
    "disconnect_endpoint": "/disconnect.example",
    "login_url": "/login",
    // When RPs use this config file, only those accounts will be
    //returned that include `developer` label in the accounts endpoint.
    "accounts": {"include": "developer"},
    "modes": {
        "active": {
          "supports_use_other_account": true,
        }
    },
    "branding": {
      "background_color": "green",
      "color": "#FFEEAA",
      "icons": [{
        "url": "https://idp.example/icon.ico",
        "size": 25
      }]
    }
  }

ब्राउज़र कॉन्फ़िगरेशन फ़ाइल फ़ेच करने के बाद, आईडीपी एंडपॉइंट पर ये अनुरोध भेजता है:

किसी दूसरे खाते का इस्तेमाल करना

अगर आईडीपी, एक से ज़्यादा खातों के साथ काम करता है या मौजूदा खाते को बदलता है, तो उपयोगकर्ता उस खाते से स्विच कर सकते हैं जिससे वे फ़िलहाल लॉग इन हैं.

उपयोगकर्ता को अन्य खाते चुनने की सुविधा देने के लिए, आईडीपी को config फ़ाइल में इस सुविधा के बारे में बताना होगा:

  {
    "accounts_endpoint" : "/accounts.example",
    "modes": {
      "active": {
        // Allow the user to choose other account (false by default)
        "supports_use_other_account": true
      }
      // "passive" mode can be configured separately
    }
  }

खातों का एंडपॉइंट

आईडीपी का खाता एंडपॉइंट, उन खातों की सूची दिखाता है जिनमें उपयोगकर्ता ने आईडीपी पर साइन इन किया है. अगर आईडीपी एक से ज़्यादा खातों के साथ काम करता है, तो यह एंडपॉइंट, साइन इन किए गए सभी खातों की जानकारी दिखाएगा.

ब्राउज़र, SameSite=None के साथ कुकी के साथ GET अनुरोध भेजता है, लेकिन client_id पैरामीटर, Origin हेडर या Referer हेडर के बिना. इससे, आईडीपी को यह पता नहीं चलता कि उपयोगकर्ता किस आरपी में साइन इन करने की कोशिश कर रहा है. उदाहरण के लिए:

  GET /accounts.example HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

अनुरोध मिलने पर, सर्वर को:

पुष्टि करें कि अनुरोध में Sec-Fetch-Dest: webidentity एचटीटीपी हेडर शामिल हो.
सेशन कुकी को, पहले से साइन इन किए गए खातों के आईडी से मैच करें.
खातों की सूची के साथ जवाब दें.

ब्राउज़र को JSON रिस्पॉन्स चाहिए, जिसमें accounts प्रॉपर्टी के साथ खाते की जानकारी का कलेक्शन शामिल हो. इस कलेक्शन में ये प्रॉपर्टी होनी चाहिए:

प्रॉपर्टी	ब्यौरा
`id` (ज़रूरी)	उपयोगकर्ता का यूनीक आईडी.
`name` (ज़रूरी)	उपयोगकर्ता का नाम और उपनाम.
`email` (ज़रूरी)	उपयोगकर्ता का ईमेल पता.
`given_name` (वैकल्पिक)	उपयोगकर्ता का नाम.
`picture` (वैकल्पिक)	उपयोगकर्ता की अवतार इमेज का यूआरएल.
`approved_clients` (वैकल्पिक)	आरपी क्लाइंट आईडी का एक कलेक्शन, जिसके साथ उपयोगकर्ता ने रजिस्टर किया है.
`login_hints` (वैकल्पिक)	सभी संभावित फ़िल्टर टाइप का कलेक्शन, जिससे आईडीपी किसी खाते के बारे में बता सकता है. आरपी, `loginHint` प्रॉपर्टी के साथ `navigator.credentials.get()` को शुरू करके, चुने गए खाते को दिखा सकता है.
`domain_hints` (वैकल्पिक)	उन सभी डोमेन का कलेक्शन जिनसे खाता जुड़ा है. खातों को फ़िल्टर करने के लिए, आरपी `domainHint` प्रॉपर्टी के साथ `navigator.credentials.get()` को कॉल कर सकता है.
`labels` (वैकल्पिक)	कस्टम खाता लेबल की स्ट्रिंग का कलेक्शन, जिनसे कोई खाता जुड़ा है. कोई आईडीपी, कस्टम खाता लेबल करने की सुविधा को इस तरह लागू कर सकता है: खातों के एंडपॉइंट में खाते के लेबल तय करें. इसके लिए, इस `labels` पैरामीटर का इस्तेमाल करें. हर खास लेबल के लिए एक config फ़ाइल बनाएं. उदाहरण के लिए, कोई आईडीपी, `"accounts": {"include": "developer"}` के साथ `https://idp.example/developer-config.json` config फ़ाइल लागू करता है. आईडीपी, खाता एंडपॉइंट में `labels` पैरामीटर का इस्तेमाल करके, कुछ खातों को `"developer"` लेबल से भी मार्क करता है. जब कोई आरपी, `https://idp.example/developer-config.json` कॉन्फ़िगरेशन फ़ाइल के साथ `navigator.credentials.get()` को कॉल करता है, तो सिर्फ़ `"developer"` लेबल वाले खाते दिखाए जाएंगे. कस्टम खाता लेबल, लॉगिन हिंट और डोमेन हिंट से इस तरह अलग होते हैं कि इन्हें आईडीपी सर्वर पूरी तरह से मैनेज करता है. आरपी सिर्फ़ इस्तेमाल करने के लिए कॉन्फ़िगरेशन फ़ाइल तय करता है.

रिस्पॉन्स बॉडी का उदाहरण:

  {
    "accounts": [{
      "id": "1234",
      "given_name": "John",
      "name": "John Doe",
      "email": "john_doe@idp.example",
      "picture": "https://idp.example/profile/123",
      // Ids of those RPs where this account can be used
      "approved_clients": ["123", "456", "789"],
      // This account has 'login_hints`. When an RP calls `navigator.credentials.get()`
      // with a `loginHint` value specified, for example, `exampleHint`, only those
      // accounts will be shown to the user whose 'login_hints' array contains the `exampleHint`.
      "login_hints": ["demo1", "exampleHint"],
      // This account is labelled. IdP can implement a specific config file for a
      // label, for example, `https://idp.example/developer-config.json`. Like that
      // RPs can filter out accounts by calling `navigator.credentials.get()` with
      // `https://idp.example/developer-config.json` config file.
      "labels": ["hr", "developer"]
    }, {
      "id": "5678",
      "given_name": "Johnny",
      "name": "Johnny",
      "email": "johnny@idp.example",
      "picture": "https://idp.example/profile/456",
      "approved_clients": ["abc", "def", "ghi"],
      "login_hints": ["demo2"],
      "domain_hints": ["@domain.example"]
    }]
  }

अगर उपयोगकर्ता ने साइन इन नहीं किया है, तो HTTP 401 (अनुमति नहीं है) के साथ जवाब दें.

खातों की लिस्ट को ब्राउज़र इस्तेमाल करता है और यह आरपी के लिए उपलब्ध नहीं होगी.

आईडी एश्योरेशन एंडपॉइंट

आईडीपी का आईडी एश्योरेशन एंडपॉइंट, साइन इन किए हुए उपयोगकर्ता के लिए एश्योरेशन दिखाता है. जब उपयोगकर्ता navigator.credentials.get() कॉल का इस्तेमाल करके किसी आरपी वेबसाइट में साइन इन करता है, तो ब्राउज़र इस एंडपॉइंट पर POST अनुरोध भेजता है. इसमें, SameSite=None कुकी और application/x-www-form-urlencoded कॉन्टेंट टाइप के साथ यह जानकारी शामिल होती है:

प्रॉपर्टी	ब्यौरा
`client_id` (ज़रूरी)	आरपी का क्लाइंट आइडेंटिफ़ायर.
`account_id` (ज़रूरी)	साइन इन करने वाले उपयोगकर्ता का यूनीक आईडी.
`disclosure_text_shown`	नतीजे, बूलियन के बजाय `"true"` या `"false"` की स्ट्रिंग में मिलते हैं. इन मामलों में नतीजा `"false"` होता है: अगर जानकारी ज़ाहिर करने वाला टेक्स्ट इसलिए नहीं दिखाया गया, क्योंकि आरपी का क्लाइंट आईडी, खाता एंडपॉइंट से मिले रिस्पॉन्स की `approved_clients` प्रॉपर्टी सूची में शामिल था. अगर जानकारी ज़ाहिर करने वाला टेक्स्ट इसलिए नहीं दिखाया गया, क्योंकि ब्राउज़र ने `approved_clients` की अनुपस्थिति में, पहले कभी साइन-अप के समय की जानकारी देखी है. अगर `fields` पैरामीटर में तीन फ़ील्ड ("name", "email", और "picture") में से एक या उससे ज़्यादा फ़ील्ड शामिल नहीं हैं, जैसे कि `fields=[ ]` या `fields=['name', 'picture']`. यह पुराने आईडीपी लागू करने के साथ बैकवर्ड कम्पैटिबिलिटी के लिए ज़रूरी है. इन आईडीपी के लिए, यह ज़रूरी है कि डिसक्लोज़र स्ट्रिंग में हमेशा तीनों फ़ील्ड शामिल हों.
`is_auto_selected`	अगर आरपी पर अपने-आप फिर से पुष्टि करने की सुविधा चालू है, तो `is_auto_selected` से `"true"` का पता चलता है. इसके अलावा, `"false"`. इससे, सुरक्षा से जुड़ी ज़्यादा सुविधाओं को इस्तेमाल करने में मदद मिलती है. उदाहरण के लिए, कुछ उपयोगकर्ता ज़्यादा सुरक्षा वाले टीयर को प्राथमिकता दे सकते हैं. इसके लिए, पुष्टि करने के दौरान उपयोगकर्ता को साफ़ तौर पर पुष्टि करनी होगी. अगर किसी आईडीपी को इस तरह के मीडिएशन के बिना टोकन का अनुरोध मिलता है, तो वह अनुरोध को अलग तरीके से हैंडल कर सकता है. उदाहरण के लिए, गड़बड़ी का ऐसा कोड दिखाएं जिससे आरपी, `mediation: required` की मदद से FedCM API को फिर से कॉल कर सके.
`fields` (वैकल्पिक)	स्ट्रिंग का कलेक्शन, जिसमें उपयोगकर्ता की वह जानकारी होती है ("name", " email", "picture") जिसे आरपी को आईडीपी से शेयर करना होता है. ब्राउज़र, पोस्ट अनुरोध में बताए गए फ़ील्ड की सूची `fields`, `disclosure_text_shown`, और `disclosure_shown_for` भेजेगा, जैसा कि इस उदाहरण में दिखाया गया है. ध्यान दें: फ़ील्ड पैरामीटर, Chrome 132 से काम करता है.
`params` (वैकल्पिक)	कोई भी मान्य JSON ऑब्जेक्ट, जो अतिरिक्त कस्टम की-वैल्यू पैरामीटर तय करने की अनुमति देता है. उदाहरण के लिए: `scope`: स्ट्रिंग वैल्यू, जिसमें अतिरिक्त अनुमतियां होती हैं. आरपी को इन अनुमतियों का अनुरोध करना होता है. उदाहरण के लिए, `"drive.readonly calendar.readonly"` `nonce`: आरपी की ओर से दी गई एक रैंडम स्ट्रिंग, ताकि यह पक्का किया जा सके कि जवाब इस खास अनुरोध के लिए जारी किया गया है. जवाबी हमलों को रोकता है. अन्य कस्टम की-वैल्यू पैरामीटर. जब ब्राउज़र कोई POST अनुरोध भेजता है, तो `params` वैल्यू को JSON में क्रम से लगाया जाएगा और फिर प्रतिशत में बदला जाएगा. ध्यान दें: Parameters API, Chrome 132 और इसके बाद के वर्शन पर काम करता है.

एचटीटीपी हेडर का उदाहरण:

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

  // disclosure_text_shown is set to 'false', as the 'name' field value is missing in 'fields' array
  // params value is serialized to JSON and then percent-encoded.
  account_id=123&client_id=client1234&disclosure_text_shown=false&is_auto_selected=true&params=%22%7B%5C%22nonce%5C%22%3A%5C%22nonce-value%5C%22%7D%22.%0D%0A4&disclosure_text_shown=true&fields=email,picture&disclosure_shown_for=email,picture

अनुरोध मिलने पर, सर्वर को:

सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) की मदद से अनुरोध का जवाब दें.
पुष्टि करें कि अनुरोध में Sec-Fetch-Dest: webidentity एचटीटीपी हेडर शामिल हो.
Origin हेडर को client_id से तय किए गए आरपी ऑरिजिन से मैच करें. अगर वे मैच नहीं करते हैं, तो उन्हें अस्वीकार करें.
account_id को पहले से साइन इन किए गए खाते के आईडी से मैच करें. अगर वे मेल नहीं खाते हैं, तो अस्वीकार करें.
टोकन की मदद से जवाब दें. अगर अनुरोध अस्वीकार कर दिया जाता है, तो गड़बड़ी का जवाब दें.

चेतावनी: सीओआरएस अनुरोध में क्रेडेंशियल होने चाहिए. इसका मतलब है कि Access-Control-Allow-Origin रिस्पॉन्स हेडर में, "*" का इस्तेमाल करके वाइल्डकार्ड के बजाय, साफ़ तौर पर ऑरिजिन की जानकारी होनी चाहिए.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://rp.example
Access-Control-Allow-Credentials: true

आईडीपी यह तय कर सकता है कि वह टोकन कैसे जारी करेगा. आम तौर पर, इस पर खाता आईडी, क्लाइंट आईडी, जारी करने वाले की जानकारी, और नॉन्स जैसी जानकारी के साथ हस्ताक्षर किया जाता है, ताकि आरपी इस बात की पुष्टि कर सके कि टोकन असली है.

ब्राउज़र को JSON रिस्पॉन्स चाहिए, जिसमें यह प्रॉपर्टी शामिल हो:

प्रॉपर्टी	ब्यौरा
`token`	टोकन एक स्ट्रिंग होती है, जिसमें पुष्टि करने के बारे में दावे होते हैं.
`continue_on`	रीडायरेक्ट यूआरएल, जो कई चरणों वाले साइन-इन फ़्लो को चालू करता है.

ब्राउज़र, रिटर्न किया गया टोकन आरपी को भेजता है, ताकि आरपी पुष्टि की पुष्टि कर सके.

  {
    // IdP can respond with a token to authenticate the user
    "token": "***********"
  }

'जारी रखें' सुविधा

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

उपयोगकर्ता के सर्वर-साइड संसाधनों को ऐक्सेस करने की अनुमति.
पुष्टि करना कि संपर्क जानकारी अप-टू-डेट है.
माता-पिता का कंट्रोल.

आईडी एश्योरेशन एंडपॉइंट, 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 popup window:
    "continue_on": "https://idp.example/continue_on_url"
  }

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

  document.getElementById('example-button').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);
  });

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

  IdentityProvider.close();

Continuation API के काम करने के लिए, उपयोगकर्ता के इंटरैक्शन (क्लिक) की ज़रूरत होती है. यहां बताया गया है कि अलग-अलग मीडिएशन मोड के साथ, Continuation API कैसे काम करता है:

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

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

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

गड़बड़ी का जवाब देना

id_assertion_endpoint, "गड़बड़ी" वाला रिस्पॉन्स भी दिखा सकता है. इसमें दो वैकल्पिक फ़ील्ड होते हैं:

code: IdP, OAuth 2.0 के मुताबिक बताई गई गड़बड़ी की सूची (invalid_request, unauthorized_client, access_denied, server_error, और temporarily_unavailable) में से किसी एक गड़बड़ी को चुन सकता है या अपनी पसंद की कोई स्ट्रिंग इस्तेमाल कर सकता है. अगर ऐसा होता है, तो Chrome, गड़बड़ी के यूज़र इंटरफ़ेस (यूआई) को सामान्य गड़बड़ी के मैसेज के साथ रेंडर करता है और कोड को आरपी को भेजता है.
url: यह गड़बड़ी के बारे में जानकारी देने वाले ऐसे वेब पेज की पहचान करता है जिसे कोई भी व्यक्ति पढ़ सकता है. इससे, उपयोगकर्ताओं को गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है. यह फ़ील्ड, उपयोगकर्ताओं के लिए फ़ायदेमंद है, क्योंकि ब्राउज़र, पहले से मौजूद यूज़र इंटरफ़ेस (यूआई) में गड़बड़ी के बारे में ज़्यादा जानकारी देने वाले मैसेज नहीं दिखा सकते. उदाहरण के लिए: अगले चरण के लिए लिंक या ग्राहक सेवा से संपर्क करने की जानकारी. अगर किसी उपयोगकर्ता को गड़बड़ी की जानकारी और उसे ठीक करने के तरीके के बारे में ज़्यादा जानना है, तो वह ज़्यादा जानकारी के लिए ब्राउज़र यूज़र इंटरफ़ेस (यूआई) से दिए गए पेज पर जा सकता है. यूआरएल, आईडीपी configURL की साइट का ही होना चाहिए.

  // id_assertion_endpoint response
  {
    "error" : {
      "code": "access_denied",
      "url" : "https://idp.example/error?type=access_denied"
    }
  }

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

पसंद के मुताबिक खाता लेबल की मदद से, आईडीपी, उपयोगकर्ता खातों को लेबल के साथ एनोटेट कर सकता है. साथ ही, आरपी उस लेबल के लिए configURL तय करके, सिर्फ़ खास लेबल वाले खातों को फ़ेच कर सकता है. यह तब काम आ सकता है, जब किसी आरपी को किसी खास शर्त के हिसाब से खातों को फ़िल्टर करना हो. उदाहरण के लिए, सिर्फ़ भूमिका के हिसाब से खाते दिखाने के लिए, जैसे कि "developer" या "hr".

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

मान लें कि कोई आईडीपी, "developer" और "hr" खातों के बीच अंतर करना चाहता है. ऐसा करने के लिए, आईडीपी को "developer" और "hr" के लिए, दो configURLs के साथ काम करना होगा:

डेवलपर कॉन्फ़िगरेशन फ़ाइल https://idp.example/developer/fedcm.json में "developer" लेबल है और एंटरप्राइज़ कॉन्फ़िगरेशन फ़ाइल https://idp.example/hr/fedcm.json में "hr" लेबल है. इनका इस्तेमाल इस तरह किया जाता है:

  // The developer config file at `https://idp.example/developer/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "accounts": {
      // Account label
      "include": "developer"
    }
  }

  // The hr config file at `https://idp.example/hr/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "accounts": {
      // Account label
      "include": "hr"
    }
  }

इस तरह के सेटअप में, एक से ज़्यादा configURLs की अनुमति देने के लिए, well-known फ़ाइल में accounts_endpoint और login_url शामिल होने चाहिए:

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

सामान्य आईडीपी खाता एंडपॉइंट (इस उदाहरण में 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": ["developer"]
    }], [{
    "id": "4567",
    "given_name": "Jane",
    "name": "Jane Doe",
    "email": "jane_doe@idp.example",
    "picture": "https://idp.example/profile/4567",
    "labels": ["hr"]
    }]
  }

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

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

इस वजह से, उपयोगकर्ता के पास साइन इन करने के लिए सिर्फ़ 4567 का खाता आईडी उपलब्ध है. ब्राउज़र, 123 का खाता आईडी चुपचाप छिपा देता है, ताकि उपयोगकर्ता को ऐसा खाता न दिया जाए जो इस साइट पर आईडीपी के साथ काम न करता हो.

लेबल स्ट्रिंग होते हैं. अगर labels ऐरे या include फ़ील्ड में कोई ऐसी वैल्यू है जो स्ट्रिंग नहीं है, तो उसे अनदेखा कर दिया जाता है.
अगर configURL में कोई लेबल नहीं दिया गया है, तो FedCM खाता चुनने वाले टूल में सभी खाते दिखेंगे.
अगर किसी खाते के लिए कोई लेबल नहीं दिया गया है, तो वह खाता चुनने वाले टूल में सिर्फ़ तब दिखेगा, जब configURL में भी कोई लेबल न दिया गया हो.
अगर कोई खाता, अनुरोध किए गए लेबल से मेल नहीं खाता है, तो FedCM डायलॉग बॉक्स में लॉगिन प्रॉम्प्ट दिखता है. इसकी मदद से, उपयोगकर्ता किसी आईडीपी खाते में साइन इन कर सकता है. यह सुविधा, डोमेन के बारे में हिंट देने वाली सुविधा जैसी ही है. ऐक्टिव मोड के लिए, लॉगिन पॉप-अप विंडो सीधे खुलती है.

एंडपॉइंट को डिसकनेक्ट करना

IdentityCredential.disconnect() को ट्रिगर करने पर, ब्राउज़र इस डिसकनेक्ट एंडपॉइंट पर, SameSite=None वाली कुकी के साथ क्रॉस-ऑरिजिन POST अनुरोध भेजता है. साथ ही, इस अनुरोध में कॉन्टेंट टाइप के तौर पर application/x-www-form-urlencoded का इस्तेमाल किया जाता है. इस अनुरोध में यह जानकारी शामिल होती है:

प्रॉपर्टी	ब्यौरा
`account_hint`	आईडीपी खाते के लिए एक हिंट..
`client_id`	आरपी का क्लाइंट आइडेंटिफ़ायर.

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

  account_hint=account456&client_id=rp123

अनुरोध मिलने पर, सर्वर को:

सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) की मदद से अनुरोध का जवाब दें.
पुष्टि करें कि अनुरोध में Sec-Fetch-Dest: webidentity एचटीटीपी हेडर शामिल हो.
Origin हेडर को client_id से तय किए गए आरपी ऑरिजिन से मैच करें. अगर वे मैच नहीं करते हैं, तो उन्हें अस्वीकार करें.
account_hint को पहले से साइन इन किए गए खातों के आईडी से मैच करें.
उपयोगकर्ता खाते को आरपी से डिसकनेक्ट करें.
उपयोगकर्ता के खाते की पहचान करने के बाद, ब्राउज़र को JSON फ़ॉर्मैट में जानकारी दें.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://rp.example
Access-Control-Allow-Credentials: true

जवाब के तौर पर मिलने वाले JSON पेलोड का उदाहरण इस तरह दिखता है:

  {
    "account_id": "account456"
  }

इसके बजाय, अगर आईडीपी चाहता है कि ब्राउज़र, RP से जुड़े सभी खातों को डिसकनेक्ट करे, तो कोई ऐसी स्ट्रिंग पास करें जो किसी भी खाता आईडी से मेल न खाती हो. उदाहरण के लिए, "*".

क्लाइंट मेटाडेटा एंडपॉइंट

आईडीपी का क्लाइंट मेटाडेटा एंडपॉइंट, भरोसेमंद पक्ष का मेटाडेटा दिखाता है. जैसे, आरपी की निजता नीति, सेवा की शर्तें, और लोगो आइकॉन. आरपी को आईडीपी को अपनी निजता नीति और सेवा की शर्तों के लिंक पहले से उपलब्ध कराने चाहिए. ये लिंक, साइन-इन डायलॉग में तब दिखते हैं, जब उपयोगकर्ता ने अब तक आईडीपी के साथ आरपी पर रजिस्टर नहीं किया है.

ब्राउज़र, कुकी के बिना client_id navigator.credentials.get का इस्तेमाल करके GET अनुरोध भेजता है. उदाहरण के लिए:

  GET /client_metadata.example?client_id=1234 HTTP/1.1
  Host: accounts.idp.example
  Origin: https://rp.example/
  Accept: application/json
  Sec-Fetch-Dest: webidentity

अनुरोध मिलने पर, सर्वर को:

client_id के लिए आरपी तय करें.
क्लाइंट मेटाडेटा के साथ जवाब दें.

क्लाइंट मेटाडेटा एंडपॉइंट की प्रॉपर्टी में ये शामिल हैं:

प्रॉपर्टी	ब्यौरा
`privacy_policy_url` (वैकल्पिक)	आरपी की निजता नीति का यूआरएल.
`terms_of_service_url` (वैकल्पिक)	आरपी की सेवा की शर्तों का यूआरएल.
`icons` (वैकल्पिक)	ऑब्जेक्ट का कलेक्शन, जैसे कि `[{ "url": "https://rp.example/rp-icon.ico", "size": 40}]`

ब्राउज़र को एंडपॉइंट से JSON रिस्पॉन्स चाहिए:

  {
    "privacy_policy_url": "https://rp.example/privacy_policy.html",
    "terms_of_service_url": "https://rp.example/terms_of_service.html",
    "icons": [{
          "url": "https://rp.example/rp-icon.ico",
          "size": 40
      }]
  }

लौटाए गए क्लाइंट मेटाडेटा का इस्तेमाल ब्राउज़र करता है. यह आरपी के लिए उपलब्ध नहीं होगा.

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

Login Status API की मदद से, आईडीपी को ब्राउज़र को उपयोगकर्ता के लॉगिन स्टेटस की जानकारी देनी होगी. हालांकि, हो सकता है कि स्थिति सिंक न हो. जैसे, सेशन की समयसीमा खत्म होने पर. ऐसे मामले में, ब्राउज़र, idp कॉन्फ़िगरेशन फ़ाइल के login_url में बताए गए लॉगिन पेज के यूआरएल के ज़रिए, उपयोगकर्ता को आईडीपी में डाइनैमिक तौर पर साइन इन करने की अनुमति दे सकता है.

FedCM डायलॉग, साइन इन करने का सुझाव देने वाला मैसेज दिखाता है, जैसा कि नीचे दी गई इमेज में दिखाया गया है.

FedCM का एक डायलॉग, जिसमें आईडीपी (IdP) में साइन इन करने का सुझाव दिया गया है.

जब उपयोगकर्ता जारी रखें बटन पर क्लिक करता है, तो ब्राउज़र, आईडीपी के लॉगिन पेज के लिए एक पॉप-अप विंडो खोलता है.

FedCM डायलॉग का उदाहरण. — आईडीपी (IdP) में साइन इन करने के बटन पर क्लिक करने के बाद दिखने वाले डायलॉग का उदाहरण.

डायलॉग एक सामान्य ब्राउज़र विंडो होती है, जिसमें पहले पक्ष की कुकी होती हैं. डायलॉग बॉक्स में जो भी होता है वह आईडीपी पर निर्भर करता है. साथ ही, आरपी पेज पर क्रॉस-ऑरिजिन कम्यूनिकेशन का अनुरोध करने के लिए, कोई विंडो हैंडल उपलब्ध नहीं होता. उपयोगकर्ता के साइन इन करने के बाद, आईडीपी को:

ब्राउज़र को यह बताने के लिए कि उपयोगकर्ता ने साइन इन कर लिया है, Set-Login: logged-in हेडर भेजें या navigator.login.setStatus("logged-in") एपीआई को कॉल करें.
डायलॉग बॉक्स बंद करने के लिए, IdentityProvider.close() को कॉल करें.

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

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

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

logged-in
logged-out
unknown (डिफ़ॉल्ट)

लॉगिन की स्थिति	जानकारी
`logged-in`	जब उपयोगकर्ता का लॉगिन स्टेटस `logged-in` पर सेट होता है, तो FedCM को कॉल करने वाला आरपी, IdP के खाता एंडपॉइंट से अनुरोध करता है. साथ ही, FedCM डायलॉग में उपयोगकर्ता को उपलब्ध खाते दिखाता है.
`logged-out`	जब उपयोगकर्ता का लॉगिन स्टेटस `logged-out` होता है, तो IdP के खाते के एंडपॉइंट से अनुरोध किए बिना, FedCM को कॉल करने की प्रोसेस बिना किसी सूचना के बंद हो जाती है.
`unknown` (डिफ़ॉल्ट)	IdP, Login Status API का इस्तेमाल करके सिग्नल भेजने से पहले, `unknown` स्टेटस सेट कर देता है. जब स्टेटस `unknown` होता है, तो ब्राउज़र, IdP के खाता एंडपॉइंट से अनुरोध करता है. साथ ही, खाता एंडपॉइंट के जवाब के आधार पर स्टेटस अपडेट करता है.

उपयोगकर्ता के साइन इन होने का सिग्नल देने के लिए, टॉप-लेवल नेविगेशन में Set-Login: logged-in एचटीटीपी हेडर भेजें या IdP ऑरिजिन पर एक ही साइट के सब-रिसॉर्स का अनुरोध करें:

  Set-Login: logged-in

इसके अलावा, टॉप-लेवल नेविगेशन में IdP ऑरिजिन से JavaScript वाले तरीके navigator.login.setStatus('logged-in') को कॉल करें:

  navigator.login.setStatus('logged-in')

उपयोगकर्ता के लॉगिन स्टेटस को logged-in के तौर पर सेट किया जाएगा.

उपयोगकर्ता ने अपने सभी खातों से साइन आउट कर लिया है, यह सिग्नल देने के लिए, टॉप-लेवल नेविगेशन में Set-Login: logged-out एचटीटीपी हेडर भेजें या आईडीपी ऑरिजिन पर, एक ही साइट के सब-रिसॉर्स का अनुरोध करें:

  Set-Login: logged-out

इसके अलावा, टॉप-लेवल नेविगेशन में IdP ऑरिजिन से JavaScript API navigator.login.setStatus('logged-out') को कॉल करें:

  navigator.login.setStatus('logged-out')

उपयोगकर्ता के लॉगिन स्टेटस को logged-out के तौर पर सेट किया जाएगा.

IdP, Login Status API का इस्तेमाल करके सिग्नल भेजने से पहले, unknown स्टेटस सेट कर देता है. ब्राउज़र, आईडीपी के खाता एंडपॉइंट से अनुरोध करता है और खाता एंडपॉइंट के जवाब के आधार पर स्टेटस अपडेट करता है:

अगर एंडपॉइंट, चालू खातों की सूची दिखाता है, तो स्थिति को logged-in पर अपडेट करें. साथ ही, उन खातों को दिखाने के लिए FedCM डायलॉग खोलें.
अगर एंडपॉइंट कोई खाता नहीं दिखाता है, तो स्टेटस को logged-out पर अपडेट करें और FedCM कॉल को फ़ेल करें.

ध्यान दें: Chrome 122 से, लॉगिन स्टेटस हेडर को एक ही साइट के सब-रिसॉर्स से भी भेजा जा सकता है. उदाहरण के लिए, यह तब काम आता है, जब कोई वेबसाइट उपयोगकर्ताओं को idp.example पर अपना उपयोगकर्ता नाम और पासवर्ड डालने की अनुमति देती है, लेकिन क्रेडेंशियल को fetch() के साथ login.idp.example पर पोस्ट किया जाता है. login.idp.example से फ़ेच किए गए रिस्पॉन्स में, Set-Login: logged-in एचटीटीपी हेडर भेजकर, अब भी idp.example के लिए लॉगिन स्टेटस सेट किया जा सकता है.

उपयोगकर्ता को डाइनैमिक लॉगिन फ़्लो की मदद से साइन इन करने की अनुमति दें

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

डाइनैमिक लॉगिन का यह अनुभव तब दिया जाता है, जब आईडीपी सेशन के खत्म होने के बाद भी उपयोगकर्ता साइन-आउट नहीं करता. इस वजह से, ब्राउज़र की लॉगिन स्थिति, उपयोगकर्ता की असल स्थिति से अलग हो जाती है. यह उन उपयोगकर्ताओं के लिए ट्रिगर नहीं होता जिन्होंने अब तक आईडीपी में साइन इन नहीं किया है. इस फ़्लो को उन मामलों को कवर करने के लिए डिज़ाइन किया गया है जहां ब्राउज़र पर उपयोगकर्ता के आईडीपी लॉगिन का स्टेटस logged-in है, लेकिन आईडीपी का खाता एंडपॉइंट कोई खाता नहीं दिखाता. मान लें कि Login Status API को तुरंत कॉल किया जाता है. ऐसे में, FedCM को ट्रिगर करने पर, इनमें से कोई भी स्थिति हो सकती है:

अगर उपयोगकर्ता के लॉगिन स्टेटस को'जानकारी नहीं है' पर सेट किया गया है, तो खाते के एंडपॉइंट से मिले आईडीपी के रिस्पॉन्स के आधार पर, स्टेटस को अपडेट किया जाता है (logged-in या logged-out). डाइनैमिक लॉगिन फ़्लो ट्रिगर नहीं होगा.
अगर किसी उपयोगकर्ता ने ब्राउज़र में आईडीपी (IdP) में साइन इन करने के बाद, साफ़ तौर पर आईडीपी से साइन आउट किया है, तो डाइनैमिक लॉगिन फ़्लो ट्रिगर नहीं होगा.
अगर किसी उपयोगकर्ता ने ब्राउज़र में IdP में साइन इन किया है, लेकिन logged-out को साफ़ तौर पर अपडेट किए बिना सेशन की समयसीमा खत्म हो जाती है, तो डाइनैमिक लॉगिन फ़्लो ट्रिगर हो जाता है.

लॉगिन स्टेटस एपीआई, आरपी को "आईडीपी में साइन इन करें" डायलॉग दिखाने की सुविधा नहीं देता. यह सुविधा सिर्फ़ उन उपयोगकर्ताओं को दिखती है जो आईडीपी में साइन इन नहीं हैं. यह एक अलग सुविधा है, जिसे आने वाले समय में जोड़ा जा सकता है.

FedCM को आरपी के तौर पर लागू करना

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

एपीआई को कॉल करने से पहले, आपको यह पुष्टि करनी होगी कि FedCM, उपयोगकर्ता के ब्राउज़र पर उपलब्ध है. यह देखने के लिए कि FedCM उपलब्ध है या नहीं, अपने FedCM लागू करने के तरीके के आस-पास यह कोड डालें:

  if ('IdentityCredential' in window) {
    // If the feature is available, take action
  } else {
    // FedCM is not supported, use a different identity solution
  }

उपयोगकर्ताओं को FedCM का इस्तेमाल करके, आरपी पर आईडीपी में साइन इन करने की अनुमति देने के लिए, आरपी navigator.credentials.get() को कॉल कर सकता है. उदाहरण के लिए:

  const credential = await navigator.credentials.get({
    identity: {
      context: 'signin',
      providers: [{
        configURL: 'https://accounts.idp.example/config.json',
        clientId: '********',
        mode: 'active',
        params: {
          nonce: '******'
        }
      }]
    }
  });
  const { token } = credential;

कॉन्टेक्स्ट प्रॉपर्टी

context प्रॉपर्टी का इस्तेमाल करके, आरपी, FedCM डायलॉग यूज़र इंटरफ़ेस (यूआई) में स्ट्रिंग में बदलाव कर सकता है. उदाहरण के लिए, "rp.example में साइन इन करें…", "idp.example का इस्तेमाल करें…". ऐसा, पहले से तय किए गए पुष्टि के संदर्भों को शामिल करने के लिए किया जा सकता है. context प्रॉपर्टी में ये वैल्यू हो सकती हैं:

signin (डिफ़ॉल्ट)
signup
use

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

उदाहरण के लिए, context को use पर सेट करने पर, आपको यह मैसेज दिखेगा:

FedCM डायलॉग बॉक्स, जिसमें उपयोगकर्ता के हिसाब से कॉन्टेक्स्ट मैसेज दिखाया गया है: FedCM के साथ 'साइन इन करें' के बजाय, कॉन्टेक्स्ट मैसेज में FedCM का 'इस्तेमाल करें' लिखा है. — FedCM डायलॉग, जिसमें उपयोगकर्ता के हिसाब से बनाया गया मैसेज दिख रहा है.

ब्राउज़र, साइन-अप और साइन-इन के इस्तेमाल के उदाहरणों को अलग-अलग तरीके से हैंडल करता है. यह इस बात पर निर्भर करता है कि खातों की सूची के एंडपॉइंट से मिले रिस्पॉन्स में approved_clients मौजूद है या नहीं. अगर उपयोगकर्ता ने पहले ही आरपी के लिए साइन अप कर लिया है, तो ब्राउज़र, ".... जारी रखने के लिए" टेक्स्ट नहीं दिखाएगा.
providers प्रॉपर्टी में IdentityProvider ऑब्जेक्ट का कलेक्शन होता है. इनमें ये प्रॉपर्टी होती हैं:

सेवा देने वाली कंपनियों की प्रॉपर्टी

providers प्रॉपर्टी में IdentityProvider ऑब्जेक्ट का कलेक्शन होता है. इन ऑब्जेक्ट में ये प्रॉपर्टी होती हैं:

प्रॉपर्टी	ब्यौरा
`configURL` (ज़रूरी)	आईडीपी कॉन्फ़िगरेशन फ़ाइल का पूरा पाथ.
`clientId` (ज़रूरी)	आईडीपी से जारी किया गया आरपी का क्लाइंट आइडेंटिफ़ायर.
`nonce` (वैकल्पिक)	यह एक रैंडम स्ट्रिंग होती है, ताकि यह पक्का किया जा सके कि जवाब इस खास अनुरोध के लिए जारी किया गया है. जवाबी हमलों को रोकता है.
`loginHint` (वैकल्पिक)	खाते के एंडपॉइंट से दी गई `login_hints` वैल्यू में से किसी एक को चुनकर, FedCM डायलॉग चुनिंदा खाता दिखाता है.
`domainHint` (वैकल्पिक)	खाते के एंडपॉइंट से दी गई `domain_hints` वैल्यू में से किसी एक को चुनकर, FedCM डायलॉग चुनिंदा खाता दिखाता है.
`mode` (वैकल्पिक)	FedCM के यूज़र इंटरफ़ेस (यूआई) मोड के बारे में बताने वाली स्ट्रिंग. यह इनमें से कोई एक वैल्यू हो सकती है: `"active"`: FedCM प्रॉम्प्ट, उपयोगकर्ता के इंटरैक्शन (जैसे, बटन पर क्लिक करना) से शुरू होना चाहिए. `"passive"`: FedCM प्रॉम्प्ट, उपयोगकर्ता के सीधे इंटरैक्शन के बिना शुरू किया जाएगा. ऐक्टिव और पैसिव मोड के बीच के अंतर के बारे में ज़्यादा जानने के लिए, खास जानकारी वाला पेज देखें. ध्यान दें: `mode` पैरामीटर, Chrome 132 से काम करता है.
`fields` (वैकल्पिक)	स्ट्रिंग का कलेक्शन, जिसमें उपयोगकर्ता की वह जानकारी होती है ("name", " email", "picture") जिसे आरपी को आईडीपी से शेयर करना होता है. ध्यान दें: फ़ील्ड एपीआई, Chrome 132 और इसके बाद के वर्शन पर काम करता है.
`parameters` (वैकल्पिक)	कस्टम ऑब्जेक्ट, जो अन्य की-वैल्यू पैरामीटर तय करने की अनुमति देता है: `scope`: स्ट्रिंग वैल्यू, जिसमें अतिरिक्त अनुमतियां होती हैं. आरपी को इन अनुमतियों का अनुरोध करना होता है. उदाहरण के लिए, `"drive.readonly calendar.readonly"` `nonce`: यह एक रैंडम स्ट्रिंग होती है. इससे यह पक्का किया जाता है कि जवाब, इस खास अनुरोध के लिए जारी किया गया है. जवाबी हमलों को रोकता है. अन्य कस्टम की-वैल्यू पैरामीटर. ध्यान दें: `parameters`, Chrome 132 से काम करता है.

ऐक्टिव मोड

FedCM, अलग-अलग यूज़र एक्सपीरियंस मोड कॉन्फ़िगरेशन के साथ काम करता है. पैसिव मोड, डिफ़ॉल्ट मोड होता है. डेवलपर को इसे कॉन्फ़िगर करने की ज़रूरत नहीं होती.

ऐक्टिव मोड में FedCM का इस्तेमाल करने के लिए:

उपयोगकर्ता के ब्राउज़र में सुविधा की उपलब्धता देखें.
बटन पर क्लिक करने जैसे उपयोगकर्ता के किसी जेस्चर से, एपीआई को ट्रिगर करें.
एपीआई कॉल में mode पैरामीटर पास करें:

  let supportsFedCmMode = false;
  try {
    navigator.credentials.get({
      identity: Object.defineProperty(
        // Check if this Chrome version supports the Mode API.
        {}, 'mode', {
          get: function () { supportsFedCmMode = true; }
        }
      )
    });
  } catch(e) {}

  if (supportsFedCmMode) {
    // The button mode is supported. Call the API with mode property:
    return await navigator.credentials.get({
      identity: {
        providers: [{
          configURL: 'https://idp.example/config.json',
          clientId: '123',
        }],
        // The 'mode' value defines the UX mode of FedCM.
        // - 'active': Must be initiated by user interaction (e.g., clicking a button).
        // - 'passive': Can be initiated without direct user interaction.
        mode: 'active'
      }
    });
  }

ऐक्टिव मोड में पसंद के मुताबिक आइकॉन

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

क्रॉस-ओरिजिन iframe से FedCM को कॉल करना

अगर पैरंट फ़्रेम अनुमति देता है, तो identity-credentials-get अनुमतियों की नीति का इस्तेमाल करके, क्रॉस-ऑरिजिन iframe में से FedCM को शुरू किया जा सकता है. ऐसा करने के लिए, iframe टैग में allow="identity-credentials-get" एट्रिब्यूट को इस तरह जोड़ें:

  <iframe src="https://fedcm-cross-origin-iframe.glitch.me" allow="identity-credentials-get"></iframe>

इसे उदाहरण में देखा जा सकता है.

इसके अलावा, अगर पैरंट फ़्रेम को FedCM को कॉल करने के लिए ऑरिजिन पर पाबंदी लगानी है, तो अनुमति वाले ऑरिजिन की सूची के साथ Permissions-Policy हेडर भेजें.

  Permissions-Policy: identity-credentials-get=(self "https://fedcm-cross-origin-iframe.glitch.me")

अनुमतियों की नीति के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, अनुमतियों की नीति की मदद से ब्राउज़र की सुविधाओं को कंट्रोल करना लेख पढ़ें.

लॉगिन करने के लिए दिए गए सुझाव का इस्तेमाल करके, आरपी यह सुझाव दे सकता है कि उपयोगकर्ता को किस खाते से साइन इन करना चाहिए. यह उन उपयोगकर्ताओं के लिए पुष्टि करने में मददगार हो सकता है जिन्हें यह याद नहीं है कि उन्होंने पहले किस खाते का इस्तेमाल किया था.

आरपी, loginHint प्रॉपर्टी के साथ navigator.credentials.get() को ट्रिगर करके, किसी खास खाते को चुनिंदा तौर पर दिखा सकते हैं. इसके लिए, खातों की सूची वाले एंडपॉइंट से फ़ेच की गई login_hints वैल्यू में से किसी एक का इस्तेमाल किया जाता है. इस बारे में नीचे दिए गए कोड सैंपल में बताया गया है:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/manifest.json',
        clientId: '123',
        // Accounts endpoint can specify a 'login_hints' array for an account.
        // When RP specifies a 'exampleHint' value, only those accounts will be
        // shown to the user whose 'login_hints' array contains the 'exampleHint'
        // value
        loginHint : 'exampleHint'
      }]
    }
  });

अगर कोई भी खाता loginHint से मेल नहीं खाता है, तो FedCM डायलॉग बॉक्स में उपयोगकर्ता को लॉगिन करने के लिए कहा जाता है. इससे उपयोगकर्ता, आरपी के अनुरोध किए गए हिंट से मैच करने वाले आईडीपी खाते में लॉगिन कर सकता है. जब उपयोगकर्ता प्रॉम्प्ट पर टैप करता है, तो config फ़ाइल में बताए गए लॉगिन यूआरएल के साथ एक पॉप-अप विंडो खुलती है. इसके बाद, लिंक में लॉगिन के लिए दिए गए हिंट और डोमेन के लिए दिए गए हिंट के क्वेरी पैरामीटर जोड़ दिए जाते हैं.

Domain Hint API

आरपी, सिर्फ़ किसी खास डोमेन से जुड़े खातों को चुनिंदा तौर पर दिखा सकते हैं. यह उन आरपी के लिए फ़ायदेमंद हो सकता है जो किसी कॉर्पोरेट डोमेन तक ही सीमित हैं.

सिर्फ़ खास डोमेन खाते दिखाने के लिए, आरपी को navigator.credentials.get() को domainHint प्रॉपर्टी के साथ कॉल करना चाहिए. इसके लिए, domain_hints की वैल्यू में से किसी एक को खातों की सूची वाले एंडपॉइंट से फ़ेच किया जाना चाहिए. इसका उदाहरण नीचे दिए गए कोड सैंपल में दिया गया है:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/manifest.json',
        clientId: 'abc',
        // Accounts endpoint can specify a 'domain_hints' array for an account.
        // When RP specifies a '@domain.example' value, only those accounts will be
        // shown to the user whose 'domain_hints' array contains the
        // '@domain.example' value
        domainHint : '@domain.example'
      }]
    }
  });

ध्यान दें: domainHint: 'any' का इस्तेमाल करने पर, Chrome उन खातों को फ़िल्टर कर देता है जिनमें कोई डोमेन नहीं है. इसका मतलब है कि domain_hints को पास नहीं किया गया है या वह खाली है. उदाहरण के लिए, इसकी मदद से ऐसे इस्तेमाल के उदाहरणों को अनुमति मिलती है जहां आरपी, साइनअप की प्रोसेस में सिर्फ़ मैनेज किए जा रहे खातों को अनुमति देता है.

अगर कोई भी खाता domainHint से मेल नहीं खाता है, तो FedCM डायलॉग बॉक्स में उपयोगकर्ता को लॉगिन करने के लिए कहा जाता है. इससे उपयोगकर्ता, आरपी के अनुरोध किए गए हिंट से मैच करने वाले आईडीपी खाते में लॉगिन कर सकता है. जब उपयोगकर्ता प्रॉम्प्ट पर टैप करता है, तो config फ़ाइल में बताए गए लॉगिन यूआरएल के साथ एक पॉप-अप विंडो खुलती है. इसके बाद, लिंक में लॉगिन के लिए दिए गए हिंट और डोमेन के लिए दिए गए हिंट के क्वेरी पैरामीटर जोड़ दिए जाते हैं.

जब कोई भी खाता, domainHint से मेल न खाता हो, तब लॉगिन करने के लिए प्रॉम्प्ट का उदाहरण. — `domainHint` से मैच करने वाला कोई खाता न होने पर, लॉगिन प्रॉम्प्ट का उदाहरण

कस्टम पैरामीटर

कस्टम पैरामीटर की सुविधा की मदद से, आरपी आईडी एश्योरेशन एंडपॉइंट को अतिरिक्त की-वैल्यू पैरामीटर दे सकता है. Parameters API की मदद से, आरपी, IdP को अतिरिक्त पैरामीटर भेज सकते हैं. इससे, वे बुनियादी साइन इन के अलावा, संसाधनों के लिए अनुमतियों का अनुरोध कर सकते हैं. अतिरिक्त पैरामीटर पास करने से, इन स्थितियों में मदद मिल सकती है:

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

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

ब्राउज़र, इसे अपने-आप IdP के लिए POST अनुरोध में बदल देगा. इसमें पैरामीटर, यूआरएल से कोड में बदले गए JSON-सीरियलाइज़ किए गए ऑब्जेक्ट के तौर पर होंगे:

  // The assertion endpoint is drawn from the config file
  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

  // params are translated into urlencoded version of `{"IDP_SPECIFIC_PARAM":"1","foo":"bar"}`
  account_id=123&client_id=client1234&params=%22%7B%5C%22IDP_SPECIFIC_PARAM%5C%22%3A1%2C%5C%22foo%5C%22%3A%5C%22BAR%5C%22%7D%22.

अगर आरपी को किसी और अनुमति की ज़रूरत है, तो आईडीपी उसे रीडायरेक्ट करने वाला लिंक दे सकता है. उदाहरण के लिए, node.js में:

  if (rpRequestsPermissions) {
    // Response with a URL if the RP requests additional permissions
    return res.json({
      continue_on: '/example-redirect',
    });
  }

फ़ील्ड

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

FedCM के चालू मोड का डायलॉग बॉक्स, जिसमें जानकारी ज़ाहिर करने का मैसेज दिख रहा है. जारी रखने के लिए, पहचान की पुष्टि करने वाली सेवा, वेबसाइट के साथ उपयोगकर्ता का ईमेल पता और प्रोफ़ाइल फ़ोटो शेयर करेगी. — ऐक्टिव मोड में जानकारी ज़ाहिर करने वाला मैसेज: आरपी, आईडीपी से सिर्फ़ उपयोगकर्ता का ईमेल पता और प्रोफ़ाइल फ़ोटो शेयर करने का अनुरोध करता है.

फ़ील्ड की सुविधा का इस्तेमाल करने के लिए, आरपी को navigator.credentials.get() कॉल में fields कलेक्शन जोड़ना चाहिए. फ़ील्ड में name, email, और picture के किसी भी क्रम का इस्तेमाल किया जा सकता है. आने वाले समय में, इसमें और वैल्यू शामिल की जा सकती हैं. fields वाला अनुरोध कुछ ऐसा दिखेगा:

  let { token } = await navigator.credentials.get({
    identity: {
      providers: [{
        // RP requests the IdP to share only user email and profile picture
        fields: [ 'email', 'picture'],
        clientId: '1234',
        configURL: 'https://idp.example/fedcm.json',

      },
    }
  });

ब्राउज़र, इसे अपने-आप आईडी एश्योरेंस एंडपॉइंट पर एचटीटीपी अनुरोध में बदल देगा. इसमें आरपी के तय किए गए fields पैरामीटर के साथ-साथ वे फ़ील्ड शामिल होंगे जिन्हें ब्राउज़र ने disclosure_shown_for पैरामीटर में उपयोगकर्ता को दिखाया था. पुराने वर्शन के साथ काम करने के लिए, ब्राउज़र disclosure_text_shown=true भी भेजेगा. ऐसा तब होगा, जब जानकारी ज़ाहिर करने वाला टेक्स्ट दिखाया गया हो और अनुरोध किए गए फ़ील्ड में तीनों फ़ील्ड शामिल हों: 'name', 'email', और 'picture'.

  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

  // The RP only requested to share email and picture. The browser will send `disclosure_text_shown=false`, as the 'name' field value is missing
  account_id=123&client_id=client1234&disclosure_text_shown=false&fields=email,picture&disclosure_shown_for=email,picture

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

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

ऐसा तब भी होता है, जब accounts endpoint के रिस्पॉन्स में ऐसा क्लाइंट आईडी न हो जो 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

गड़बड़ी का मैसेज दिखाना

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

FedCM डायलॉग, जिसमें उपयोगकर्ता के साइन इन करने की कोशिश के विफल होने के बाद, गड़बड़ी का मैसेज दिख रहा है. यह स्ट्रिंग, गड़बड़ी के टाइप से जुड़ी होती है.

  try {
    const cred = await navigator.credentials.get({
      identity: {
        providers: [
          {
            configURL: 'https://idp.example/manifest.json',
            clientId: '1234',
          },
        ],
      }
    });
  } catch (e) {
    const code = e.code;
    const url = e.url;
  }

शुरुआती पुष्टि के बाद, उपयोगकर्ताओं की पुष्टि अपने-आप हो जाए

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

उपयोगकर्ता के लिए साफ़ तौर पर जानकारी देने की सुविधा, ट्रैकिंग को रोकने के लिए फ़ेडरेटेड खाता बनाने से पहले काम की होती है. यह FedCM के मुख्य लक्ष्यों में से एक है. हालांकि, उपयोगकर्ता के एक बार जानकारी देने के बाद, यह सुविधा ज़रूरत से ज़्यादा परेशानी वाली हो जाती है: उपयोगकर्ता के आरपी और आईडीपी के बीच कम्यूनिकेशन की अनुमति देने के बाद, किसी ऐसी जानकारी के लिए साफ़ तौर पर फिर से पुष्टि करने की ज़रूरत नहीं होती जिसकी पुष्टि उपयोगकर्ता ने पहले ही कर दी है. इससे निजता या सुरक्षा को कोई फ़ायदा नहीं मिलता.

अपने-आप फिर से पुष्टि करने की सुविधा की मदद से, ब्राउज़र अपने व्यवहार में बदलाव करता है. यह बदलाव, navigator.credentials.get() को कॉल करते समय mediation के लिए बताए गए विकल्प के आधार पर होता है.

  const cred = await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/fedcm.json',
        clientId: '1234',
      }],
    },
    mediation: 'optional', // this is the default
  });

  // `isAutoSelected` is `true` if auto-reauthn was performed.
  const isAutoSelected = cred.isAutoSelected;

mediation, Credential Management API में मौजूद एक प्रॉपर्टी है. यह PasswordCredential और FederatedCredential के लिए ठीक उसी तरह काम करती है जिस तरह यह PublicKeyCredential के लिए काम करती है. हालांकि, यह PublicKeyCredential के साथ कुछ हद तक ही काम करती है. प्रॉपर्टी में ये चार वैल्यू इस्तेमाल की जा सकती हैं:

'optional'(डिफ़ॉल्ट): अगर मुमकिन हो, तो अपने-आप फिर से पुष्टि करने की सुविधा चालू करें. अगर ऐसा नहीं है, तो मीडिएशन की ज़रूरत होगी. हमारा सुझाव है कि आप साइन-इन पेज पर यह विकल्प चुनें.
'required': आगे बढ़ने के लिए, हमेशा मीडिएशन की ज़रूरत होती है. उदाहरण के लिए, यूज़र इंटरफ़ेस (यूआई) पर "जारी रखें" बटन पर क्लिक करना. यह विकल्प तब चुनें, जब आपके उपयोगकर्ताओं को हर बार पुष्टि कराने के लिए, साफ़ तौर पर अनुमति देनी पड़े.
'silent': अगर हो सके, तो अपने-आप फिर से पुष्टि होने की सुविधा चालू करें. अगर ऐसा नहीं हो पाता है, तो बिना किसी मध्यस्थता के चुपचाप पुष्टि न हो. हमारा सुझाव है कि इस विकल्प को साइन इन करने के लिए बने पेज के अलावा, उन पेजों पर चुनें जहां आपको उपयोगकर्ताओं को साइन इन रखना है. उदाहरण के लिए, शिपिंग वेबसाइट पर आइटम पेज या समाचार वेबसाइट पर लेख पेज.
'conditional': इसका इस्तेमाल WebAuthn के लिए किया जाता है. फ़िलहाल, यह FedCM के लिए उपलब्ध नहीं है.

इस कॉल के साथ, अपने-आप फिर से पुष्टि करने की सुविधा इन स्थितियों में होती है:

FedCM का इस्तेमाल किया जा सकता है. उदाहरण के लिए, उपयोगकर्ता ने सेटिंग में जाकर, FedCM को पूरी तरह से बंद नहीं किया है या आरपी के लिए बंद नहीं किया है.
उपयोगकर्ता ने इस ब्राउज़र पर वेबसाइट में साइन इन करने के लिए, FedCM API के साथ सिर्फ़ एक खाते का इस्तेमाल किया है.
उपयोगकर्ता ने उस खाते से आईडीपी में साइन इन किया हो.
पिछले 10 मिनट में, अपने-आप फिर से पुष्टि नहीं हुई.
पिछले साइन इन के बाद, आरपी ने navigator.credentials.preventSilentAccess() को कॉल नहीं किया है.

इन शर्तों के पूरा होने पर, FedCM navigator.credentials.get() का इस्तेमाल करने के बाद, उपयोगकर्ता की पुष्टि अपने-आप होने की प्रोसेस शुरू हो जाती है.

mediation: optional के लिए, अपने-आप फिर से पुष्टि करने की सुविधा उपलब्ध न हो सकती. ऐसा उन वजहों से हो सकता है जिनके बारे में सिर्फ़ ब्राउज़र को पता होता है. आरपी, isAutoSelected प्रॉपर्टी की जांच करके यह पता लगा सकता है कि अपने-आप फिर से पुष्टि करने की सुविधा चालू है या नहीं.

इससे एपीआई की परफ़ॉर्मेंस का आकलन करने और यूज़र एक्सपीरियंस को बेहतर बनाने में मदद मिलती है. साथ ही, अगर यह उपलब्ध नहीं है, तो उपयोगकर्ता को साफ़ तौर पर उपयोगकर्ता मध्यस्थता के साथ साइन इन करने के लिए कहा जा सकता है. यह mediation: required वाला फ़्लो है.

FedCM की मदद से, उपयोगकर्ता अपने-आप फिर से पुष्टि कर रहा है.

`preventSilentAccess()` की मदद से मीडिएशन लागू करना

उपयोगकर्ताओं के साइन आउट करने के तुरंत बाद, अपने-आप पुष्टि करने की सुविधा से, उपयोगकर्ता अनुभव बेहतर नहीं होगा. इसलिए, FedCM में अपने-आप फिर से पुष्टि होने के बाद, 10 मिनट के लिए कोई गतिविधि नहीं होती, ताकि इस तरह की गतिविधि को रोका जा सके. इसका मतलब है कि अपने-आप फिर से पुष्टि करने की सुविधा, ज़्यादा से ज़्यादा हर 10 मिनट में एक बार होती है. हालांकि, अगर उपयोगकर्ता 10 मिनट के अंदर साइन इन करता है, तो ऐसा नहीं होता. जब कोई उपयोगकर्ता आरपी से साइन आउट करता है, तो आरपी को navigator.credentials.preventSilentAccess() को कॉल करके, ब्राउज़र से अपने-आप फिर से पुष्टि करने की सुविधा को बंद करने का अनुरोध करना चाहिए. उदाहरण के लिए, साइन आउट बटन पर क्लिक करके.

  function signout() {
    navigator.credentials.preventSilentAccess();
    location.href = '/signout';
  }

उपयोगकर्ता, सेटिंग में जाकर अपने-आप फिर से पुष्टि होने की सुविधा से ऑप्ट-आउट कर सकते हैं

उपयोगकर्ता, सेटिंग मेन्यू में जाकर, अपने-आप फिर से पुष्टि होने की सुविधा से ऑप्ट-आउट कर सकते हैं:

डेस्कटॉप पर Chrome में, chrome://password-manager/settings > अपने-आप साइन इन करें पर जाएं.
Android के Chrome पर, सेटिंग > Password Manager खोलें > सबसे ऊपर दाएं कोने में मौजूद ऐप्लिकेशन आइकॉन पर टैप करें > अपने-आप साइन इन करें पर टैप करें.

टॉगल बंद करके, उपयोगकर्ता अपने-आप फिर से पुष्टि करने की सुविधा से पूरी तरह ऑप्ट-आउट कर सकता है. अगर उपयोगकर्ता ने Chrome इंस्टेंस पर Google खाते में साइन इन किया हुआ है और सिंक करने की सुविधा चालू है, तो यह सेटिंग सभी डिवाइसों पर सेव और सिंक की जाती है.

आईडीपी को आरपी से डिसकनेक्ट करना

अगर किसी उपयोगकर्ता ने पहले FedCM के ज़रिए IdP का इस्तेमाल करके RP में साइन इन किया है, तो ब्राउज़र, कनेक्ट किए गए खातों की सूची के तौर पर, इस संबंध को स्थानीय तौर पर सेव कर लेता है. आरपी, IdentityCredential.disconnect() फ़ंक्शन को शुरू करके डिसकनेक्ट कर सकता है. इस फ़ंक्शन को टॉप-लेवल आरपी फ़्रेम से कॉल किया जा सकता है. आरपी को configURL पास करना होगा, जो आईडीपी के तहत इस्तेमाल किया जाने वाला clientId है. साथ ही, आईडीपी को डिसकनेक्ट करने के लिए accountHint भी पास करना होगा. खाते के बारे में जानकारी देने वाली स्ट्रिंग, कोई भी हो सकती है. हालांकि, यह ज़रूरी है कि खाते को अनलिंक करने वाला एंडपॉइंट, खाते की पहचान कर सके. उदाहरण के लिए, कोई ईमेल पता या उपयोगकर्ता आईडी, जो ज़रूरी नहीं है कि खाता सूची वाले एंडपॉइंट से मिले खाता आईडी से मेल खाए:

  // Disconnect an IdP account 'account456' from the RP 'https://idp.com/'. This is invoked on the RP domain.
  IdentityCredential.disconnect({
    configURL: 'https://idp.com/config.json',
    clientId: 'rp123',
    accountHint: 'account456'
  });

IdentityCredential.disconnect(), Promise दिखाता है. इस वादे की वजह से, इन वजहों से अपवाद दिख सकता है:

उपयोगकर्ता ने FedCM के ज़रिए IdP का इस्तेमाल करके, आरपी में साइन इन नहीं किया है.
एपीआई को iframe में से कॉल किया जाता है. इसके लिए, FedCM की अनुमतियों की नीति का इस्तेमाल नहीं किया जाता.
configURL अमान्य है या डिसकनेक्ट एंडपॉइंट मौजूद नहीं है.
कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी) की जांच पूरी नहीं हो पाती.
खाता बंद करने का अनुरोध स्वीकार नहीं किया गया है.
उपयोगकर्ता ने ब्राउज़र की सेटिंग में जाकर, FedCM को बंद कर दिया हो.

जब IdP का डिसकनेक्ट एंडपॉइंट कोई जवाब देता है, तो ब्राउज़र पर RP और IdP डिसकनेक्ट हो जाते हैं और वादा पूरा हो जाता है. डिसकनेक्ट किए गए खातों के आईडी, disconnect एंडपॉइंट से मिले रिस्पॉन्स में दिए गए होते हैं.

FedCM की मदद से आइडेंटिटी सलूशन लागू करना

FedCM को आईडीपी (IdP) के तौर पर लागू करना

.well-known फ़ाइल बनाना

आईडीपी कॉन्फ़िगरेशन फ़ाइल और एंडपॉइंट बनाना

किसी दूसरे खाते का इस्तेमाल करना

खातों का एंडपॉइंट

आईडी एश्योरेशन एंडपॉइंट

'जारी रखें' सुविधा

गड़बड़ी का जवाब देना

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

एंडपॉइंट को डिसकनेक्ट करना

क्लाइंट मेटाडेटा एंडपॉइंट

लॉगिन यूआरएल

उपयोगकर्ता के लॉगिन स्टेटस के बारे में ब्राउज़र को बताना

उपयोगकर्ता को डाइनैमिक लॉगिन फ़्लो की मदद से साइन इन करने की अनुमति दें

FedCM को आरपी के तौर पर लागू करना

कॉन्टेक्स्ट प्रॉपर्टी

सेवा देने वाली कंपनियों की प्रॉपर्टी

ऐक्टिव मोड

ऐक्टिव मोड में पसंद के मुताबिक आइकॉन

क्रॉस-ओरिजिन iframe से FedCM को कॉल करना

Login Hint API

Domain Hint API

कस्टम पैरामीटर

फ़ील्ड

गड़बड़ी का मैसेज दिखाना

शुरुआती पुष्टि के बाद, उपयोगकर्ताओं की पुष्टि अपने-आप हो जाए

preventSilentAccess() की मदद से मीडिएशन लागू करना

उपयोगकर्ता, सेटिंग में जाकर अपने-आप फिर से पुष्टि होने की सुविधा से ऑप्ट-आउट कर सकते हैं

आईडीपी को आरपी से डिसकनेक्ट करना

`preventSilentAccess()` की मदद से मीडिएशन लागू करना