आर्किटेक्चर निर्णय रिकॉर्ड: प्रमाणीकरण और प्राधिकरण के विकल्प

वेब एप्लिकेशन का प्रमाणीकरण (authentication) और प्राधिकरण (authorization) एप्लिकेशन और सेवाओं तक पहुँच को सुरक्षित करने की दो महत्वपूर्ण अवधारणाएँ हैं। दोनों उपयोगकर्ताओं की पहचान और अनुमतियाँ कैसे दी जाती हैं, इससे संबंधित हैं, लेकिन वे अलग-अलग पहलुओं पर केंद्रित हैं:

प्रमाणीकरण किसी उपयोगकर्ता या प्रणाली की पहचान सत्यापित करने की प्रक्रिया है।
प्राधिकरण यह निर्धारित करने की प्रक्रिया है कि प्रमाणित उपयोगकर्ता या प्रणाली किन संसाधनों या कार्यों तक पहुँच सकती है।

अब, आइए उन विशिष्ट प्रोटोकॉल और तकनीकों में उतरें जिनका आपने उल्लेख किया है, जिनका उपयोग आधुनिक वेब एप्लिकेशन में प्रमाणीकरण और प्राधिकरण के प्रबंधन के लिए आमतौर पर किया जाता है।

1. OAuth (Open Authorization)

OAuth प्राधिकरण का एक खुला मानक है। यह उपयोगकर्ता को अपने क्रेडेंशियल साझा किए बिना किसी तृतीय-पक्ष एप्लिकेशन को अपने संसाधनों तक सीमित पहुँच देने की अनुमति देता है। मुख्य विचार प्रत्यायोजित पहुँच (delegated access) है। OAuth का प्रायः उन स्थितियों में उपयोग होता है जहाँ उपयोगकर्ता तृतीय-पक्ष को सीधे अपना उपयोगकर्ता नाम और पासवर्ड दिए बिना तृतीय-पक्ष सेवा में लॉग इन कर सकते हैं (जैसे Google से साइन इन करना)।

प्रवाह: OAuth में सामान्यतः टोकन-आधारित प्रवाह होता है, जिसमें प्राधिकरण सर्वर तृतीय-पक्ष एप्लिकेशन को एक एक्सेस टोकन जारी करता है। यह टोकन उपयोगकर्ता की अनुमतियों को दर्शाता है, और एप्लिकेशन इसका उपयोग किसी API से उपयोगकर्ता का डेटा या संसाधन प्राप्त करने के लिए करता है।
उदाहरण: कोई उपयोगकर्ता अपने Google खाते से किसी तृतीय-पक्ष ऐप में साइन इन करता है। Google उपयोगकर्ता की पहचान सत्यापित करता है और फिर एक टोकन देता है जो तृतीय-पक्ष ऐप को कुछ Google डेटा (जैसे Google Calendar) तक पहुँचने की अनुमति देता है।

OAuth प्रमाणीकरण को सीधे नहीं संभालता; यह पहुँच देने से संबंधित है। प्रमाणीकरण के लिए, OAuth को प्रायः अन्य प्रोटोकॉल, जैसे OpenID Connect, के साथ जोड़ा जाता है।

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) OAuth 2.0 के ऊपर बनी पहचान परत है जो OAuth की प्राधिकरण क्षमताओं में प्रमाणीकरण जोड़ती है। मूलतः, OpenID Connect OAuth का विस्तार करके उपयोगकर्ता प्रमाणीकरण को संभालता है और एप्लिकेशन को उपयोगकर्ता की पहचान सत्यापित करने का मानकीकृत तरीका देता है।

प्रवाह: जब कोई उपयोगकर्ता OpenID Connect से लॉग इन करता है, तो तृतीय-पक्ष एप्लिकेशन (OAuth एक्सेस टोकन के अतिरिक्त) एक ID टोकन माँगता है। ID टोकन में उपयोगकर्ता के बारे में जानकारी (जैसे उसका उपयोगकर्ता नाम, ईमेल और अन्य दावे) होती है। इससे एप्लिकेशन जान पाता है कि उपयोगकर्ता कौन है और क्या वह प्रमाणित है।
उदाहरण: अपने Google खाते (Google OpenID Connect प्रदाता है) से Slack जैसी सेवा में लॉग इन करने में OpenID Connect के माध्यम से प्रमाणीकरण होता है, जबकि OAuth आपके Google संसाधनों तक पहुँच का प्रबंधन करता है।

OIDC तृतीय-पक्ष ऐप के लिए उपयोगकर्ताओं को प्रमाणित करना आसान बनाता है, जबकि साथ ही इस पर सूक्ष्म नियंत्रण भी रखने देता है कि वे ऐप किन संसाधनों तक पहुँच सकते हैं।

