OIDC या SAML: आपको असल में किसकी ज़रूरत है

B2B सॉफ़्टवेयर बनाने वाली हर टीम उसी दोराहे पर पहुँचती है जब पहली बार कोई गंभीर ग्राहक कहता है, "हमें SSO चाहिए।" दो संक्षिप्त नाम, OIDC और SAML, दोनों खुद को जवाब बताते हैं, और इंटरनेट तुलना-तालिकाओं से भरा पड़ा है जो आपको बताती हैं कि SAML "एंटरप्राइज़" है और OIDC "आधुनिक" है, और आपको ठीक उतना ही उलझा हुआ छोड़ देती हैं जितने आप पहले थे। यह रहा वह संस्करण जो असल में आपको शिप करने में मदद करता है।

ये क्या हैं

SAML 2005 का है और यह XML है। एक आइडेंटिटी प्रोवाइडर एक असर्शन पर हस्ताक्षर करता है ("यह [email protected] है, ये रहे उसके समूह") और उसे आपके ऐप पर पोस्ट कर देता है, जो हस्ताक्षर की जाँच करता है और उसे लॉग इन कर देता है। इसे ब्राउज़र और वर्कफ़ोर्स आइडेंटिटी के लिए बनाया गया था, उस दौर में जब "एंटरप्राइज़" का मतलब ऑन-प्रेम Active Directory और एक SOAP स्टैक होता था। यह वाचाल है, यह पुराना है, और यह बड़े संगठनों के अंदर बिल्कुल हर जगह मौजूद है, और इसके बारे में यही एक तथ्य है जो आपके लिए मायने रखता है।

OIDC 2014 का है और यह JSON तथा JWT है, जो OAuth 2.0 के ऊपर बैठा है। एक आइडेंटिटी प्रोवाइडर एक ID टोकन जारी करता है जिसे आपका ऐप वैलिडेट करता है। इसे आधुनिक वेब के लिए बनाया गया था: SPA, मोबाइल ऐप, API, सोशल लॉगिन। यह ज़्यादा साफ़-सुथरा है, उन चीज़ों के लिए बेहतर तरीके से परिभाषित है जो आप आज असल में बनाते हैं, और यही वह प्रोटोकॉल है जिसे अधिकांश नई आइडेंटिटी प्रणालियाँ अब बोलती हैं।

कब कौन जीतता है

"मुझे कौन-सा बनाना चाहिए" का ईमानदार जवाब यह है कि चुनने का मौका आपको लगभग कभी नहीं मिलता। आप वही बनाते हैं जो आपके ग्राहक के IT विभाग ने चुना है, और उन्होंने वह आपके बारे में सुनने से बहुत पहले ही चुन लिया था।

• Okta, Entra ID, या Google Workspace पर मौजूद कोई ग्राहक आम तौर पर दोनों में से कुछ भी कर सकता है, और OIDC ज़्यादा बेहतर रास्ता है।
• किसी पुराने ADFS, किसी लीगेसी ऑन-प्रेम IdP, या 2016 में लिखी गई किसी ख़रीद-चेकलिस्ट पर मौजूद ग्राहक आपको SAML मेटाडेटा का एक टुकड़ा और एक कैलेंडर इनवाइट थमा देगा, और बस यहीं चर्चा ख़त्म।
• आपके अपने फ़र्स्ट-पार्टी ऐप, आपका डैशबोर्ड और आपका मोबाइल क्लाइंट, OIDC चाहते हैं, बस। अपने ख़ुद के React ऐप में किसी यूज़र को लॉग इन कराने के लिए आप SAML की ओर कभी हाथ नहीं बढ़ाएँगे।

तो मैदान साफ़-साफ़ बँट जाता है: आधुनिक और फ़र्स्ट-पार्टी के लिए OIDC, और "क्योंकि एंटरप्राइज़ ने ऐसा कहा" के लिए SAML। पर्याप्त एंटरप्राइज़ों को बेचिए और आपसे दोनों माँगे जाएँगे। किसी दिन नहीं। बार-बार।

वे पेच, जहाँ इसे ख़ुद बनाना महँगा पड़ने लगता है

SAML की दिक़्क़त यह है कि यह एक signed-XML प्रोटोकॉल है, और signed XML अनुप्रयुक्त क्रिप्टोग्राफ़ी में सबसे भरोसेमंद रूप से ख़तरनाक चीज़ों में से एक है। SAML सिग्नेचर वेरिफ़िकेशन को ग़लत करने के तरीके कई हैं और मशहूर हैं:

• Signature wrapping (XSW): एक हमलावर हस्ताक्षरित एलिमेंट को हटा देता है और वहाँ एक अहस्ताक्षरित, जाली असर्शन घुसा देता है जहाँ आपका पार्सर असल में पढ़ता है। अगर आप हस्ताक्षर की जाँच और असर्शन को पढ़ना दो अलग-अलग चरणों के रूप में करते हैं, तो आप शायद असुरक्षित हैं, और लगभग हर पहला इम्प्लीमेंटेशन ठीक यही करता है।
• Canonicalization और comment injection: बग़ों का 2018 वाला वर्ग जहाँ [email protected]<!---->.evil.com सिग्नेचर जाँच के लिए एक तरह से और आपके कोड द्वारा पढ़ी जाने वाली स्ट्रिंग के लिए दूसरी तरह से canonicalize होता है, तो आप ख़ुशी-ख़ुशी ग़लत व्यक्ति को ऑथेंटिकेट कर देते हैं। असली CVE, कई बड़ी लाइब्रेरियाँ।
• ज़्यादा चुपके वाले: रिस्पॉन्स पर हस्ताक्षर करना लेकिन असर्शन पर नहीं, अहस्ताक्षरित असर्शन स्वीकार करना, IdP द्वारा दिए गए issuer पर बिना उसे पिन किए भरोसा करना, असर्शन की वैधता-अवधि को ग़लत करना। हर एक अपने आप में एक जोखिम है, और हर एक को ऐसे लोगों ने प्रोडक्शन में शिप किया है जो जानते थे कि वे क्या कर रहे हैं।

OIDC काफ़ी हद तक ज़्यादा समझदार है, लेकिन यह तीखे किनारों से मुक्त नहीं है। आपको फिर भी सही claims (iss, aud, exp, और nonce) को वैलिडेट करना होता है, PKCE इस्तेमाल करना होता है, कब का मर चुके implicit flow को मना करना होता है, और JWKS को इस तरह रोटेट और कैश करना होता है कि ऐसी key से हस्ताक्षरित किसी टोकन को रिजेक्ट न कर दें जिसे आपने अभी तक फ़ेच नहीं किया है। फ़र्क़ यह है कि OIDC के जाल प्रलेखित हैं, JSON-आकार के हैं, और अधिकांश लाइब्रेरियों में डिफ़ॉल्ट रूप से सही ढंग से संभाले जाते हैं। SAML के जाल XML-आकार के हैं और इन्होंने आपसे कहीं बेहतर संसाधन वाली सुरक्षा टीमों को निगल लिया है।

असली जवाब

"OIDC या SAML" ग़लत सवाल है, क्योंकि एक B2B प्रोडक्ट के लिए सही जवाब है "हाँ।" आपके आधुनिक ग्राहक और आपके अपने ऐप OIDC चाहते हैं। आपके एंटरप्राइज़ ग्राहक एक ऐसी समय-सीमा पर SAML अनिवार्य कर देंगे जो आपके नियंत्रण में नहीं है। किसी एक के लिए बनाइए, और तीसरी सेल्स कॉल उसे तोड़ देगी।

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

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