फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट एपीआई की डेवलपर गाइड

निजता बनाए रखने के लिए आइडेंटिटी फ़ेडरेशन की सुविधा के लिए, FedCM का इस्तेमाल करने का तरीका जानें.

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

FedCM के इस्तेमाल के उदाहरणों, उपयोगकर्ता फ़्लो, और एपीआई रोडमैप के बारे में ज़्यादा जानने के लिए, FedCM API के बारे में जानकारी देखें.

FedCM डेवलपमेंट एनवायरमेंट

FedCM का इस्तेमाल करने के लिए, आपको Chrome में आईडीपी और आरपी, दोनों पर सुरक्षित कॉन्टेक्स्ट (एचटीटीपीएस या localhost) की ज़रूरत होती है.

Android पर Chrome में कोड डीबग करना

अपने FedCM कोड को डीबग करने के लिए, स्थानीय तौर पर सर्वर सेट अप करें और उसे चलाएं. पोर्ट फ़ॉरवर्ड करने की सुविधा वाली यूएसबी केबल से कनेक्ट किए गए Android डिवाइस पर, Chrome में इस सर्वर को ऐक्सेस किया जा सकता है.

Android पर Chrome को डीबग करने के लिए, डेस्कटॉप पर DevTools का इस्तेमाल किया जा सकता है. इसके लिए, Android डिवाइसों को रिमोट से डीबग करना पर दिए गए निर्देशों का पालन करें.

Chrome पर तीसरे पक्ष की कुकी ब्लॉक करना

तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, Chrome को कॉन्फ़िगर करके, तीसरे पक्ष की कुकी के फ़ेज़-आउट को सिम्युलेट करना
Chrome को तीसरे पक्ष की कुकी को ब्लॉक करने के लिए कॉन्फ़िगर करके, तीसरे पक्ष की कुकी को धीरे-धीरे बंद करने की प्रक्रिया को सिम्युलेट करना

FedCM को लागू करने से पहले, यह जांच की जा सकती है कि Chrome पर तीसरे पक्ष की कुकी के बिना, FedCM कैसे काम करता है.

तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, गुप्त मोड का इस्तेमाल करें. इसके अलावा, chrome://settings/cookies पर अपनी डेस्कटॉप सेटिंग में जाकर "तीसरे पक्ष की कुकी ब्लॉक करें" चुनें. मोबाइल पर, सेटिंग > साइट की सेटिंग > कुकी पर जाकर भी ऐसा किया जा सकता है.

FedCM API का इस्तेमाल करना

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

इसके बाद, FedCM ऐसे JavaScript एपीआई दिखाता है जिनका इस्तेमाल आरपी, आईडीपी के साथ साइन इन करने के लिए कर सकते हैं.

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

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

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

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

JSON फ़ाइल में provider_urls प्रॉपर्टी होनी चाहिए. इसमें आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल के यूआरएल का कलेक्शन मौजूद होना चाहिए. इन यूआरएल को आरपी के हिसाब से, navigator.credentials.get में configURL के पाथ के हिस्से के तौर पर तय किया जा सके. ऐरे में यूआरएल स्ट्रिंग की संख्या एक तक सीमित है. हालांकि, आने वाले समय में आपके सुझाव/राय/शिकायत के आधार पर इसमें बदलाव हो सकता है.

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

आईडीपी कॉन्फ़िगरेशन फ़ाइल, ब्राउज़र के लिए ज़रूरी एंडपॉइंट की सूची उपलब्ध कराती है. आईडीपी, इस कॉन्फ़िगरेशन फ़ाइल और ज़रूरी एंडपॉइंट और यूआरएल को होस्ट करेंगे. सभी 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;

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

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

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

प्रॉपर्टी ब्यौरा
accounts_endpoint (ज़रूरी) खाते के एंडपॉइंट का यूआरएल.
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 या उससे ज़्यादा होनी चाहिए.