3. SAML (Security Assertion Markup Language)

SAML एक पुराना, XML-आधारित मानक है जिसका उपयोग पक्षों के बीच प्रमाणीकरण और प्राधिकरण डेटा के आदान-प्रदान के लिए होता है, विशेष रूप से सिंगल साइन-ऑन (SSO) परिदृश्यों में। यह मुख्यतः एंटरप्राइज़ परिवेशों में उपयोग होता है, ताकि उपयोगकर्ता एक बार प्रमाणित होकर क्रेडेंशियल दोबारा डाले बिना कई एप्लिकेशन तक पहुँच सकें।

प्रवाह: उपयोगकर्ता पहले पहचान प्रदाता (IdP) से प्रमाणित होता है। IdP एक हस्ताक्षरित SAML कथन (assertion) बनाता है जिसमें उपयोगकर्ता की पहचान और संबंधित विशेषताएँ होती हैं। यह कथन सेवा प्रदाता (SP) को भेजा जाता है, जो इसका उपयोग एप्लिकेशन तक पहुँच को अधिकृत करने के लिए करता है।
उदाहरण: कोई कर्मचारी अपने कॉर्पोरेट पोर्टल (IdP) में लॉग इन करता है और क्रेडेंशियल दोबारा डाले बिना ईमेल, CRM आदि अन्य प्रणालियों में अपने-आप लॉग इन हो जाता है। प्रमाणीकरण प्रक्रिया IdP द्वारा भेजे गए SAML कथन पर आधारित होती है।

SAML का सामान्यतः एंटरप्राइज़ SSO समाधानों में उपयोग होता है और कॉर्पोरेट परिवेश के वेब एप्लिकेशन के लिए अच्छा काम करता है, लेकिन OAuth/OIDC की तुलना में यह मोबाइल के लिए कम अनुकूल है।

4. WS-Federation (Web Services Federation)

WS-Federation सिंगल साइन-ऑन (SSO) के लिए प्रयुक्त एक और प्रोटोकॉल है, विशेष रूप से Microsoft-आधारित एंटरप्राइज़ परिवेशों में। यह WS- (Web Services)* विनिर्देशों के परिवार का हिस्सा है और विभिन्न सुरक्षा डोमेन (जैसे विभिन्न संगठनों के बीच या विभिन्न सेवाओं के बीच) में पहचान संघ (identity federation) की अनुमति देता है।

प्रवाह: WS-Federation एक विश्वसनीय पहचान प्रदाता (IdP) को उपयोगकर्ताओं को प्रमाणित करने और ऐसे टोकन जारी करने की अनुमति देता है जिनका उपयोग सेवा प्रदाता प्राधिकरण के लिए कर सके। यह SAML के समान है लेकिन अक्सर उन परिदृश्यों में उपयोग होता है जो Microsoft तकनीकों पर बहुत निर्भर हैं।
उदाहरण: कोई उपयोगकर्ता Microsoft Azure Active Directory (AD) द्वारा होस्ट किए गए एंटरप्राइज़ एप्लिकेशन में लॉग इन करता है, और उसकी पहचान का उपयोग तृतीय-पक्ष विक्रेताओं द्वारा होस्ट किए गए एप्लिकेशन सहित अन्य संघीय सेवाओं तक पहुँचने के लिए किया जा सकता है।

हालाँकि कई आधुनिक वेब परिवेशों में WS-Federation का स्थान बड़े पैमाने पर OAuth 2.0 और OpenID Connect जैसे नए प्रोटोकॉल ने ले लिया है, यह अब भी पुरानी प्रणालियों में, विशेषकर Microsoft-केंद्रित एंटरप्राइज़ में, उपयोग होता है।

5. LDAP (Lightweight Directory Access Protocol)

LDAP डायरेक्टरी सेवाओं तक पहुँचने और उन्हें प्रबंधित करने के लिए उपयोग होने वाला प्रोटोकॉल है, जिसका आमतौर पर केंद्रीकृत डायरेक्टरी (जिसे प्रायः डायरेक्टरी सेवा कहा जाता है) में उपयोगकर्ता क्रेडेंशियल संग्रहीत करने और पहुँच नियंत्रण प्रबंधित करने के लिए उपयोग होता है। LDAP विशेष रूप से प्रमाणीकरण या प्राधिकरण के बारे में नहीं है, बल्कि पहचान डेटा को संग्रहीत और पुनर्प्राप्त करने के लिए उपयोग होता है, जिसका उपयोग फिर उन प्रक्रियाओं में किया जाता है।

