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

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

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

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

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

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

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

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

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

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

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

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

तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, गुप्त मोड का इस्तेमाल करें. इसके अलावा, 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) एंडपॉइंट
IdP एंडपॉइंट

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

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

ब्राउज़र, कुकी के साथ GET का अनुरोध भेजता है. हालांकि, इसमें SameSite=None की जानकारी शामिल होती है. हालांकि, इसमें 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 (वैकल्पिक) उन सभी डोमेन की कैटगरी जिनसे खाता जुड़ा है. खातों को फ़िल्टर करने के लिए, आरपी navigator.credentials.get() को domainHint प्रॉपर्टी के साथ कॉल कर सकता है.

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

{
  "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 (अनऑथराइज़्ड) कोड के साथ जवाब दें.

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

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

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

ब्राउज़र, कुकी के बिना 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". इसका इस्तेमाल, सुरक्षा से जुड़ी ज़्यादा सुविधाओं के लिए किया जाता है. उदाहरण के लिए, कुछ उपयोगकर्ता ज़्यादा सुरक्षा वाले टीयर को प्राथमिकता दे सकते हैं. इसके लिए, पुष्टि करने के दौरान उपयोगकर्ता को साफ़ तौर पर पुष्टि करनी होगी. अगर किसी आईडीपी (IdP) को इस तरह की मध्यस्थता के बिना टोकन अनुरोध मिलता है, तो वह अनुरोध को अलग तरीके से हैंडल कर सकता है. उदाहरण के लिए, गड़बड़ी का ऐसा कोड दें जिससे आरपी, 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"
}

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

लॉगिन यूआरएल

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

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

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

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

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

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

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

ब्राउज़र को, आइडेंटिटी प्रोवाइडर पर उपयोगकर्ता के लॉगिन स्टेटस के बारे में जानकारी दें

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

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

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

Set-Login: logged-in

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

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

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

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

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

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

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

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

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

साइन-अप की स्थिति इस आधार पर तय होती है कि नीचे दी गई शर्तों को पूरा किया गया है या नहीं:

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

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

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

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

Domain Hint API

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

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

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

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

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

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

क्रॉस-ऑरिजिन iframe से FedCM को कॉल करें

अगर पैरंट फ़्रेम अनुमति देता है, तो identity-credentials-get की अनुमतियों की नीति का इस्तेमाल करके, FedCM को क्रॉस-ऑरिजिन iframe में शुरू किया जा सकता है. ऐसा करने के लिए, 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")

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