पुष्टि करने के लिए पहले से तय किए गए कॉन्टेक्स्ट के हिसाब से, आरपी, navigator.credentials.get() के लिए identity.context वैल्यू का इस्तेमाल करके, FedCM डायलॉग यूज़र इंटरफ़ेस (यूआई) में स्ट्रिंग में बदलाव कर सकता है. वैकल्पिक प्रॉपर्टी, "signin" (डिफ़ॉल्ट), "signup", "use" या "continue" में से कोई एक हो सकती है.

FedCM डायलॉग पर ब्रैंडिंग कैसे लागू की जाती है
FedCM डायलॉग में ब्रैंडिंग कैसे लागू की जाती है

यहां आईडीपी (IdP) से मिलने वाले रिस्पॉन्स का मुख्य हिस्सा उदाहरण के तौर पर दिया गया है:

{
  "accounts_endpoint": "/accounts.php",
  "client_metadata_endpoint": "/client_metadata.php",
  "id_assertion_endpoint": "/assertion.php",
  "disconnect_endpoint": "/disconnect.php",
  "login_url": "/login",
  "branding": {
    "background_color": "green",
    "color": "#FFEEAA",
    "icons": [{
      "url": "https://idp.example/icon.ico",
      "size": 25
    }]
  }
}

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

आईडीपी (IdP) एंडपॉइंट
IdP एंडपॉइंट

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

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

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

GET /accounts.php 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 प्रॉपर्टी के साथ खाते की जानकारी का कलेक्शन शामिल हो. इस कलेक्शन में ये प्रॉपर्टी होनी चाहिए:

प्रॉपर्टी ब्यौरा
id (ज़रूरी) उपयोगकर्ता का यूनीक आईडी.
name (ज़रूरी) उपयोगकर्ता का दिया गया और उपनाम.
email (ज़रूरी) उपयोगकर्ता का ईमेल पता.
given_name (वैकल्पिक) उपयोगकर्ता का नाम.
picture (वैकल्पिक) इस्तेमाल करने वाले व्यक्ति की अवतार इमेज का यूआरएल.
approved_clients (वैकल्पिक) आरपी क्लाइंट आईडी का कलेक्शन, जिसके साथ उपयोगकर्ता ने रजिस्टर किया है.
login_hints (वैकल्पिक) सभी संभावित फ़िल्टर टाइप का कलेक्शन, जिससे आईडीपी किसी खाते के बारे में बताता है. चुने गए खाते को चुनिंदा तरीके से दिखाने के लिए, आरपी loginHint प्रॉपर्टी के साथ navigator.credentials.get() शुरू कर सकता है.
domain_hints (वैकल्पिक) उन सभी डोमेन का कलेक्शन जिनसे खाता जुड़ा है. खातों को फ़िल्टर करने के लिए, आरपी domainHint प्रॉपर्टी के साथ navigator.credentials.get() को कॉल कर सकता है.

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

{
  "accounts": [{
    "id": "1234",
    "given_name": "John",
    "name": "John Doe",
    "email": "john_doe@idp.example",
    "picture": "https://idp.example/profile/123",
    "approved_clients": ["123", "456", "789"],
    "login_hints": ["demo1", "demo1@idp.example"]
  }, {
    "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", "demo2@idp.example"],
    "domain_hints": ["corp.example"]
  }]
}

अगर उपयोगकर्ता ने साइन इन नहीं किया है, तो एचटीटीपी 401 (अनऑथराइज़्ड) कोड के साथ जवाब दें.

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

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

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

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

GET /client_metadata.php?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. क्लाइंट मेटाडेटा के साथ जवाब दें.

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

प्रॉपर्टी ब्यौरा
privacy_policy_url (वैकल्पिक) आरपी की निजता नीति का यूआरएल.
terms_of_service_url (वैकल्पिक) आरपी की सेवा की शर्तों का यूआरएल.

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

{
  "privacy_policy_url": "https://rp.example/privacy_policy.html",
  "terms_of_service_url": "https://rp.example/terms_of_service.html",
}

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

आईडी दावा एंडपॉइंट

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

