OAuth क्या है?

विभिन्न वेबसाइट्स के लिए नए खाते बनाना हमेशा से परेशानी भरा रहा है। इनमें से अधिकांश काम अनावश्यक होते हैं, क्योंकि इन सभी में उपयोगकर्ता की एक ही जानकारी होती है, जैसे नाम और फोन नंबर।

"क्या यह संभव है कि एक ऐप को मेरे डेटा तक पहुंचने की अनुमति दी जाए बिना मेरा पासवर्ड दिए?"

OAuth एक मानक है जो केंद्रीकृत प्राधिकरण प्रदान करके इस समस्या को हल करने का प्रयास करता है।

OAuth, जो "ओपन ऑथराइजेशन" के लिए खड़ा है, एक ओपन स्टैंडर्ड है जो एक्सेस डेलिगेशन के लिए है। यह आपको (संसाधन मालिक) को एप्लिकेशन और वेबसाइट्स के बीच जानकारी साझा करने की अनुमति देता है बिना आपके पासवर्ड को उजागर किए। यह व्यापक रूप से उपयोग किया जाता है, और आप शायद रोजाना OAuth सेवाओं का उपयोग करते हैं। उदाहरण के लिए, GeeksforGeek पर लॉग इन करने के लिए, आप अपने Google खाते का उपयोग करके लॉग इन करने का विकल्प चुन सकते हैं। ऐसा करके, आप GeeksforGeek को अपने Google खाते पर कुछ जानकारी, जैसे उपयोगकर्ता नाम, प्रोफाइल चित्र आदि, तक पहुंचने की अनुमति देते हैं।

OAuth साइन इन उदाहरण

OAuth का इतिहास

OAuth 1.0 प्रोटोकॉल RFC 5849 के रूप में अप्रैल 2010 में प्रकाशित किया गया था, जो एक सूचनात्मक अनुरोध टिप्पणी (Request for Comments) था।

OAuth 2.0 प्रोटोकॉल RFC 6749 के रूप में प्रकाशित किया गया था, और OAuth 2.0 बेयरर टोकन उपयोग RFC 6750 के रूप में अक्टूबर 2012 में प्रकाशित किया गया था।

हालांकि OAuth 1.0 के अनुभव पर आधारित होने के बावजूद, OAuth 2.0 OAuth 1.0 का पूरी तरह से पुनर्लेखन है, जो केवल समग्र लक्ष्य और सामान्य उपयोगकर्ता अनुभव साझा करता है। OAuth 2.0 OAuth 1.0 के साथ पिछड़ा संगत नहीं है।

OAuth 2.0 कैसे काम करता है

OAuth प्रोटोकॉल में, संसाधन मालिक के उपयोगकर्ता नाम और पासवर्ड का उपयोग करने के बजाय संरक्षित संसाधनों तक पहुंचने के लिए, क्लाइंट एक एक्सेस टोकन का उपयोग करता है। क्लाइंट संसाधन मालिक की अनुमति पर प्राधिकरण सर्वर से एक्सेस टोकन प्राप्त करता है। संसाधन मालिक को क्लाइंट को प्राधिकरण देने के लिए, उसे पहले एप्लिकेशन पर प्रमाणित होना होगा। और चूंकि प्रमाणीकरण केवल संसाधन मालिक और एप्लिकेशन के बीच हुआ था, तीसरे पक्ष के क्लाइंट को संसाधन मालिक की किसी भी निजी जानकारी का पता नहीं चलता है।

हम देख सकते हैं कि OAuth प्रोटोकॉल को लागू करने से तीसरे पक्ष के क्लाइंट की प्रमाणीकरण प्रक्रिया को काफी सरल बनाया जा सकता है। इसे केवल उपयोगकर्ता से प्राधिकरण प्राप्त करने, एक्सेस टोकन का अनुरोध करने, उसका उपयोग करने और उपयोगकर्ता जानकारी (संरक्षित संसाधन) प्राप्त करने की आवश्यकता होती है। इसे नए उपयोगकर्ताओं को खाते पंजीकृत करने या उनकी साख को उजागर करने की आवश्यकता नहीं होगी, इस प्रकार हमले की सतह को कम करके और नेटवर्क सुरक्षा को बढ़ाकर।