प्रमाणीकरण: LDAP किसी एप्लिकेशन को डायरेक्टरी सेवा से क्रेडेंशियल (जैसे पासवर्ड) के लिए क्वेरी करके उपयोगकर्ताओं को प्रमाणित करने देता है।
प्राधिकरण: यह उपयोगकर्ता भूमिकाओं और अनुमतियों का भी प्रबंधन करता है, जिससे यह निर्धारित करने में मदद मिलती है कि उपयोगकर्ता की कुछ संसाधनों तक पहुँच है या नहीं।
उदाहरण: कई उद्यम प्रमाणीकरण और प्राधिकरण के लिए LDAP-आधारित डायरेक्टरी (जैसे Active Directory) का उपयोग करते हैं, विशेषकर Windows परिवेशों में।

LDAP उद्यमों के लिए आंतरिक प्रणालियों में उपयोगकर्ता पहुँच प्रबंधित करने हेतु महत्वपूर्ण है, लेकिन आधुनिक वेब संदर्भ में, अधिक संपूर्ण पहचान प्रबंधन के लिए LDAP को प्रायः SAML या OAuth जैसे अन्य प्रोटोकॉल के साथ एकीकृत किया जाता है।

6. सोशल SSO प्रदाता

Facebook, Google, Twitter, GitHub और अन्य जैसे सोशल सिंगल साइन-ऑन (SSO) प्रदाता उपयोगकर्ताओं को अपने सोशल मीडिया क्रेडेंशियल से तृतीय-पक्ष एप्लिकेशन में प्रमाणित होने देते हैं। यह एक प्रकार का OAuth-आधारित प्रमाणीकरण है जहाँ तृतीय-पक्ष सेवा (जैसे Google) पहचान प्रदाता है।

प्रवाह: उपयोगकर्ता "Google से लॉग इन करें" (उदाहरण के लिए) पर क्लिक करता है। ऐप Google पर रीडायरेक्ट करता है, जहाँ उपयोगकर्ता लॉग इन करता है (यदि पहले से लॉग इन नहीं है)। फिर Google तृतीय-पक्ष ऐप को एक एक्सेस टोकन या ID टोकन देता है, जिसका उपयोग उपयोगकर्ता को प्रमाणित करने और संभवतः उसका डेटा एक्सेस करने के लिए किया जा सकता है।
उदाहरण: कई एप्लिकेशन आपको अपने Google या Facebook क्रेडेंशियल से लॉग इन करने देते हैं। ऐप आपकी पहचान सत्यापित करने और, कुछ मामलों में, कुछ सोशल मीडिया डेटा एक्सेस करने के लिए पर्दे के पीछे OAuth या OpenID Connect का उपयोग करेगा।

सोशल SSO प्रमाणीकरण का सुविधाजनक और व्यापक रूप से अपनाया गया तरीका है क्योंकि यह उन उपयोगकर्ताओं के लिए घर्षण कम करता है जो शायद एक और उपयोगकर्ता नाम और पासवर्ड नहीं बनाना चाहते।

अंतरों का सारांश:

OAuth: प्राधिकरण के लिए उपयोग होता है, तृतीय-पक्ष ऐप को क्रेडेंशियल उजागर किए बिना उपयोगकर्ता डेटा तक पहुँचने देता है।
OpenID Connect: प्रमाणीकरण प्रदान करने के लिए OAuth का विस्तार करता है, जिससे ऐप उपयोगकर्ता की पहचान सत्यापित कर सकते हैं।
SAML: SSO के लिए प्रयुक्त XML-आधारित प्रोटोकॉल, प्रायः एंटरप्राइज़ परिवेशों में।
WS-Federation: पहचान संघ के लिए Microsoft-विशिष्ट प्रोटोकॉल, जो पुरानी प्रणालियों में उपयोग होता है।
LDAP: उपयोगकर्ताओं को प्रमाणित करने और प्राधिकरण प्रबंधित करने के लिए डायरेक्टरी सेवाओं को क्वेरी करने का प्रोटोकॉल।
सोशल SSO प्रदाता: OAuth-आधारित प्रणालियाँ (जैसे Google, Facebook) जो तृतीय-पक्ष ऐप को उपयोगकर्ताओं को उनके सोशल मीडिया क्रेडेंशियल से प्रमाणित करने देती हैं।

इनमें से प्रत्येक तकनीक की अपनी शक्तियाँ और उपयोग के मामले हैं, और आधुनिक एप्लिकेशन में आप सुरक्षा के विभिन्न पहलुओं के लिए इनके संयोजन का उपयोग होता देख सकते हैं (जैसे API पहुँच के लिए OAuth/OIDC, एंटरप्राइज़ SSO के लिए SAML)।