प्रॉपर्टी ब्यौरा
client_id (ज़रूरी) आरपी का क्लाइंट आइडेंटिफ़ायर.
account_id (ज़रूरी) साइन इन करने वाले उपयोगकर्ता का यूनीक आईडी.
nonce (वैकल्पिक) आरपी से मिला अनुरोध नॉन्स.
disclosure_text_shown बूलियन के बजाय, "true" या "false" की स्ट्रिंग में नतीजे. अगर जानकारी ज़ाहिर करने वाला टेक्स्ट नहीं दिखाया गया था, तो नतीजा "false" होगा. ऐसा तब होता है, जब आरपी का क्लाइंट आईडी, खाता एंडपॉइंट से मिले जवाब की approved_clients प्रॉपर्टी सूची में शामिल होता है या ब्राउज़र ने approved_clients की अनुपस्थिति में, पहले कभी साइन-अप के समय को देखा हो.
is_auto_selected अगर आरपी पर अपने-आप फिर से पुष्टि करने की सुविधा चालू है, तो is_auto_selected से "true" का पता चलता है. इसके अलावा, "false". इससे, सुरक्षा से जुड़ी ज़्यादा सुविधाओं को इस्तेमाल करने में मदद मिलती है. उदाहरण के लिए, कुछ उपयोगकर्ता ज़्यादा सुरक्षा वाले टीयर को प्राथमिकता दे सकते हैं. इसके लिए, पुष्टि करने के दौरान उपयोगकर्ता को साफ़ तौर पर पुष्टि करनी होगी. अगर किसी आईडीपी को इस तरह के मीडिएशन के बिना टोकन का अनुरोध मिलता है, तो वह अनुरोध को अलग तरीके से हैंडल कर सकता है. उदाहरण के लिए, गड़बड़ी का ऐसा कोड दिखाएं जिससे आरपी, mediation: required के साथ FedCM API को फिर से कॉल कर सके.

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

POST /assertion.php HTTP/1.1
Host: accounts.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=Ct60bD&disclosure_text_shown=true&is_auto_selected=true

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

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

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

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

प्रॉपर्टी ब्यौरा
token (ज़रूरी) टोकन एक ऐसी स्ट्रिंग होती है जिसमें पुष्टि करने के बारे में दावे होते हैं. 
{
  "token": "***********"
}

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

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

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"
  }
}

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

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

प्रॉपर्टी ब्यौरा
account_hint आईडीपी (IdP) खाते के लिए हिंट.
client_id आरपी का क्लाइंट आइडेंटिफ़ायर. 
POST /disconnect.php 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"
}

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

लॉगिन यूआरएल

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

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

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

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

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

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

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

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

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

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

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

Set-Login: logged-in

इसके अलावा, टॉप लेवल नेविगेशन में मौजूद आईडीपी (IdP) ऑरिजिन से, JavaScript API navigator.login.setStatus("logged-in") को कॉल करें:

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

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

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

Set-Login: logged-out

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

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

ये कॉल, उपयोगकर्ता के लॉगिन स्टेटस को logged-out के तौर पर रिकॉर्ड करते हैं. जब उपयोगकर्ता का लॉगिन स्टेटस logged-out होता है, तो IdP के खाता एंडपॉइंट से अनुरोध किए बिना, FedCM को कॉल करने की प्रोसेस बिना किसी सूचना के बंद हो जाती है.

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

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

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

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

आइडेंटिटी प्रोवाइडर की मदद से, भरोसेमंद पक्ष में साइन इन करें

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

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

if ('IdentityCredential' in window) {
  // If the feature is available, take action
}

उपयोगकर्ताओं को आरपी टीम के आईडीपी (IdP) से साइन इन करने की अनुमति देने का अनुरोध करने के लिए, यह तरीका अपनाएं:

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

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

प्रॉपर्टी ब्यौरा
configURL (ज़रूरी) आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल का पूरा पाथ.
clientId (ज़रूरी) आईडीपी से जारी किया गया आरपी का क्लाइंट आइडेंटिफ़ायर.
nonce (वैकल्पिक) यह एक रैंडम स्ट्रिंग होती है, ताकि यह पक्का किया जा सके कि जवाब इस खास अनुरोध के लिए जारी किया गया है. जवाबी हमलों को रोकता है.
loginHint (वैकल्पिक) खाते के एंडपॉइंट से मिलने वाली login_hints वैल्यू में से कोई एक तय करने पर, FedCM डायलॉग, बताए गए खाते को चुनिंदा तरीके से दिखाता है.
domainHint (वैकल्पिक) खाते के एंडपॉइंट से दी गई domain_hints वैल्यू में से किसी एक को चुनकर, FedCM डायलॉग चुनिंदा खाते को दिखाता है.

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

