Chrome 143 में FedCM में परिवर्तन: संरचित ID दावे, कड़े क्लाइंट मेटाडेटा, और ब्रेकिंग API अपडेट

वेब प्लेटफ़ॉर्मप्रमाणीकरणक्रोम

Chrome 143 (12 जनवरी, 2026 को प्रकाशित) कई FedCM (फेडरेटेड क्रेडेंशियल प्रबंधन) परिवर्तनों को पेश करता है जो पूर्ण-स्टैक टीमों के लिए तुरंत प्रासंगिक हैं जो वेब साइन-इन प्रवाह का निर्माण कर रही हैं। अपडेट पहचान प्रदाताओं (IdPs) को ID दावे में संरचित JSON लौटाने की अनुमति देता है, क्लाइंट_मेटाडेटा सत्यापन को कड़ा करता है (ब्राउज़र आवश्यक फ़ील्ड लागू करना शुरू करेगा), और कुछ ब्रेकिंग API/आकार परिवर्तनों को लागू करता है जो Chrome 145 द्वारा लागू किए जाएंगे। (developer.chrome.com)

यह क्यों महत्वपूर्ण है

  • ये वैकल्पिक UX सुधार नहीं हैं: वे आपके IdP एंडपॉइंट्स द्वारा लौटाए गए डेटा के आकार और Chrome द्वारा IdPs से RPs को मिलाने के समय स्वीकार किए जाने वाले डेटा के आकार को बदलते हैं। यदि आप एक IdP होस्ट करते हैं या FedCM-एकीकृत साइन-इन पर निर्भर करते हैं, तो परिवर्तन Chrome 145 के आने पर चुपचाप लॉगिन को तोड़ सकता है।
  • परिवर्तन क्लाइंट कोड (navigator.credentials.get() कॉल, त्रुटि प्रबंधन, और जहां आप nonce शामिल करते हैं) और सर्वर-साइड एंडपॉइंट्स (.well-known/web-identity और ID दावा प्रतिक्रिया) दोनों को प्रभावित करते हैं।
  • Chrome एक संक्रमण विंडो (Chrome 143–144) प्रदान करता है जहां पुराने और नए व्यवहार सह-अस्तित्व में हैं, लेकिन टीमों को Chrome 145 में लागू होने से पहले अपडेट करना चाहिए।

प्रमुख तकनीकी परिवर्तन (संक्षेप में)

  • ID दावा टोकन एक संरचित JSON ऑब्जेक्ट हो सकता है न कि एक अनुक्रमित स्ट्रिंग (जैसे, { token: { access_token: "...", user_info: { email: "..." } } }). यह मैन्युअल सर्वर-साइड JSON स्ट्रिंगिफिकेशन और क्लाइंट-साइड पार्सिंग को हटा देता है। (developer.chrome.com)
  • क्लाइंट_मेटाडेटा सत्यापन कड़ा है: यदि आप एक क्लाइंट_मेटाडेटा एंडपॉइंट का उपयोग करते हैं, तो आपकी .well-known/web-identity में accounts_endpoint और login_url शामिल होना चाहिए; Chrome 145 accounts_endpoint को लागू करेगा। (developer.chrome.com)
  • API आकार / त्रुटि परिवर्तन: शीर्ष स्तर का nonce params ऑब्जेक्ट में स्थानांतरित किया जा रहा है जिसका उपयोग navigator.credentials.get(...) के साथ किया जाता है, और IdentityCredentialError.code का नाम बदलकर IdentityCredentialError.error कर दिया गया है — संक्रमण के दौरान दोनों को संभालें। (developer.chrome.com)

