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

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

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

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

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

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

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

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

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

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

तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, Chrome को कॉन्फ़िगर करके उन्हें सिम्युलेट करें
Chrome को ब्लॉक करने के लिए, कॉन्फ़िगर करके तीसरे पक्ष की कुकी के चरण को सिम्युलेट करें

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

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

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

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

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

एक लोकप्रिय फ़ाइल बनाना

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

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

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

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

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

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

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

ब्राउज़र को आईडीपी से 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 या उससे ज़्यादा होनी चाहिए.

आरपी, FedCM डायलॉग यूज़र इंटरफ़ेस (यूआई) में मौजूद स्ट्रिंग में बदलाव कर सकता है. इसके लिए, वह navigator.credentials.get() के लिए identity.context वैल्यू का इस्तेमाल करेगा. ऐसा पुष्टि करने से जुड़े पहले से तय संदर्भ के हिसाब से किया जा सकता है. वैकल्पिक प्रॉपर्टी, "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 कुकी के साथ, लेकिन client_id पैरामीटर, Origin हेडर या Referer हेडर के बिना, GET अनुरोध भेजता है. इससे आईडीपी को यह पता नहीं चलता कि उपयोगकर्ता किस आरपी में साइन इन करने की कोशिश कर रहा है. उदाहरण के लिए:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Set-Login: logged-out

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लॉगिन हिंट एपीआई

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

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

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

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

डोमेन हिंट एपीआई

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

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

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

आईडीपी (IdP) को आरपी से डिसकनेक्ट करें

अगर किसी उपयोगकर्ता ने पहले भी 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 को बंद कर दिया है.

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

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

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