FedCM के अपडेट: एपीआई डिसकनेक्ट करने के साथ-साथ दो अपडेट

Chrome 122 में, Federated Credential Management API (FedCM) के लिए Disconnect API उपलब्ध है. Disconnect API की मदद से, भरोसा करने वाले पक्ष अपने उपयोगकर्ताओं को तीसरे पक्ष की कुकी के बिना, पहचान की पुष्टि करने वाली सेवा देने वाली कंपनी के खाते से डिसकनेक्ट कर सकते हैं. साथ ही, FedCM के एक ही साइट को हैंडल करने के तरीके में कुछ अपडेट किए गए हैं.

Disconnect API

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

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

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

आईडीपी को आरपी से डिसकनेक्ट करना

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

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

आईडीपी (IdP) कॉन्फ़िगरेशन फ़ाइल सेट अप करना

Disconnect API के साथ काम करने के लिए, आईडीपी के पास डिसकनेक्ट एंडपॉइंट होना चाहिए. साथ ही, आईडीपी कॉन्फ़िगरेशन फ़ाइल में disconnect_endpoint प्रॉपर्टी और उसका पाथ उपलब्ध कराना चाहिए.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

डिसकनेक्ट करने वाले एंडपॉइंट पर जाकर खाता डिसकनेक्ट करना

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

प्रॉपर्टी ब्यौरा
account_hint आईडीपी खाते के लिए एक हिंट.
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

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

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

जवाब के तौर पर मिलने वाले JSON पेलोड का उदाहरण इस तरह दिखता है:

{
  "account_id": "account456"
}

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

जब आरपी और आईडीपी एक ही साइट पर हों, तो /.well-known/web-identity की जांच अब छोड़ दी जाती है

FedCM सिस्टम डेवलप करते समय, टेस्टिंग या स्टेजिंग आरपी सर्वर डोमेन, प्रोडक्शन आईडीपी सर्वर के सबडोमेन हो सकते हैं. उदाहरण के लिए, प्रोडक्शन आईडीपी सर्वर idp.example पर है और स्टैजिंग आरपी सर्वर और स्टैजिंग आईडीपी सर्वर, दोनों staging.idp.example पर हैं. हालांकि, .well-known फ़ाइल को आईडीपी सर्वर के ईटीएलडी+1 के रूट में डाला जाना चाहिए. इसलिए, यह idp.example/.well-known/web-identity पर होनी चाहिए और यह प्रोडक्शन सर्वर है. डेवलपर के लिए, ऐप्लिकेशन के डेवलपमेंट के दौरान, प्रोडक्शन एनवायरमेंट में फ़ाइलें डालना ज़रूरी नहीं है. इसलिए, वे FedCM की जांच नहीं कर पाते.

Chrome 122 से, अगर आरपी डोमेन और आईडीपी डोमेन एक ही हैं, तो Chrome, अच्छी तरह से जानी-पहचानी फ़ाइल की जांच नहीं करता. इस तरह, डेवलपर ऐसी स्थिति में टेस्ट कर पाएंगे.

सब-रिसॉर्स अब एक ही साइट पर लॉगिन करने की स्थिति सेट कर सकते हैं

पहले, Chrome सिर्फ़ तब लॉगिन की स्थिति सेट करने की अनुमति देता था, जब अनुरोध सभी पैरंट के साथ एक ही ऑरिजिन होता था. उदाहरण के लिए, Set-Login: logged-in हेडर का इस्तेमाल करके. इससे, लॉगिन स्टेटस सेट करने वाले same-site fetch() अनुरोधों के ज़रिए लॉगिन करने से रोका गया.

उदाहरण के लिए, ऐसी वेबसाइट के बारे में सोचें जो उपयोगकर्ताओं को idp.example पर अपना उपयोगकर्ता नाम और पासवर्ड डालने की अनुमति देती है, लेकिन क्रेडेंशियल को fetch() के साथ login.idp.example पर पोस्ट किया जाता है. लॉगिन स्टेटस एपीआई का इस्तेमाल करके, ब्राउज़र में लॉगिन स्टेटस रिकॉर्ड नहीं किया जा सका, क्योंकि दोनों डोमेन क्रॉस-ऑरिजिन और एक ही साइट के हैं.

इस बदलाव के बाद, हमने लॉगिन स्टेटस एपीआई के लिए, सभी पैरंट साइट के साथ एक ही साइट पर होने की ज़रूरी शर्त को कम कर दिया है. साथ ही, ऊपर दिए गए उदाहरण में एचटीटीपी हेडर (Set-Login: logged-in) का इस्तेमाल करके, login.idp.example का लॉगिन स्टेटस सेट किया जा सकता है.

खास जानकारी

Disconnect API का इस्तेमाल करके, FedCM अब तीसरे पक्ष की कुकी पर भरोसा किए बिना, आरपी को आईडीपी से डिसकनेक्ट कर सकता है. ऐसा करने के लिए, आरपी पर IdentityCredential.disconnect() को कॉल करें. इस फ़ंक्शन की मदद से, ब्राउज़र, आईडीपी के डिसकनेक्ट एंडपॉइंट को अनुरोध भेजता है, ताकि आईडीपी सर्वर और फिर ब्राउज़र से कनेक्शन को बंद कर सके.

हमने यह एलान किया है कि टेस्टिंग के मकसद से, जब RP और IdP एक ही साइट पर हों, तो /.well-known/web-identity की जांच नहीं की जाएगी. साथ ही, अब एक ही साइट के आईडीपी सब-रिसॉर्स से एचटीटीपी रिस्पॉन्स हेडर की मदद से, लॉगिन की स्थिति सेट की जा सकती है.