पूर्ण-स्टैक टीमों के लिए व्यावहारिक चेकलिस्ट (उच्च प्रभाव, कम घर्षण)

  • IdP ID दावा प्रतिक्रियाओं को अपडेट करें
    • token के लिए एक वास्तविक JSON ऑब्जेक्ट लौटाएं (न कि एक JSON स्ट्रिंग)। स्थिर संरचना के तहत कोई अतिरिक्त दावे जोड़ें (access_token, user_info, आदि)।
    • सत्यापित करें कि सर्वर-साइड साइनिंग/सत्यापन तर्क संरचित टोकन प्रारूप को स्वीकार करता है जिसकी आपके RP को अपेक्षा है।
  • ज्ञात मेटाडेटा को मान्य करें और प्रकाशित करें
    • सुनिश्चित करें कि आपकी .well-known/web-identity में आवश्यक फ़ील्ड शामिल हैं: न्यूनतम accounts_endpoint और login_url।
    • Chrome 143 का उपयोग करके स्टेजिंग में एंडपॉइंट खोज और प्रतिक्रिया आकार का परीक्षण करें।
  • क्लाइंट एकीकरण को अपडेट करें
    • nonce को params ऑब्जेक्ट में स्थानांतरित करें जो navigator.credentials.get({...}) को पास किया जाता है। शीर्ष स्तर के nonce से बचें।
    • 143–144 संक्रमण विंडो के दौरान दोनों e.error और e.code की जांच करने के लिए त्रुटि प्रबंधन को अपडेट करें।
    • नए आकार का समर्थन न करने वाले ब्राउज़रों के लिए फ़ीचर-डिटेक्शन और ग्रेसफुल फॉलबैक जोड़ें।
  • क्रॉस-ब्राउज़र व्यवहार और पुनरावृत्तियों का परीक्षण करें
    • Chrome 143+ और पुराने ब्राउज़रों के साथ एंड-टू-एंड परीक्षण चलाएँ। प्रवाह को मान्य करने के लिए FedCM डेमो और Chrome दस्तावेज़ों में कार्यान्वयन मार्गदर्शन का उपयोग करें। (developer.chrome.com)
  • टेलीमेट्री और स्टेज्ड फ़ीचर फ़्लैग के साथ रोल आउट करें
    • एक टॉगल के पीछे सर्वर परिवर्तनों को तैनात करें, ट्रैफ़िक के एक छोटे प्रतिशत के लिए सक्षम करें, और पूर्ण रोलआउट से पहले प्रमाणीकरण विफलता दरों और उपयोगकर्ता ड्रॉप-ऑफ की निगरानी करें।
    • खोज, .well-known फ़ेच, और पहचान दावा पार्सिंग त्रुटियों के लिए लॉगिंग जोड़ें।
  • CI / सुरक्षा पाइपलाइनों
    • एक परीक्षण जोड़ें जो .well-known को फ़ेच करता है और आवश्यक क्लाइंट_मेटाडेटा कुंजियों की उपस्थिति को मान्य करता है।
    • यदि आप एक IdP हैं, तो परिवर्तन को एक संगतता तोड़ने वाले परिवर्तन के रूप में मानें और RP या ग्राहकों को एकीकरण मार्गदर्शिकाओं के साथ सूचित करें।

समयरेखा और जोखिम

  • संक्रमण विंडो: Chrome 143–144 पुराने और नए आकार दोनों का समर्थन करता है। Chrome 145 में प्रवर्तन शुरू होता है — उत्पादन टूटने से बचने के लिए उस रिलीज से पहले अपडेट करें। (developer.chrome.com)
  • जोखिम स्तर: IdPs और RPs के लिए उच्च जो अपनी .well-known और दावा पार्सिंग को मान्य नहीं करते हैं; तीसरे पक्ष के IdPs का उपयोग करने वाले उपभोक्ता साइटों के लिए मध्यम (प्रदाताओं के साथ पुष्टि करें)।

अंतिम निष्कर्ष

यदि आपका स्टैक FedCM के साथ साइन-इन को संभालता है (या तो IdP या RP के रूप में), तो इसे एक प्लेटफ़ॉर्म-स्तरीय API परिवर्तन के रूप में मानें: ID दावा आउटपुट को अपडेट करें, आवश्यक मेटाडेटा प्रकाशित करें, क्लाइंट nonce/त्रुटि प्रबंधन को संशोधित करें, और अब Chrome 143 में परीक्षण करें। Chrome 145 में प्रवर्तन से पहले परिवर्तनों को सुरक्षित रूप से रोल करने के लिए 143–144 संक्रमण अवधि का उपयोग करें। (developer.chrome.com)

स्रोत

आगे पढ़ें

नवीनतम डाइजेस्ट देखेंसभी डाइजेस्ट देखें