आइडेंटिटी प्रोवाइडर की ओर से, FedCM के साथ आइडेंटिटी सलूशन लागू करना

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

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

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

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

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

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

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

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

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

• IdP को अलग-अलग टेस्ट और प्रोडक्शन कॉन्फ़िगरेशन के साथ काम करना चाहिए.
• आईडीपी (IdP) को हर क्षेत्र के हिसाब से अलग-अलग कॉन्फ़िगरेशन (उदाहरण के लिए, 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"
  }

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

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

कॉन्फ़िगरेशन फ़ाइल का यूआरएल, navigator.credentials.get() कॉल को दी गई वैल्यू से तय होता है. यह कॉल, आरपी पर एक्ज़ीक्यूट होता है. आरपी, हर आइडेंटिटी प्रोवाइडर के लिए कॉन्फ़िगरेशन फ़ाइल का यूआरएल पास करेगा:

  // Executed on RP's side:
  try {
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // To allow users to sign in with the IdP1 using FedCM, RP specifies the IdP's config file URL:
            configUrl: 'https://idp1.example/foo.json', // first IdP
            clientId: '123',
          },
          // To allow users to sign in with the IdP2 using FedCM, RP specifies the IdP's config file URL.
          // Note that multiple IdPs in a single get() are supported from Chrome 136.
          {
            configUrl: 'https://idp2.example/bar.json', // second IdP
            clientId: '456',
          },
        ],
      },
    });

    const token = credential.token;
    // Get the current IdP's configURL to identify which provider the user is signed in with
    const currentIdpConfigUrl = credential.configURL;
    if (currentIdpConfigUrl === 'https://idp1.example/foo.json') {
      // handle the case where the user signed in with idp1
    } else if (currentIdpConfigUrl === 'https://idp2.example/bar.json') {
      // handle the case where the user signed in with idp2
    }
  } catch (error) {
    // handle error
  }

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

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

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

यहां IdP से मिले जवाब के मुख्य हिस्से का एक उदाहरण दिया गया है:

  {
    "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.
    "account_label": "developer",
    "supports_use_other_account": true,
    "branding": {
      "background_color": "green",
      "color": "#FFEEAA",
      "icons": [{
        "url": "https://idp.example/icon.ico",
        "size": 25
      }]
    }
  }

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

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

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

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

  {
    "accounts_endpoint" : "/accounts.example",
    "supports_use_other_account": true
  }

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

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

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

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

अनुरोध मिलने पर, सर्वर को यह काम करना चाहिए:

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

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

जवाब के मुख्य हिस्से का उदाहरण:

  {
    "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.
      "label_hints": ["enterprise", "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 (अनुमति नहीं है) के साथ जवाब दें.

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

आईडी असर्शन एंडपॉइंट

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

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

  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&fields=email,picture&disclosure_shown_for=email,picture

अनुरोध मिलने पर, सर्वर को यह काम करना चाहिए:

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

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

ब्राउज़र को ऐसे JSON रिस्पॉन्स की ज़रूरत होती है जिसमें यह प्रॉपर्टी शामिल हो:

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

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

इस सुविधा का इस्तेमाल जारी रखें

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

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

आईडी असर्शन एंडपॉइंट, 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);
  });

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

  IdentityProvider.close();

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

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

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

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

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

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

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

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

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

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

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

मान लें कि कोई IdP, "developer" और "hr" खातों के बीच अंतर करना चाहता है. इसके लिए, आईडीपी को "developer" और "hr" के लिए दो configURL इस्तेमाल करने की सुविधा देनी होगी:

• डेवलपर कॉन्फ़िगरेशन फ़ाइल 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",
    "account_label": "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",
    "account_label": "hr"
  }

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

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

• इस उदाहरण में, सामान्य IdP accounts endpoint (https://idp.example/accounts) खातों की एक सूची दिखाता है. इसमें हर खाते के लिए, असाइन किए गए लेबल वाली label_hints प्रॉपर्टी, ऐरे में शामिल होती है:

  {
  "accounts": [{
    "id": "123",
    "given_name": "John",
    "name": "John Doe",
    "email": "john_doe@idp.example",
    "picture": "https://idp.example/profile/123",
    "label_hints": ["developer"]
    }], [{
    "id": "4567",
    "given_name": "Jane",
    "name": "Jane Doe",
    "email": "jane_doe@idp.example",
    "picture": "https://idp.example/profile/4567",
    "label_hints": ["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 के खाते के आईडी को चुपचाप छिपा देता है, ताकि उपयोगकर्ता को ऐसा खाता न मिले जिसे इस साइट पर आईडीपी (IdP) इस्तेमाल करने की अनुमति नहीं है.

इन बातों पर भी गौर करें:

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

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

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

  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

अनुरोध मिलने पर, सर्वर को यह काम करना चाहिए:

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

जवाब के तौर पर मिले JSON पेलोड का उदाहरण यहां दिया गया है:

  {
    "account_id": "account456"
  }

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

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

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

ब्राउज़र, कुकी के बिना 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

अनुरोध मिलने पर, सर्वर को यह काम करना चाहिए:

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

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

ब्राउज़र को एंडपॉइंट से 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
      }]
  }

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

लॉगिन यूआरएल

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

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

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

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

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

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

यह कुकी, ब्राउज़र को उपयोगकर्ता के लॉगिन स्टेटस के बारे में सूचना देती है

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

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

• logged-in
• logged-out
• unknown (डिफ़ॉल्ट)

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

  Set-Login: logged-in

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

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

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

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

  Set-Login: logged-out

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

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

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

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

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

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

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

आगे क्या करना होगा

आरपी की ओर से FedCM लागू करना

अपने आरपी के लिए FedCM लागू करें और JavaScript SDK टूल को डिस्ट्रिब्यूट करें. आरपी को अप-टू-डेट रखें. इसके लिए, उन्हें खुद लागू करने की ज़रूरत नहीं है.

सेट अप करना और डीबग करना

अपना एनवायरमेंट सेटअप करने और लागू करने के तरीके को डीबग करने का तरीका जानें.