यह ध्यान देने योग्य है कि OAuth प्रमाणीकरण नहीं है। यहां Auth प्राधिकरण है। उपयोगकर्ता एप्लिकेशन में लॉग इन नहीं करता है। यह केवल तीसरे पक्ष के एप्लिकेशन को उसकी कुछ जानकारी प्राप्त करने की अनुमति देता है।

OAuth की प्राधिकरण प्रक्रिया

भूमिकाएं

OAuth चार भूमिकाएं परिभाषित करता है:

क्लाइंट - वह एप्लिकेशन जो आपके (संसाधन मालिक) डेटा तक पहुंचना चाहता है और संसाधन मालिक की ओर से और उसके प्राधिकरण के साथ संरक्षित संसाधन अनुरोध करता है।

संसाधन मालिक - एक उपयोगकर्ता जो संसाधन सर्वर में डेटा का मालिक है, क्लाइंट की सेवा का उपयोग करना चाहता है और प्राधिकरण सर्वर पर एक खाता है। उदाहरण के लिए, मैं अपने Facebook प्रोफाइल का संसाधन मालिक हूं, और मैं GeeksforGeeks की सेवा का उपयोग करना चाहता हूं।

प्राधिकरण सर्वर - OAuth का मुख्य इंजन। संसाधन मालिक को सफलतापूर्वक प्रमाणित करने और प्राधिकरण प्राप्त करने के बाद क्लाइंट को एक्सेस टोकन जारी करता है।

संसाधन सर्वर - वह सर्वर जो डेटा संग्रहीत करता है जिसे क्लाइंट चाहता है, एक्सेस टोकन का उपयोग करके संरक्षित संसाधन अनुरोधों को स्वीकार करने और उनका जवाब देने में सक्षम है।

OAuth प्रोटोकॉल प्रवाह

oauth प्रोटोकॉल प्रवाह

चरण A: तीसरे पक्ष का एप्लिकेशन उपयोगकर्ता से प्राधिकरण का अनुरोध करता है

चरण B: तीसरे पक्ष का एप्लिकेशन एक प्राधिकरण अनुदान प्राप्त करता है, जो संसाधन मालिक के प्राधिकरण का प्रतिनिधित्व करने वाला एक प्रमाणपत्र है

चरण C: तीसरे पक्ष का एप्लिकेशन प्राधिकरण अनुदान का उपयोग करके एक्सेस टोकन का अनुरोध करता है

चरण D: प्राधिकरण सर्वर क्लाइंट को प्रमाणित करता है और प्राधिकरण अनुदान को मान्य करता है, यदि मान्य है, तो यह तीसरे पक्ष के एप्लिकेशन को एक्सेस टोकन जारी करता है

चरण E: तीसरे पक्ष का एप्लिकेशन एक्सेस टोकन का उपयोग करके संसाधन सर्वर से संरक्षित संसाधनों का अनुरोध करता है

चरण F: संसाधन सर्वर एक्सेस टोकन को मान्य करता है और यदि मान्य है तो अनुरोध को पूरा करता है

प्राधिकरण कोड और एक्सेस टोकन

प्राधिकरण सर्वर से एक्सेस टोकन प्राप्त करने के लिए चार प्रकार के प्राधिकरण अनुदान हैं। हम यहां केवल प्राधिकरण कोड विधि के बारे में बात करेंगे, क्योंकि यह सबसे सुरक्षित और सबसे आम विधि है।

oauth प्रवाह - प्राधिकरण कोड मोड

चरण A: तीसरे पक्ष का एप्लिकेशन उपयोगकर्ता को एक प्राधिकरण विधि चुनने देता है, जैसे GitHub, और फिर उपयोगकर्ता को client_id और redirect_uri जैसे पैरामीटर के साथ प्राधिकरण सर्वर पर पुनर्निर्देशित करता है

