16 नव॰ 2025·8 मिनट
SSO के लिए OAuth बनाम SAML: एंटरप्राइज़ खरीदार क्या उम्मीद करते हैं
SSO के लिए OAuth बनाम SAML सरल शब्दों में समझाया गया—एंटरप्राइज़ क्या मांगते हैं, क्या बनाना चाहिए, और मौजूदा लॉगिन को कैसे चालू रखें।
SSO के लिए OAuth बनाम SAML सरल शब्दों में समझाया गया—एंटरप्राइज़ क्या मांगते हैं, क्या बनाना चाहिए, और मौजूदा लॉगिन को कैसे चालू रखें।
SSO की ज़रूरत तब तुरंत महसूस होती है जब कोई डील "टीम ट्रायल" से कंपनी-व्यापी रोल-आउट की तरफ बढ़ती है। खरीदार आपका प्रोडक्ट पसंद कर सकते हैं, लेकिन सुरक्षा और IT प्रोक्योरमेंट रोक देंगे अगर कर्मचारियों को नए पासवर्ड बनाने हों, MFA किसी और जगह मैनेज करनी पड़े, या जब लोग रोल बदलते हैं तो खाते पीछे छूट जाएँ।
कई एंटरप्राइज़ के लिए SSO सुविधा का मामला कम और नियंत्रण का मामला ज़्यादा होता है। वे एक ही जगह से लॉगिन नियम लागू करना, एक्सेस जल्दी रद्द करना, और ऑडिटर्स को दिखाना चाहते हैं कि पहचान केंद्रीय रूप से मैनेज होती है। इसलिए "OAuth vs SAML for SSO" का सवाल सेल्स साइकिल के आख़िर में आता है: यह जल्दी बताता है कि आप उनके आइडेंटिटी सेटअप में फिट बैठते हैं या नहीं।
SSO को बाद में जोड़ने से उन मान्यताओं में टूट आ सकता है जिन पर आप पहले ही भरोसा कर रहे हैं। यदि आपका मौजूदा मॉडल "एक ईमेल = एक यूज़र" है, तो SSO साझा एलियास, कई identity providers, या माइग्रेशन के दौरान पासवर्ड लॉगिन और SSO दोनों बनाए रखने जैसे एज केस लाता है। अगर अकाउंट लिंकिंग गलत हुई तो लोग एक्सेस खो सकते हैं या, उससे भी बुरा, किसी गलत टेनेंट को एक्सेस मिल सकता है।
SSO ऑनबोर्डिंग और सपोर्ट को भी बदल देता है। सही तरीके से किया जाए तो यह पासवर्ड रीसेट्स और "यह अकाउंट किसका है?" टिकट्स घटा देता है। गलत तरीके से किया जाए तो रोलआउट फंस जाते हैं, एडमिन नाराज होते हैं, और रिन्यूअल रिस्की हो सकती है क्योंकि प्रोडक्ट "ट्रायल में काम कर रहा था" पर एंटरप्राइज़ डिप्लॉयमेंट के पहले दिन फेल हो जाता है।
फैसला शायद ही किसी एक व्यक्ति का होता है। खरीदार गति चाहता है, सिक्योरिटी टीम जोखिम और ऑडिट ज़रूरतें देखती है, IT एडमिन को स्पष्ट सेटअप स्टेप्स चाहिए, एंड-यूज़र्स सहज लॉगिन चाहते हैं, और सपोर्ट अंततः लॉकआउट, माइग्रेशन और अपवाद संभालता है।
यदि आप Koder.ai जैसे प्लेटफ़ॉर्म पर ऐप बनाते हैं, तो बेहतर है कि आप SSO की पहले से योजना बना लें ताकि ग्राहक पहले से सक्रिय होने के बाद पहचान का री‑डिज़ाइन न करना पड़े।
SSO (single sign-on) का मतलब है कि आपका ग्राहक आपकी ऐप में उनका कंपनी लॉगिन इस्तेमाल करके साइन इन करे, न कि कोई अलग पासवर्ड जो आप स्टोर करते हों। वे अपने वर्क अकाउंट से साइन इन करते हैं और एक्सेस कंपनी की पॉलिसी से नियंत्रित होता है।
ये वे टर्म्स हैं जो एंटरप्राइज़ कॉल्स पर सुनने को मिलेंगी:
जब लोग "OAuth login" कहते हैं, वे अक्सर OpenID Connect (OIDC) का मतलब लेते हैं। OAuth मुख्यतः authorization के बारे में है (किसी चीज़ तक पहुँच की अनुमति)। OIDC authentication जोड़ता है (यूज़र कौन है), इसलिए इसे लॉगिन के लिए इस्तेमाल किया जा सकता है।
SAML एक पुराना, XML-आधारित SSO स्टैण्डर्ड है। एंटरप्राइज़ इसे अभी भी बहुत इस्तेमाल करते हैं क्योंकि यह प्रमाणित है, IdPs द्वारा व्यापक रूप से समर्थित है, और कई कंप्लायंस चेकलिस्ट में शामिल है।
SCIM SSO नहीं है। SCIM provisioning के लिए है: उपयोगकर्ताओं (और कभी-कभी ग्रुप्स) को ऑटोमेटिकली बनाना, अपडेट करना और निष्क्रिय करना। एक सामान्य सेटअप में साइन‑इन के लिए SAML या OIDC और साथ में SCIM होता है ताकि एक्सेस बिना मैन्युअल एडमिन काम के ऐड और रिमूव हो सके।
एंटरप्राइज़ खरीदार आमतौर पर प्रोटोकॉल विवरण से शुरू नहीं करते। वे जोखिम और नियंत्रण से शुरू करते हैं: "क्या हम अपने identity provider से एक्सेस मैनेज कर सकते हैं, और क्या हम साबित कर सकते हैं कि किसने क्या किया?"
ज़्यादातर एंटरप्राइज़ टीमें कम से कम एक एंटरप्राइज़‑फ्रेंडली विकल्प चाहती हैं, और कई दोनों चाहते हैं:
वे यह भी पूछेंगे कि सेटअप कैसे काम करता है: metadata या discovery URL, सर्टिफिकेट रोटेशन, और क्या IT बिना आपके इंजीनियर का इंतज़ार किए सेल्फ‑सर्व कर सकता है।
ऑफबोर्डिंग के बारे में अस्पष्ट होना सबसे तेज़ तरीका है एक एंटरप्राइज़ डील खोने का। वे पूछेंगे कि जब कोई कर्मचारी छोड़े, विभाग बदले, या लैपटॉप खो दे तो क्या होता है।
इन तरह के सवालों की उम्मीद रखें:
एक साधारण परिदृश्य जो उन्हें मायने देता है: एक एडमिन ने 9:02 पर एक यूज़र डिसेबल किया, और 9:03 तक वह यूज़र ऐप खोलने में सक्षम नहीं होना चाहिए, भले ही उसके पास ब्राउज़र टैब खुला हो। अगर आप उस फ्लो को स्पष्ट रूप से समझा नहीं सकते, तो और जांच चक्रों की उम्मीद करें।
OAuth मूलतः delegated access के लिए बनाया गया था: एक सिस्टम को दूसरे सिस्टम की API कॉल करने देना बिना पासवर्ड शेयर किए। कई टीमें अभी भी इसका उपयोग करती हैं (उदाहरण: कैलेंडर पढ़ने वाला एक इंटीग्रेशन)। कर्मचारी लॉगिन के लिए अधिकांश प्रोडक्ट OpenID Connect (OIDC) का उपयोग करते हैं, जो OAuth के ऊपर बैठता है और यह तय करने का स्टैण्डर्ड तरीका जोड़ता है कि यूज़र कौन है।
OIDC के साथ सामान्य सेटअप authorization code flow है। आपकी ऐप यूज़र को कंपनी के IdP पर साइन इन करने भेजती है। सफल लॉगिन के बाद, IdP आपकी ऐप को एक short‑lived authorization code भेजता है। आपका बैकएंड उस कोड का एक्सचेंज करके टोकन्स लेता है।
महत्वपूर्ण टोकन विभाजन:
OAuth बनाम SAML के बारे में व्यावहारिक तरीका: OIDC आधुनिक लॉगिन के लिए बढ़िया है जो वेब, मोबाइल और API पैटर्न में फिट बैठता है। SAML अधिक सामान्य है जब एंटरप्राइज़ क्लासिक "ऐप में साइन‑इन" हैंडशेक चाहता है और API एक्सेस को कम महत्व देता है।
जो कुछ स्टोर करना चाहिए वह सरल रखें: यूज़र का स्थिर पहचानकर्ता (subject), उनका ईमेल (यदि दिया गया है), और जिस टेनेंट कनेक्शन का उन्होंने उपयोग किया। यूज़र का पासवर्ड स्टोर न करें। लंबे समय तक रहने वाले refresh tokens भी तब तक न रखें जब तक आपको वाकई offline API एक्सेस की ज़रूरत न हो।
इसे प्रति‑कस्टमर टेनेंट के लिए काम करने लायक बनाने के लिए आपको चाहिए होगा:
सही तरीके से किया जाए तो यूज़र वापस आपकी ऐप पर आ जाता है, आप टोकन्स को वैलिडेट करते हैं, और आप अपना सामान्य सेशन बना लेते हैं बिना अपने पूरे ऑथ मॉडल को फिर से लिखे।
SAML एंटरप्राइज़ IdP को आपकी ऐप से यह कहने देता है: "यह व्यक्ति पहले से साइन इन कर चुका है, ये उनकी जानकारियाँ हैं।" IdP एक SAML assertion भेजता है, जो मूलतः एक साइन की हुई नोट होती है जिसमें यूज़र कौन है (और कभी-कभी ग्रुप या रोल जानकारी) और साथ में एक छोटा वैधता विंडो होती है।
उस नोट को भरोसेमंद बनाने के लिए SAML metadata और certificates पर निर्भर करता है। Metadata एक छोटा कॉन्फ़िग पैकेज है जो endpoints और keys को बताता है। Certificates मुख्य रूप से साइनिंग के लिए होते हैं, ताकि आपकी ऐप पुष्टि कर सके कि assertion ग्राहक के IdP से आई है और उसमें बदलाव नहीं हुआ।
दो पहचानकर्ता लगभग हर सेटअप में दिखते हैं:
यदि इनमें से कोई भी गलत है तो लॉगिन फेल हो जाता है भले ही बाकी सब कुछ सही लगे।
वास्तविक दुनिया में SAML उतना ही ऑपरेशंस है जितना कि कोड। टेनेंट‑लेवल SAML सेटिंग्स, सर्टिफिकेट रोटेशन बिना डाउनटाइम के, क्लॉक स्क्यू (कुछ मिनट भी assertions तोड़ सकते हैं), और एडमिन के लिए स्पष्ट एरर संदेश (सिर्फ "invalid response" न देकर) की योजना बनाइए।
एक सामान्य पैटर्न: कस्टमर एडमिन प्रति टेनेंट SAML सक्षम करता है, फिर आपकी ऐप सिग्नेचर को वेरिफाई करती है, चेक करती है कि assertion एक्सपायर्ड नहीं है, और ईमेल (या NameID) को मौजूदा यूज़र से मैप करती है या सुरक्षित ऑटो‑प्रोविजन नियम लागू करती है। व्यवहार में, यही OAuth vs SAML निर्णय का दिल है: SAML आमतौर पर आपको मजबूत एडमिन वर्कफ्लो बनाने पर मजबूर करता है।
OIDC और SAML के बीच चुनाव ज़्यादातर इस बारे में है कि आपका खरीदार पहले से क्या चला रहा है। कई B2B ऐप समय के साथ दोनों सपोर्ट करने लगते हैं, लेकिन आप हर ग्राहक के लिए साफ़ निर्णय ले सकते हैं और अपने ऑथ सिस्टम को predictable रख सकते हैं।
OIDC आधुनिक ऐप्स के लिए अक्सर सहज होता है। यह ब्राउज़र और मोबाइल ऐप्स के साथ फिट बैठता है, APIs के साथ अच्छा काम करता है, और आम तौर पर डिबग और एक्सटेंड करने में आसान होता है (scopes, token lifetimes, आदि)। यदि आपका एंटरप्राइज़ कस्टमर पहले से आधुनिक IdP सेटअप इस्तेमाल करता है और उनकी IT टीम OIDC से परिचित है, तो वहीं से शुरू करें।
SAML गैर‑वार्तालाप हो सकता है। कई बड़े संगठन के पास पहले से SAML प्रोग्राम और विक्रेता ऑनबोर्डिंग नियम होते हैं जैसे "सिर्फ SAML।" ऐसे मामलों में, सबसे अच्छा तरीका सरल है: SAML को एक नियंत्रित तरीके से एक बार लागू करें और इसे आपके बाकी लॉगिन सिस्टम से अलग रखें।
कुझ सवाल जो आप पूछें पहले कि आप कमिट करें:
एक त्वरित निर्णय मार्गदर्शिका:
| If the customer says... | Prefer | Why |
|---|---|---|
| "We use Entra ID and want a modern app integration" | OIDC | Better fit for web and API flows |
| "Our policy is SAML only for vendors" | SAML | Required to pass security onboarding |
| "We need both for different subsidiaries" | Both | Common in large orgs |
| "We need custom claims per app" | Either | Both support attribute mapping |
यदि आप दोनों सपोर्ट करते हैं, तो अपने ऐप के बाकी हिस्सों को संगत रखें: एक internal user model, एक session model, और एक authorization नियम सेट। SSO मेथड का सवाल होना चाहिए "यह यूज़र कौन है और वह किस टेनेंट से संबंधित है," न कि यह कि एक्सेस कैसे काम करता है को फिर से लिख दे।
सबसे पहले यह परिभाषित करें कि आपके प्रोडक्ट में "टेनेंट" का मतलब क्या है। अधिकांश B2B ऐप्स के लिए SSO संगठन या वर्कस्पेस के हिसाब से कॉन्फ़िगर किया जाता है, न कि प्रति‑यूज़र। यह चुनाव निर्धारित करता है कि आप IdP सेटिंग्स कहाँ स्टोर करेंगे, कौन उन्हें बदल सकता है, और यूज़र्स वर्कस्पेसेज़ के बीच कैसे मूव करते हैं।
इसके बाद एक लॉगिन व्यवहार चुनें जो प्रत्याश्य योग्य हो। ईमेल डोमेन रूटिंग (ईमेल टाइप करें, फिर अगर डोमेन SSO‑सक्षम है तो redirect कर दें) भ्रम को कम करती है, लेकिन आपको ठेकेदारों और बहु‑डोमेन कंपनियों जैसे एज‑केसेस संभालने होंगे। एक सादा "Continue with SSO" बटन समझने में आसान है, पर यूज़र्स गलत विकल्प चुन सकते हैं।
OIDC या SAML दोनों के लिए एक सुरक्षित बिल्ड ऑर्डर:
टेस्टिंग वैकल्पिक नहीं है। एक सैंडबॉक्स IdP और रिऐलिस्टिक डोमेन्स के साथ एक स्टेजिंग टेनेंट का उपयोग करें। हैप्पी पाथ और फेल्यर केस चलाएँ: एक्सपायर्ड सर्ट, गलत ऑडिएंस, क्लॉक स्क्यू, IdP से यूज़र हटना। SSO रोलआउट को फीचर फ्लैग की तरह ट्रीट करें।
Koder.ai जैसी प्लेटफ़ॉर्म्स इस तरह के इटरेशन को आसान बनाती हैं क्योंकि वे स्नैपशॉट और रोलबैक के साथ प्रति‑टेनेंट कॉन्फ़िगरेशन सपोर्ट करती हैं, ताकि एक खराब बदलाव एक साथ हर कस्टमर को लॉक न करे।
SSO सिर्फ एक लॉगिन बटन नहीं है। सिक्योरिटी टीमें सेशन लंबाई, ऑफबोर्डिंग, और जब कुछ गलत हो तो आप क्या प्रमाण दे सकते हैं, ये पूछेंगी। यदि आप SSO को अपने ऑथ सिस्टम का मूल हिस्सा मानकर देखें (बोल्ट‑ऑन की तरह नहीं), तो आप ज़्यादातर दर्दनाक स्केल‑अप से बच जाएंगे।
सेशन नियमों से शुरू करें। एक idle timeout और एक absolute session lifetime चुनें, और यह स्पष्ट करें कि जब कोई लैपटॉप बंद करता है और कल वापस आएगा तो क्या होगा। OIDC के साथ refresh tokens सेशन्स को अपेक्षित से लंबे समय तक जीवित रख सकते हैं, इसलिए यदि आप उन्हें उपयोग करते हैं तो सीमा रखें (rotation, max age)। SAML के साथ, ब्राउज़र सेशन्स लंबे समय तक रह सकती हैं जब तक आप re‑auth मजबूर नहीं करते।
लॉगआउट एक और जाल है। "Single logout" सार्वभौमिक नहीं है। अपने ऐप में लोकल लॉगआउट विश्वसनीय ढंग से सपोर्ट करें, और दस्तावेज़ करें कि वैश्विक लॉगआउट हर ऐप पर IdP पर निर्भर करता है।
MFA भी मिलती‑जुलती है। एंटरप्राइज़ चाहती हैं कि IdP MFA लागू करे, इसलिए आपकी ऐप को बिना फिर से प्रम्प्ट किए authenticated यूज़र स्वीकार कर लेना चाहिए। फिर भी, रिस्की एक्शन्स (डेटा एक्सपोर्ट या बिलिंग बदलना) के लिए step‑up checks सपोर्ट करना उपयोगी हो सकता है, क्योंकि हर IdP पॉलिसी पर भरोसा पूरा नहीं किया जा सकता।
यूज़र provisioning वह जगह है जहाँ एक्सेस लीक होते हैं। JIT provisioning सुविधाजनक है, पर यह किसी भी प्रमाणीकृत व्यक्ति के लिए अकाउंट बना सकता है। इनवाइट‑ओनली सुरक्षित है पर एडमिन काम बढ़ाता है। कई टीमें बीच का रास्ता अपनाती हैं: JIT की अनुमति है, पर सीमित allowed domains और (वैकल्पिक) group claims से।
SSO कॉन्फ़िगरेशन को least‑privilege रोल्स के पीछे रखें। किसी को सर्टिफिकेट रोटेट करने या IdP URL अपडेट करने के लिए सुपर‑एडमिन अधिकार नहीं होने चाहिए।
सपोर्ट के लिए, किसी एक लॉगिन को ट्रेस करने के लिए पर्याप्त लॉग रखें बिना सीक्रेट्स स्टोर किए:
यह फर्क है "हम इसे reproduce नहीं कर पा रहे" और मिनटों में एक एंटरप्राइज़ SSO आउटेज ठीक करने के बीच।
एक मिड‑मार्केट कंपनी procurement तक पहुंचती है और कहती है: "हमें साइन करने से पहले SSO चाहिए।" यह शायद दार्शनिक नहीं होता; यह एक नियंत्रण है जो उन्हें ऑनबोर्डिंग, ऑफबोर्डिंग और ऑडिट के लिए चाहिए।
अब ट्विस्ट: आप दो टीमों को बेच रहे हैं। टीम A OIDC से खुश है क्योंकि वे Okta के साथ आधुनिक ऐप्स इस्तेमाल करते हैं। टीम B SAML पर ज़ोर देती है क्योंकि उनके लेगसी टूल्स अभी भी उसी पर निर्भर हैं। यही वह जगह है जहाँ OAuth vs SAML का सवाल बहस बंद करके रोलआउट प्लान बन जाता है।
एक नियम रखें: SSO एक प्रति‑टेनेंट लॉगिन विकल्प होना चाहिए, न कि ग्लोबल रिप्लेसमेंट। मौजूदा यूज़र्स तब तक पुरानी तरह साइन‑इन कर सकते हैं जब तक टेनेंट एडमिन "SSO required" न फ्लिप कर दे।
पहली SSO लॉगिन पर, आपको सुरक्षित अकाउंट‑लिंकिंग चाहिए। एक साफ़ तरीका है: सत्यापित ईमेल पर मैच करें, टेनेंट को डोमेन (या इनवाइट) से कन्फ़र्म करें, फिर IdP पहचान को मौजूदा यूज़र से जोड़ें। अगर कोई मैच नहीं है, तो जस्ट‑इन‑टाइम यूज़र बनाएं, पर केवल तब जब एडमिन ने इसकी अनुमति दी हो।
रोल असाइनमेंट वह जगह है जहाँ डील अक्सर अटकते हैं। इसे सरल रखें: नए यूज़र्स के लिए एक डिफ़ॉल्ट रोल, और वैकल्पिक मैपिंग IdP ग्रुप्स या क्लेम्स से आपके रोल्स तक।
एडमिन साइड पर आम तौर पर उन्हें कॉन्फ़िगर करना होगा:
स्विच के दौरान लॉकआउट से बचने के लिए, SSO के बाहर एक ब्रेक‑ग्लास एडमिन अकाउंट रखें, पहले कुछ लॉगिन के लिए टेस्ट मोड चलाएँ, और कम‑से‑कम एक कन्फ़र्म्ड कार्यशील एडमिन सेशन होने तक SSO लागू न करें।
ज़्यादातर SSO घटनाएँ IdP की वजह से नहीं होतीं। वे इसलिए होती हैं क्योंकि आपकी ऐप SSO को एक सिंगल ग्लोबल स्विच मान लेती है, न कि प्रति‑कस्टमर सेटिंग।
एक क्लासिक फेल्यर टेनेंट बाउंड्रीज़ मिस करना है। एक नया IdP कॉन्फ़िग गलती से ग्लोबली सेव हो जाता है, और अचानक हर ग्राहक को आखिरी IdP पर रीडायरेक्ट किया जाने लगता है। IdP सेटिंग्स को टेनेंट से जोड़ कर रखें, और SSO हैंडशेक शुरू करने से पहले हमेशा टेनेंट रिजॉल्व करें।
अकाउंट मैचिंग अगला बड़ा जाल है। अगर आप सिर्फ ईमेल पर भरोसा करते हैं, तो आप डुप्लीकेट यूज़र्स बना देंगे या असली यूज़र्स को लॉक‑आउट कर देंगे जब उनका IdP ईमेल पहले इस्तेमाल किए गए ईमेल से अलग होगा। अपनी मर्ज पॉलिसी पहले से परिभाषित करें: आप किन पहचानकर्ताओं पर भरोसा करते हैं, ईमेल बदलने को कैसे हैंडल करेंगे, और एडमिन बिना इंजीनियर मदद के मिस्टमैच कैसे ठीक कर सकेगा।
टीमें अक्सर क्लेम्स पर ज़्यादा भरोसा कर लेती हैं। जो मिलता है उसे validate करें: issuer, audience, signature, और कि ईमेल verified है (या इसके बजाय स्थिर subject identifier का उपयोग करें)। गलत audience स्वीकार करना या unverified email लेना किसी गलत व्यक्ति को एक्सेस देने का आसान तरीका है।
जब कुछ फेल होता है, अस्पष्ट एरर लंबी सपोर्ट कॉल्स बनाते हैं। उपयोगकर्ताओं को एक स्पष्ट संदेश दें, और एडमिन को एक डायग्नोस्टिक संकेत (उदाहरण: "Audience mismatch" या "Certificate expired") दें बिना सीक्रेट्स उजागर किए।
टाइम‑संबंधित मुद्दों को शिप करने से पहले टेस्ट करें। क्लॉक स्क्यू और सर्टिफिकेट रोटेशन लॉगिन तोड़ देते हैं—अक्सर सोमवार सुबह 9 बजे।
पाँच चेक जो अधिकांश आउटेज रोकते हैं:
SSO वह जगह है जहाँ छोटी मान्यताएँ बड़े सपोर्ट टिकट में बदल जाती हैं। किसी एंटरप्राइज़ ग्राहक को यह बताने से पहले कि आप इसे सपोर्ट करते हैं, सुनिश्चित करें कि बेसिक्स आपकी प्रोडक्ट में काम कर रहे हैं, सिर्फ़ डेमो में नहीं।
स्टेजिंग वातावरण में उन चीज़ों को चलाएँ जो प्रोडक्शन की तरह हों:
एक पूरा "बुरा दिन" ड्रिल करें: एक सर्टिफिकेट रोटेट करें, एक क्लेम बदलें, या IdP URL तोड़ दें और पुष्टि करें कि आप इसे जल्दी detect कर सकते हैं।
फिर यह सुनिश्चित करें कि आपके पास टेनेंट हिसाब से SSO विफलताओं के लिए मॉनिटरिंग और अलर्ट हैं, साथ में एक रोलबैक प्लान (फीचर फ्लैग, कॉन्फ़िग रिवर्ट, या तेज़ डिप्लॉय) जिसे आपने प्रैक्टाइस किया हो।
एक स्पष्ट शुरुआत बिंदु चुनें। ज़्यादातर एंटरप्राइज़ खरीदार "Okta/Entra ID के साथ SAML" या "Google/Microsoft के साथ OIDC" माँगते हैं, और आप पहले हफ्ते में दोनों वादा नहीं करना चाहेंगे जब तक आपकी टीम तैयार न हो। तय करें कि आप पहले क्या सपोर्ट करेंगे (SAML, OIDC, या दोनों) और लिखें कि आपके लिए "done" का मतलब क्या है—प्रोडक्ट और सपोर्ट टीम के लिए।
किसी असली ग्राहक को शामिल करने से पहले एक छोटा internal demo टेनेंट बनाइए। इसे उपयोग करें पूरा फ्लो rehearse करने के लिए: SSO इनब्ल करें, लॉगिन टेस्ट करें, डोमेन तक सीमित करें, और जब कुछ गलत हो तो एक्सेस रिकवर करें। यही जगह है जहाँ आपका सपोर्ट प्लेबुक टेस्ट होता है।
एक एंटरप्राइज़ requirements डॉक रखें जो जीवित रहे। रिव्यू समय के साथ बदलते हैं, और एक जगह पर यह ट्रैक करने से एक‑ऑफ वादों को रोका जा सकता है जो बाद में ऑनबोर्डिंग तोड़ देते हैं।
एक साधारण योजना जो व्यवहार में काम करती है:
यदि आप उत्पाद पक्ष पर तेज़ी से आगे बढ़ना चाहते हैं, तो सेटिंग्स स्क्रीन और टेनेंट स्ट्रक्चर का प्रोटोटाइप Koder.ai (koder.ai) में कर सकते हैं और ग्राहक सुरक्षा प्रश्नावलियों के आते ही iterate कर सकते हैं।
उन एड‑ऑन्स की योजना बनाएं जो अक्सर SSO के तुरंत बाद आते हैं: SCIM provisioning, ऑडिट लॉग एक्सपोर्ट, और स्पष्ट अनुमतियों वाले एडमिन रोल्स। भले ही आप उन्हें तुरंत शिप न करें, खरीदार पूछेंगे, और आपका उत्तर consistent होना चाहिए।
ज़्यादातर एंटरप्राइज़ टीमें एक्सेस पर केंद्रीय नियंत्रण चाहती हैं। SSO उन्हें अपना MFA और लॉगिन नियम अपने Identity Provider पर लागू करने देता है, किसी कर्मचारी के जाने पर तेजी से एक्सेस हटाने का मौका देता है, और ऑडिट ज़रूरतें पूरी करने में मदद करता है बिना आपकी ऐप पर पासवर्ड मैनेजमेंट पर निर्भर हुए।
पहले देखें कि उनके Identity Provider क्या सपोर्ट करता है और उनकी विक्रेता ऑनबोर्डिंग नीति क्या कहती है। OIDC आधुनिक वेब और मोबाइल फ्लो के लिए अक्सर बेहतर है, जबकि SAML बड़े ग्राहकों में अक्सर अनिवार्य होता है क्योंकि यह पुराने एंटरप्राइज़ सेटअप में व्यापक रूप से इस्तेमाल होता है।
OIDC OAuth के ऊपर एक authentication लेयर है जो लॉगिन के लिए बनाया गया है। सिर्फ OAuth आमतौर पर APIs तक पहुंच देने के लिए है, न कि यह साबित करने के लिए कि यूज़र कौन है। जब आप "Sign in with the company IdP" कह रहे होते हैं, तो आमतौर पर आपका मतलब OIDC ही होता है।
नहीं। SSO साइन-इन के बारे में है, जबकि SCIM उपयोगकर्ता अकाउंट (और कभी-कभी ग्रुप) को ऑटोमेटिकली बनाना, अपडेट करना और डिएक्टिवेट करना संभालता है। एक आम एंटरप्राइज़ सेटअप में साइन-इन के लिए SAML या OIDC और साथ में SCIM ऑफबोर्डिंग और रोल-चेंज के लिए होता है।
SSO को per-tenant setting मानें, न कि ग्लोबल स्विच। पहले टेनेंट को रिजॉल्व करें (डोमेन रूटिंग, इनवाइट, या स्पष्ट ऑर्ग चयन से), फिर उस टेनेंट के IdP कॉन्फ़िगरेशन के साथ SSO हैंडशेक शुरू करें। इससे एक ग्राहक की IdP सेटिंग्स दूसरे ग्राहक के लॉगिन को प्रभावित नहीं करेंगी।
IdP से मिलने वाला स्थिर आइडेंटिफायर (उदाहरण: OIDC sub या SAML NameID) प्राथमिक लिंक के रूप में प्रयोग करें, और ईमेल को द्वितीयक विशेषता मानें जो बदल सकती है। पहली SSO लॉगिन पर, केवल तब मौजूदा अकाउंट से लिंक करें जब आप निश्चित हों कि वही व्यक्ति है और टेनेंट सही है; वरना इनवाइट या एडमिन पुष्टि माँगें।
एक ब्रेक-ग्लास एडमिन अकाउंट रखें जो SSO के बिना साइन इन कर सके, और SSO को opt-in रखें जब तक कोई एडमिन यह सत्यापित न कर दे कि यह काम कर रहा है। साथ ही एक सिंगल टॉगल दें जिससे उस टेनेंट के लिए SSO डिसेबल किया जा सके अगर IdP कॉन्फ़िगरेशन टूट जाए, ताकि सपोर्ट बिना कोड बदलाव के एक्सेस रिस्टोर कर सके।
अपने ऐप में लोकल लॉगआउट विश्वसनीय ढंग से सपोर्ट करें और स्पष्ट रूप से बताएं कि ग्लोबल साइन-आउट हर एप पर IdP की सुविधाओं और कॉन्फ़िगरेशन पर निर्भर करता है। साथ ही तेज़ एक्सेस रिवोकेशन पर ध्यान दें: सेशन्स एक्सपायर कर दें या उपयोगकर्ता स्थिति जल्दी चेक करें ताकि डिसेबल किए गए यूज़र पुराने ब्राउज़र टैब से ऐप का उपयोग न कर सकें।
टेनेंट-स्तरीय SSO एरर लॉग रखें जो यह बताएं कि क्या फेल हुआ बिना सीक्रेट्स स्टोर किए। एक correlation ID, टेनेंट, issuer/entity ID, टाइमस्टैम्प और स्पष्ट कारण जैसे signature failure, audience mismatch, या expired certificate कैप्चर करें। raw tokens, पूरी SAML assertions, client secrets या private keys लॉग में न रखें।
आपको टेनेंट-स्तरीय कॉन्फ़िगरेशन स्टोरेज, IdP सेटिंग्स मैनेज करने के लिए एक एडमिन UI, सुरक्षित अकाउंट-लिंकिंग नियम, और रोलबैक पाथ चाहिए। Koder.ai पर बिल्ड करने पर टेनेंट मॉडल पहले से प्लान करें और रोलआउट के दौरान स्नैपशॉट्स और रोलबैक का उपयोग करें ताकि एक खराब बदलाव हर ग्राहक के साइन-इन को ब्लॉक न करे।