साइन-अप की स्थिति, इस आधार पर तय की जाती है कि ये शर्तें पूरी हुई हैं या नहीं:

  • अगर approved_clients में RP का clientId शामिल है.
  • अगर ब्राउज़र को याद है कि उपयोगकर्ता ने पहले ही आरपी के लिए साइन अप कर लिया है.
उपयोगकर्ता, FedCM का इस्तेमाल करके किसी आरपी में साइन इन करता है.

जब आरपी navigator.credentials.get() को कॉल करता है, तो ये कार्रवाइयां होती हैं:

  1. ब्राउज़र कई अनुरोध भेजता है और कई दस्तावेज़ फ़ेच करता है:
    1. well-known फ़ाइल और आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल, जो एंडपॉइंट की जानकारी देती है.
    2. खातों की सूची.
    3. ज़रूरी नहीं: आरपी की निजता नीति और सेवा की शर्तों के यूआरएल, जो क्लाइंट मेटाडेटा एंडपॉइंट से लिए गए हैं.
  2. ब्राउज़र, उन खातों की सूची दिखाता है जिनका इस्तेमाल करके उपयोगकर्ता साइन इन कर सकता है. साथ ही, अगर उपलब्ध हो, तो सेवा की शर्तें और निजता नीति भी दिखती है.
  3. जब उपयोगकर्ता साइन इन करने के लिए कोई खाता चुन लेता है, तो टोकन पाने के लिए, IdP को आईडी एश्योरेशन एंडपॉइंट का अनुरोध भेजा जाता है.
  4. उपयोगकर्ता की पुष्टि करने के लिए, आरपी टोकन की पुष्टि कर सकता है.
login API call
login API call

आरपी ऐसे ब्राउज़र के साथ काम करते हैं जो FedCM के साथ काम नहीं करते. इसलिए, उपयोगकर्ताओं को FedCM के बिना साइन इन करने की मौजूदा प्रोसेस का इस्तेमाल करना चाहिए. जब तक तीसरे पक्ष की कुकी पूरी तरह से बंद नहीं हो जातीं, तब तक इसकी वजह से कोई समस्या नहीं होगी.

आरपी सर्वर से टोकन की पुष्टि होने के बाद, आरपी उपयोगकर्ता को रजिस्टर कर सकता है या उसे साइन-इन करने और नया सेशन शुरू करने की अनुमति दे सकता है.

Login Hint API

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

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

return await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/manifest.json",
      clientId: "123",
      nonce: nonce,
      loginHint : "demo1@example.com"
    }]
  }
});

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

Domain Hint API

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

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

return await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/manifest.json",
      clientId: "abc",
      nonce: nonce,
      domainHint : "corp.example"
    }]
  }
});

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

डोमेन हिंट से किसी खाते का मैच न होने पर लॉगिन के प्रॉम्प्ट का उदाहरण.
domainHint से मैच करने वाला कोई खाता न होने पर, लॉगिन प्रॉम्प्ट का उदाहरण
.

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

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

A
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 का एक मुख्य लक्ष्य है. हालांकि, उपयोगकर्ता के एक बार जानकारी देने के बाद, उसे फिर से जानकारी देने के लिए कहना ज़रूरी नहीं है. उपयोगकर्ता के RP और IdP के बीच कम्यूनिकेशन की अनुमति देने के बाद, किसी ऐसी जानकारी के लिए फिर से साफ़ तौर पर जानकारी देने के लिए कहना, निजता या सुरक्षा के लिहाज़ से फ़ायदेमंद नहीं होता जिसकी पुष्टि उपयोगकर्ता ने पहले ही कर दी है.

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

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

क्रॉस-ओरिजिन 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")

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