अनुरोध नमूना:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

चरण B: उपयोगकर्ता लॉग इन करता है और प्राधिकरण देता है

चरण C: प्राधिकरण सर्वर उपयोगकर्ता को redirect_uri के अनुसार तीसरे पक्ष के एप्लिकेशन के बैकएंड पर पुनर्निर्देशित करता है, प्राधिकरण कोड प्रदान करता है

प्रतिक्रिया नमूना:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

चरण D: तीसरे पक्ष का एप्लिकेशन प्राधिकरण कोड का उपयोग करके प्राधिकरण सर्वर से एक्सेस टोकन का आदान-प्रदान करता है

अनुरोध उदाहरण:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

चरण E: प्राधिकरण सर्वर मान्य करता है और एक्सेस टोकन लौटाता है

प्राधिकरण सर्वर से प्रतिक्रिया नमूना:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

एक ठोस उदाहरण

बॉब अपने Amazon ऑर्डर को सुंदर ढंग से प्रिंट करने के लिए Rabbit नामक सॉफ्टवेयर का उपयोग करना चाहता है।

संसाधन मालिक -> बॉब

क्लाइंट (तीसरे पक्ष का एप्लिकेशन) -> सॉफ्टवेयर Rabbit

प्राधिकरण सर्वर -> Amazon का प्राधिकरण सर्वर

संसाधन सर्वर -> Amazon का डेटाबेस जो ऑर्डर जानकारी संग्रहीत करता है

संरक्षित संसाधन -> Amazon पर बॉब की ऑर्डर जानकारी

OAuth प्रवाह उदाहरण - Amazon ऑर्डर

प्राधिकरण कोड और एक्सेस टोकन को अलग-अलग क्यों प्राप्त किया जाना चाहिए?

प्राधिकरण कोड और एक्सेस टोकन को अलग-अलग प्राप्त करने का उद्देश्य सुरक्षा उपायों को सुनिश्चित करना है।

OAuth2 प्रोटोकॉल में, प्राधिकरण कोड एक अस्थायी कोड है जिसे क्लाइंट एक्सेस टोकन के लिए एक्सचेंज करेगा। कोड प्राधिकरण सर्वर से प्राप्त किया जाता है, जहां उपयोगकर्ता (संसाधन मालिक) को यह देखने का मौका मिलता है कि क्लाइंट कौन सी जानकारी का अनुरोध कर रहा है और अनुरोध को स्वीकार या अस्वीकार कर सकता है।

एक बार जब उपयोगकर्ता सफलतापूर्वक लॉग इन करता है और प्राधिकरण देता है, तो उसे URL में एक अस्थायी प्राधिकरण कोड के साथ एप्लिकेशन पर पुनर्निर्देशित किया जाता है।

यह प्राधिकरण कोड आमतौर पर दस मिनट के लिए और केवल एक बार के लिए मान्य होता है। छोटी वैधता अवधि उपयोगकर्ता की जानकारी के लीक होने के जोखिम को कम करती है यदि यह चोरी हो जाती है। इसके विपरीत, access_token की वैधता अवधि अपेक्षाकृत लंबी होती है, आमतौर पर 1 से 2 घंटे। यदि यह लीक हो जाता है, तो यह उपयोगकर्ताओं के डेटा सुरक्षा के लिए अधिक खतरा पैदा कर सकता है।

