Chrome 122 में, Federated Credential Management API (FedCM) के लिए Disconnect API उपलब्ध है. डिसकनेक्ट एपीआई की मदद से भरोसेमंद पार्टी, तीसरे पक्ष की कुकी पर निर्भर हुए बिना, अपने उपयोगकर्ताओं को आइडेंटिटी प्रोवाइडर के खाते से डिसकनेक्ट कर सकती हैं. साथ ही, FedCM के एक ही साइट को हैंडल करने के तरीके में कुछ अपडेट किए गए हैं.
एपीआई डिसकनेक्ट करें
जब कोई उपयोगकर्ता, पहचान फ़ेडरेशन की मदद से किसी भरोसेमंद पक्ष (RP—पुष्टि करने के लिए, पहचान की पुष्टि करने वाली सेवा का इस्तेमाल करने वाली साइट) पर खाता बनाता है, तो पहचान की पुष्टि करने वाली सेवा (IdP—यह सेवा, पुष्टि करने और अन्य पक्षों को खाते की जानकारी देने के लिए इस्तेमाल की जाती है) आम तौर पर अपने सर्वर पर कनेक्शन को रिकॉर्ड करती है. सेव किए गए कनेक्शन की मदद से, आईडीपी उन आरपी को ट्रैक कर सकता है जिनमें उपयोगकर्ता ने साइन इन किया है. साथ ही, उपयोगकर्ता के अनुभव को ऑप्टिमाइज़ कर सकता है. उदाहरण के लिए, उपयोगकर्ता के बाद में RP पर वापस आने पर बेहतर अनुभव देने के लिए, IdP के साथ मौजूद उपयोगकर्ता खाते को फिर से आने वाले खाते के तौर पर माना जाता है. इससे, अपने-आप फिर से पुष्टि करने और इस्तेमाल किए गए खाते को दिखाने वाले, उपयोगकर्ता के हिसाब से बटन जैसी सुविधाओं का इस्तेमाल किया जा सकता है.
कभी-कभी, आईडीपी (IdP) खाते को आरपी से डिसकनेक्ट करने के लिए एपीआई की सुविधा देते हैं. हालांकि, डिसकनेक्ट फ़्लो की पुष्टि की जाती है और इसके लिए, आईडीपी (IdP) कुकी की ज़रूरत होती है. तीसरे पक्ष की कुकी के बिना, जब कोई उपयोगकर्ता आरपी पर जाता है, तो आरपी के लिए, आईडीपी (IdP) से डिसकनेक्ट करने के लिए कोई ब्राउज़र एपीआई नहीं होता. एक ही आईडीपी (IdP) से कई आईडीपी खाते जुड़े हो सकते हैं. इसलिए, किसी खास आरपी से जुड़े होने की वजह से, डिसकनेक्ट करने की प्रोसेस के दौरान यह जानने की ज़रूरत होती है कि कौनसा खाता डिसकनेक्ट किया गया है.
Disconnect API की मदद से, उपयोगकर्ता ब्राउज़र पर आईडीपी खाते को आरपी से डिसकनेक्ट कर सकता है. साथ ही, वह तय किए गए एंडपॉइंट को सिग्नल भेजकर, आईडीपी सर्वर पर भी आईडीपी खाते को डिसकनेक्ट कर सकता है. उपयोगकर्ता को, फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट एपीआई (FedCM) का इस्तेमाल करके, आइडेंटिटी फ़ेडरेशन की प्रोसेस पूरी करनी होगी. अगर उपयोगकर्ता का खाता डिसकनेक्ट हो जाता है, तो अगली बार आईडीपी (IdP) का इस्तेमाल करके आरपी में साइन इन करने पर, उसे नया उपयोगकर्ता माना जाता है.
आईडीपी को आरपी से डिसकनेक्ट करें
अगर किसी उपयोगकर्ता ने पहले 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 का डिसकनेक्ट एंडपॉइंट कोई जवाब देता है, तो RP और IdP ब्राउज़र पर डिसकनेक्ट हो जाते हैं और वादा पूरा हो जाता है. डिसकनेक्ट एंडपॉइंट से मिले रिस्पॉन्स में, डिसकनेक्ट किए जा रहे उपयोगकर्ता खातों की जानकारी दी जाती है.
आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल सेट अप करें
Disconnect API के साथ काम करने के लिए, आईडीपी (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) साइट पर मौजूद होने पर, /.well-known/web-identity
को चेक करने की प्रोसेस को स्किप कर दिया गया है
FedCM सिस्टम डेवलप करते समय, टेस्टिंग या स्टेजिंग आरपी सर्वर डोमेन, प्रोडक्शन IdP सर्वर के सबडोमेन हो सकते हैं. उदाहरण के लिए, प्रोडक्शन आईडीपी सर्वर idp.example
पर है और स्टैजिंग आरपी सर्वर और स्टैजिंग आईडीपी सर्वर, दोनों staging.idp.example
पर हैं. हालांकि, लोकप्रिय फ़ाइल को आईडीपी सर्वर के eTLD+1 के रूट में डाला जाना चाहिए. इसलिए, यह idp.example/.well-known/web-identity
पर होना चाहिए और यह प्रोडक्शन सर्वर है. यह ज़रूरी नहीं है कि डेवलपर, डेवलपमेंट के दौरान फ़ाइलों को प्रोडक्शन एनवायरमेंट में रखें.
इससे वे FedCM की जांच नहीं कर पाएंगे.
अगर Chrome 122 और आरपी डोमेन और आईडीपी (IdP) डोमेन एक ही हैं, तो Chrome उस फ़ाइल को स्किप कर देता है जो लोकप्रिय है. इस तरह, डेवलपर ऐसी स्थिति में टेस्ट कर पाएंगे.
सब-रिसॉर्स अब एक ही साइट पर लॉगिन करने की स्थिति सेट कर सकते हैं
इससे पहले, Chrome सिर्फ़ तब लॉगिन की स्थिति सेट करने की अनुमति देता था, जब
Set-Login: logged-in
हेडर का इस्तेमाल करके
अनुरोध एक ही ऑरिजिन
के लिए किया गया हो. इससे, लॉगिन स्टेटस सेट करने वाले same-sitefetch()
अनुरोधों के ज़रिए लॉगिन करने से रोका गया.
उदाहरण के लिए, ऐसी वेबसाइट के बारे में सोचें जो उपयोगकर्ताओं को idp.example
पर अपना उपयोगकर्ता नाम और पासवर्ड डालने की अनुमति देती है, लेकिन क्रेडेंशियल को fetch()
के साथ login.idp.example
पर पोस्ट किया जाता है. लॉगिन स्टेटस एपीआई का इस्तेमाल करके, ब्राउज़र में लॉगिन स्टेटस रिकॉर्ड नहीं किया जा सका, क्योंकि दोनों डोमेन क्रॉस-ऑरिजिन और एक ही साइट के हैं.
इस बदलाव के साथ, हमने लॉगिन स्थिति एपीआई को सभी पहले वाले लोगों के लिए एक ही साइट पर सेट करने की शर्त में छूट दी है. साथ ही, ऊपर दिए गए उदाहरण को एचटीटीपी हेडर (Set-Login:
logged-in
) का इस्तेमाल करके login.idp.example
के लॉगिन का स्टेटस सेट करने के लिए अनुमति दी गई है.
खास जानकारी
Disconnect API का इस्तेमाल करके, FedCM अब तीसरे पक्ष की कुकी पर निर्भर हुए बिना, RP को IdP से डिसकनेक्ट कर सकता है. ऐसा करने के लिए, RP पर IdentityCredential.disconnect()
को कॉल करें. इस फ़ंक्शन की मदद से ब्राउज़र, आईडीपी के डिसकनेक्ट एंडपॉइंट पर एक अनुरोध भेजता है. इससे आईडीपी, सर्वर पर और फिर ब्राउज़र पर कनेक्शन को खत्म कर सकता है.
हमने यह एलान किया है कि टेस्टिंग के मकसद से, जब RP और IdP एक ही साइट पर हों, तो /.well-known/web-identity
की जांच नहीं की जाएगी. साथ ही, एक ही साइट के आईडीपी (IdP) सबरिसॉर्स से एचटीटीपी रिस्पॉन्स हेडर के ज़रिए लॉगिन की स्थिति सेट की जा सकती है.