Chrome 122 से, Federated क्रेडेंशियल Management API (FedCM) के लिए, डिसकनेक्ट एपीआई उपलब्ध है. डिसकनेक्ट एपीआई, भरोसेमंद पक्षों को अपने उपयोगकर्ताओं को, पहचान देने वाली सेवा के खाते से डिसकनेक्ट करने की अनुमति देता है. ऐसा, तीसरे पक्ष की कुकी के बिना किया जा सकता है. साथ ही, FedCM को एक ही साइट पर मैनेज करने के कुछ अपडेट भी किए गए हैं.
एपीआई डिसकनेक्ट करें
जब कोई उपयोगकर्ता, आइडेंटिटी फ़ेडरेशन के ज़रिए किसी भरोसेमंद पक्ष (आरपी—पुष्टि करने के लिए आइडेंटिटी प्रोवाइडर का इस्तेमाल करने वाली साइट) पर खाता बनाता है, तो आइडेंटिटी प्रोवाइडर (आईडीपी) आम तौर पर अपने सर्वर पर कनेक्शन रिकॉर्ड करता है. यह सेवा अन्य पक्षों को पुष्टि करने और खाते की जानकारी उपलब्ध कराती है. स्टोर किए गए कनेक्शन की मदद से, आईडीपी (IdP) उस आरपी को ट्रैक कर सकता है जिसमें उपयोगकर्ता ने साइन इन किया है. साथ ही, वह उसके अनुभव को बेहतर भी बना सकता है. उदाहरण के लिए, उपयोगकर्ता जब बाद में आरपी पर लौटता है, तो उसे बेहतर अनुभव देने के लिए आईडीपी वाले उपयोगकर्ता खाते को, वापस आने वाले खाते के तौर पर माना जाता है. इससे, अपने-आप फिर से पुष्टि करने और इस्तेमाल किए गए खाते को अपने हिसाब से दिखाने वाले बटन जैसी सुविधाएं मिलती हैं.
कभी-कभी, आईडीपी, खाते को आरपी से डिसकनेक्ट करने के लिए एपीआई ऑफ़र करते हैं. हालांकि, डिसकनेक्ट फ़्लो की पुष्टि हो गई है और इसके लिए आईडीपी कुकी की ज़रूरत है. तीसरे पक्ष की कुकी के बिना, जब उपयोगकर्ता आरपी पर जाता है, तो आरपी के लिए कोई ब्राउज़र एपीआई नहीं होता, जिसे आईडीपी से डिसकनेक्ट किया जा सके. किसी आरपी से जुड़े एक ही आईडीपी (IdP) के कई आईडीपी खाते हो सकते हैं, इसलिए डिसकनेक्ट फ़्लो को यह जानना ज़रूरी है कि कौनसा खाता डिसकनेक्ट किया जा रहा है.
डिसकनेक्ट एपीआई की मदद से उपयोगकर्ता, ब्राउज़र और आईडीपी सर्वर पर मौजूद आरपी से आईडीपी खाते को डिसकनेक्ट कर सकता है. इसके लिए, उसे दिए गए एंडपॉइंट पर सिग्नल भेजा जाता है. उपयोगकर्ता को फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट एपीआई (FedCM) का इस्तेमाल करके, आइडेंटिटी फ़ेडरेशन से गुज़रना होगा. इस उपयोगकर्ता के डिसकनेक्ट हो जाने के बाद, अगली बार आईडीपी (IdP) का इस्तेमाल करके आरपी में साइन इन करने पर, उसे नया उपयोगकर्ता माना जाता है.
आईडीपी (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 को बंद कर दिया है.
जब आईडीपी का डिसकनेक्ट एंडपॉइंट जवाब देता है, तो ब्राउज़र पर आरपी और आईडीपी डिसकनेक्ट हो जाते हैं. साथ ही, प्रॉमिस रिज़ॉल्व हो जाता है. डिसकनेक्ट करने वाले उपयोगकर्ता खातों की जानकारी, डिसकनेक्ट एंडपॉइंट से मिलने वाले रिस्पॉन्स में होती है.
आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल सेट अप करें
डिसकनेक्ट एपीआई के साथ काम करने के लिए, आईडीपी को डिसकनेक्ट एंडपॉइंट के साथ काम करना चाहिए. साथ ही, अपनी आईडीपी कॉन्फ़िगरेशन फ़ाइल में disconnect_endpoint
प्रॉपर्टी और उसका पाथ उपलब्ध कराना चाहिए.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
डिसकनेक्ट किए गए एंडपॉइंट पर खाते को डिसकनेक्ट करना
IdentityCredential.disconnect()
को शुरू करने पर, ब्राउज़र कुकी के साथ क्रॉस-ऑरिजिन POST
अनुरोध और इस डिसकनेक्ट एंडपॉइंट को application/x-www-form-urlencoded
के कॉन्टेंट-टाइप वाला डेटा भेजता है. इस अनुरोध में, यहां दी गई जानकारी शामिल होती है:
प्रॉपर्टी | जानकारी |
---|---|
account_hint |
आईडीपी (IdP) खाते के लिए संकेत. |
client_id |
आरपी का क्लाइंट आइडेंटिफ़ायर. |
POST /disconnect 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
अनुरोध मिलने पर, आईडीपी (IdP) सर्वर को:
- सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) की मदद से अनुरोध का जवाब दें.
- पुष्टि करें कि अनुरोध में
Sec-Fetch-Dest: webidentity
एचटीटीपी हेडर है. Origin
हेडर कोclient_id
के तय किए गए आरपी ऑरिजिन के साथ मैच करें. अगर ये आपस में मेल नहीं खाते, तो उन्हें अस्वीकार कर दें.account_hint
से मेल खाने वाला खाता ढूंढें.- आरपी से कनेक्ट किए गए खातों की सूची से उपयोगकर्ता खाते को डिसकनेक्ट करें.
- उपयोगकर्ता के
account_id
की मदद से, ब्राउज़र को JSON फ़ॉर्मैट में जवाब दिया जा सकता है.
रिस्पॉन्स JSON पेलोड का उदाहरण:
{
"account_id": "account456"
}
अगर आईडीपी (IdP) चाहता है कि ब्राउज़र, आरपी से जुड़े सभी खाते डिसकनेक्ट कर दे, तो ऐसी स्ट्रिंग पास करें जो किसी भी खाता आईडी से मेल न खाती हो, जैसे कि "*"
.
आरपी और आईडीपी (IdP) का एक ही साइट पर मौजूद होने पर, अब /.well-known/web-identity
की जांच नहीं की जाएगी
FedCM सिस्टम डेवलप करते समय, आरपी सर्वर डोमेन की जांच या स्टेजिंग
इस प्रोडक्शन आईडीपी सर्वर के सबडोमेन हो सकते हैं. उदाहरण के लिए, प्रोडक्शन आईडीपी सर्वर idp.example
पर है और स्टेजिंग आरपी सर्वर और स्टेजिंग आईडीपी सर्वर, दोनों staging.idp.example
पर हैं. हालांकि, जानी-मानी फ़ाइल को
आईडीपी सर्वर के eTLD+1 के रूट में रखा जाना चाहिए, इसलिए उसे
idp.example/.well-known/web-identity
पर होना चाहिए और वह प्रोडक्शन सर्वर है. हालांकि, यह ज़रूरी नहीं है कि डेवलपर डेवलपमेंट के दौरान, फ़ाइलों को प्रोडक्शन एनवायरमेंट में रख सकें. इसलिए, वे FedCM को टेस्ट नहीं कर पाते.
Chrome 122 से, अगर आरपी डोमेन और आईडीपी (IdP) डोमेन एक जैसे हैं, तो Chrome जानी-पहचानी फ़ाइल की जांच करना छोड़ देता है. इस तरह, डेवलपर ऐसी स्थिति में टेस्ट कर पाएंगे.
सबरिसॉर्स अब उसी साइट पर लॉगिन का स्टेटस सेट कर सकते हैं
पहले, Chrome सिर्फ़ लॉगिन की स्थिति सेट करने की अनुमति देता था, जैसे कि Set-Login: logged-in
हेडर का इस्तेमाल करके. ऐसा तब किया जा सकता था, जब अनुरोध के लिए सभी पूर्वजों के अनुरोध एक ही मूल से किए गए हों. इसकी वजह से,
एक ही साइट
से लॉगिन करने वाले fetch()
अनुरोधों के लिए, लॉगिन स्टेटस सेट करने पर रोक लगा दी गई.
उदाहरण के लिए, ऐसी वेबसाइट के बारे में सोचें जो idp.example
पर लोगों को अपना उपयोगकर्ता नाम और पासवर्ड डालने की सुविधा देती हो, लेकिन क्रेडेंशियल fetch()
के साथ login.idp.example
पर पोस्ट किए गए हों. लॉगिन स्टेटस एपीआई का इस्तेमाल करके, ब्राउज़र में लॉगिन स्टेटस रिकॉर्ड नहीं किया जा सका. ऐसा इसलिए हुआ, क्योंकि दो डोमेन क्रॉस-ऑरिजिन और एक ही साइट के हैं.
इस बदलाव के साथ ही, हमने लॉगिन स्टेटस एपीआई के सभी पूर्वजों के साथ एक ही साइट होने की शर्त को कम कर दिया है. साथ ही, ऊपर दिए गए उदाहरण में एचटीटीपी हेडर (Set-Login:
logged-in
) का इस्तेमाल करके login.idp.example
के लॉगिन स्टेटस को सेट किया जा सकता है.
खास जानकारी
डिसकनेक्ट एपीआई का इस्तेमाल करके, FedCM तीसरे पक्ष की कुकी के बिना, आरपी को आईडीपी से डिसकनेक्ट कर सकता है. ऐसा करने के लिए, आरपी पर
IdentityCredential.disconnect()
को कॉल करें. इस फ़ंक्शन की मदद से ब्राउज़र, आईडीपी के डिसकनेक्ट एंडपॉइंट को अनुरोध भेजता है, ताकि आईडीपी (IdP) सर्वर और फिर ब्राउज़र
से कनेक्शन खत्म कर सके.
हमने बताया है कि टेस्टिंग के लिए, आरपी और आईडीपी (IdP) के एक ही साइट पर होने पर, /.well-known/web-identity
की जांच नहीं की जाती. अब उसी साइट के आईडीपी (IdP) सबरिसॉर्स से एचटीटीपी रिस्पॉन्स हेडर से लॉगिन की स्थिति सेट की जा सकती है.