इसके अलावा, एक्सेस टोकन के लिए एक्सचेंज करने के लिए, क्लाइंट को प्राधिकरण कोड के अलावा client ID और client secret प्रदान करने की आवश्यकता होगी। प्राधिकरण सर्वर को क्लाइंट को प्रमाणित करने और यह जांचने के लिए इन पैरामीटर की आवश्यकता होती है कि एक्सेस टोकन का अनुरोध करने वाला विश्वसनीय है। यदि प्राधिकरण कोड दुर्भाग्यवश लीक हो जाता है, लेकिन हैकर के पास client ID और client secret नहीं है, तो वह अभी भी एक्सेस कोड प्राप्त नहीं कर पाएगा। यहां तक कि अगर उसके पास किसी तरह client ID और client secret है, तो उसे अभी भी क्लाइंट-सर्वर के साथ दौड़ना होगा, क्योंकि प्राधिकरण कोड केवल एक बार के लिए होता है। यह तंत्र संभावित हमलों की कठिनाई को काफी बढ़ा देता है। यदि हम प्राधिकरण कोड प्राप्त करने के चरण को छोड़ देते हैं और सीधे एक्सेस टोकन लौटाते हैं, तो हमलावर आसानी से उपयोगकर्ता की जानकारी चुराने के लिए एक्सेस टोकन का उपयोग कर सकता है।

OIDC (OpenID Connect)

प्राधिकरण के लिए OAuth का उपयोग करने का उद्देश्य क्या है? यह उपयोगकर्ता के बारे में सभी प्रकार की जानकारी प्राप्त करना है। हम आउटपुट को मानकीकृत क्यों नहीं कर सकते ताकि तीसरे पक्ष के एप्लिकेशन इसे सीधे उपयोग कर सकें?

OIDC यह मानकीकरण करता है।

OIDC यह कैसे करता है? सरल शब्दों में, यह access token के साथ एक अतिरिक्त JWT प्रारूप id_token लौटाता है जिसमें उपयोगकर्ता की मूल जानकारी होती है। तीसरे पक्ष के एप्लिकेशन id_token पर हस्ताक्षर एल्गोरिथ्म की जांच करके और सार्वजनिक कुंजी के साथ हस्ताक्षर को सत्यापित करके उपयोगकर्ता की जानकारी प्राप्त कर सकते हैं।

इसके अलावा, OIDC UserInfo एंडपॉइंट प्रदान करता है। तीसरे पक्ष की सेवाएं एक्सेस टोकन का उपयोग करके इस एंडपॉइंट तक पहुंच सकती हैं और उपयोगकर्ता के बारे में अतिरिक्त जानकारी प्राप्त कर सकती हैं।

OIDC की एक और विशेषता Single Sign On (SSO) और Single Log Out (SLO) है। SSO उपयोगकर्ता अनुभव को बेहतर बनाता है क्योंकि यह उपयोगकर्ता को हर बार साख प्रदान किए बिना विभिन्न क्लाइंट्स के साथ प्रमाणित सत्र रखने की अनुमति देता है। जब तक उपयोगकर्ता एक एप्लिकेशन में सफलतापूर्वक लॉग इन करता है, तब तक अन्य एप्लिकेशन में लॉग इन करते समय पासवर्ड दोबारा दर्ज करने की आवश्यकता नहीं होती है।

SLO सुरक्षा को बेहतर बनाता है क्योंकि यह सुनिश्चित करता है कि उपयोगकर्ता द्वारा सिंगल लॉगआउट शुरू करने के बाद SSO सत्र से कोई सक्रिय सत्र नहीं बचा है। उपयोगकर्ताओं को केवल एक बार लॉग आउट करने की आवश्यकता होती है और सभी सत्र समाप्त हो जाते हैं, जिससे उन्हें हाईजैक या दुरुपयोग से बचाया जा सकता है।

यह ध्यान देने योग्य है कि OIDC किसी विशिष्ट प्रमाणीकरण विधि, जैसे पासवर्ड या चेहरे की पहचान, को मानकीकृत नहीं करता है। इसके बजाय, यह निर्दिष्ट करता है कि प्रमाणीकरण को केंद्रीकृत प्रमाणीकरण प्रदाता को कैसे सौंपा जाए, प्रमाणीकरण के बाद हमें क्या मिलता है - id token, इस टोकन को कैसे सत्यापित किया जाता है - JWT प्रारूप, और इस id token में कौन सी उपयोगकर्ता जानकारी होती है। इसलिए, तीसरे पक्ष के एप्लिकेशन को अब पहिया का पुनः आविष्कार करने की आवश्यकता नहीं है।

APISIX का OAuth/OIDC समर्थन

Apache APISIX एक ओपन-सोर्स क्लाउड-नेटिव API गेटवे है। यह एक गतिशील, रीयल-टाइम, उच्च-प्रदर्शन API गेटवे है और आप इसका उपयोग पारंपरिक उत्तर-दक्षिण ट्रैफिक के साथ-साथ सेवाओं के बीच पूर्व-पश्चिम ट्रैफिक को संभालने के लिए कर सकते हैं। इसका उपयोग k8s इन्ग्रेस कंट्रोलर के रूप में भी किया जा सकता है।

चूंकि APISIX एक API गेटवे है जो कई अपस्ट्रीम एप्लिकेशन सर्वर के लिए प्रॉक्सी के रूप में कार्य करता है, इसलिए केंद्रीकृत प्राधिकरण और प्रमाणीकरण को API गेटवे पर रखना सबसे स्वाभाविक है।

APISIX का OpenID Connect (OIDC) प्लगइन OpenID Connect प्रोटोकॉल का समर्थन करता है। उपयोगकर्ता इस प्लगइन का उपयोग करके APISIX को कई पहचान प्रदाताओं (IdP) के साथ जोड़ सकते हैं, जैसे Okta, Keycloak, Ory Hydra, Authing, आदि, और इसे एक केंद्रीकृत प्रमाणीकरण गेटवे के रूप में तैनात कर सकते हैं। OIDC OAuth का एक सुपरसेट है, इसलिए यह प्लगइन OAuth का भी समर्थन करता है।

तैनाती आरेख:

APISIX और OAuth की तैनाती आरेख

कॉन्फ़िगरेशन नमूना: Apache APISIX के साथ Keycloak को प्रमाणीकरण के लिए एकीकृत करें

Keycloak कॉन्फ़िगर करें

पैरामीटर	मान
keycloak पता	http://127.0.0.1:8080/
Realm	myrealm
क्लाइंट प्रकार	OpenID Connect
क्लाइंट ID	myclient
क्लाइंट सीक्रेट	e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq
पुनर्निर्देश URI	http://127.0.0.1:9080/anything/callback
डिस्कवरी	http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration
लॉगआउट URI	/anything/logout
उपयोगकर्ता नाम	myuser
पासवर्ड	myrealm
Realm	mypassword

नमूना कोड

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

जब आप API सफलतापूर्वक बनाने के बाद http://127.0.0.1:9080/anything/test पर जाते हैं, तो आपको Keycloak के लॉगिन पृष्ठ पर पुनर्निर्देशित किया जाएगा क्योंकि आपने लॉग इन नहीं किया है:

APISIX Keycloak लॉगिन

उपयोगकर्ता नाम के रूप में myuser और पासवर्ड के रूप में mypassword दर्ज करें, और आपको निम्नलिखित पृष्ठ पर पुनर्निर्देशित किया जाएगा।

APISIX Keycloak प्राधिकृत

लॉग आउट करने के लिए http://127.0.0.1:9080/anything/logout पर जाएं:

APISIX Keycloak लॉगआउट

सारांश

संक्षेप में, OAuth मानक एप्लिकेशन और उपयोगकर्ताओं दोनों के लिए एक लोकप्रिय समाधान है। यह उपयोगकर्ताओं को उनकी साख साझा किए बिना कई प्लेटफॉर्म पर सेवाओं का उपयोग करने की अनुमति देकर सुविधा और सुरक्षा प्रदान करता है। Apache APISIX एक लोकप्रिय API गेटवे है जो विभिन्न पहचान प्रदाताओं (Keycloak, Ory Hydra, Okta, Auth0, आदि) के एकीकरण का समर्थन करता है ताकि आपके API को सुरक्षित किया जा सके।

अधिक सत्र पढ़ें: