OAuth 2.0 के बारे में जानकारी

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़. जानकारी

OAuth होम: OAuth के दिशा-निर्देशों के टॉप-लेवल व्यू के लिए, OAuth का होम पेज देखें. उपलब्ध कराएं.

इस विषय में, Apigee Edge पर OAuth 2.0 के बारे में बुनियादी जानकारी दी गई है.

OAuth 2.0 क्या है?

OAuth 2.0 को समर्पित कई किताबें, ब्लॉग और साइटें हैं. हमारा सुझाव है कि आप IETF OAuth 2.0 की समीक्षा करके शुरुआत करें खास जानकारी. OAuth 2.0 आईईटीएफ़ की खास बातों में, OAuth 2.0 की परिभाषा यहां दी गई है खुद:

"OAuth 2.0 के ऑथराइज़ेशन फ़्रेमवर्क की मदद से, तीसरे पक्ष को एक एचटीटीपी सेवा का सीमित ऐक्सेस पाने के लिए, संसाधन के मालिक और एचटीटीपी सेवा के बीच मंज़ूरी इंटरैक्शन को आयोजित करना या ऐसा करके तीसरे पक्ष के ऐप्लिकेशन को अपनी ओर से ऐक्सेस पाने की अनुमति देना."

आपको खास बात यह जानने की ज़रूरत है कि OAuth 2.0 की मदद से, ऐप्लिकेशन उपयोगकर्ता के सुरक्षित संसाधनों का सीमित ऐक्सेस पा सकते हैं. जैसे, बैंक खाते या किसी दूसरे तरीके से ऐसी संवेदनशील जानकारी जिसे उपयोगकर्ता किसी ऐप्लिकेशन से ऐक्सेस करना चाहता है. इसके लिए, उपयोगकर्ता को इनकी ज़रूरत नहीं होती वे अपने लॉगिन क्रेडेंशियल ऐप्लिकेशन में खोल सकते हैं.

OAuth 2.0 फ़्लो

यहां OAuth 2.0 सुरक्षा फ़्रेमवर्क के बारे में सामान्य जानकारी दी गई है. हम इस फ़्लो के बारे में और ज़्यादा बातचीत करेंगे इस विषय में ज़्यादा जानकारी दी गई है. पहले डायग्राम में यह उदाहरण दिया गया है. इसमें OAuth 2.0 के काम करने के तरीके के बारे में काफ़ी जानकारी दी गई है. अगर आपको इस डायग्राम में इस्तेमाल किए गए शब्दों के बारे में नहीं पता है, तो जल्दी से जानकारी पाने के लिए यह सेक्शन पढ़ें परिचय.

ये शर्तें आपको पता होनी चाहिए

• क्लाइंट: इसे "ऐप्लिकेशन" भी कहा जाता है. यह मोबाइल पर चलने वाला कोई ऐप्लिकेशन हो सकता है या कोई पारंपरिक वेब ऐप्लिकेशन. ऐप्लिकेशन, सुरक्षित ब्राउज़िंग की प्रोसेस पूरी करने के लिए, संसाधन सर्वर को अनुरोध भेजता है ऐसेट, संसाधन के मालिक की तरफ़ से सबमिट की गई होती है. संसाधन के मालिक को ऐप्लिकेशन को सुरक्षित संसाधनों को ऐक्सेस करने की अनुमति दें.
• संसाधन का मालिक: इसे "असली उपयोगकर्ता" भी कहा जाता है. आम तौर पर, कोई ऐसा व्यक्ति (या कोई अन्य इकाई) जो किसी सुरक्षित संसाधन को ऐक्सेस करने में सक्षम हो. इसके लिए उदाहरण के लिए, अगर कोई ऐप्लिकेशन आपकी किसी सोशल मीडिया साइट का डेटा इस्तेमाल करता है, तो संसाधन का मालिक -- वह व्यक्ति जो किसी ऐप्लिकेशन को आपके डेटा का ऐक्सेस दे सकता है.
• संसाधन सर्वर: संसाधन सर्वर को एक ऐसी सेवा मानें Facebook, Google या Twitter; या आपके इंट्रानेट पर HR सेवा; या अपने पर एक पार्टनर सेवा B2B एक्स्ट्रानेट. जब भी OAuth टोकन की पुष्टि करने की ज़रूरत होती है, तब Apigee Edge एक संसाधन सर्वर होता है एपीआई अनुरोधों को प्रोसेस करते हैं. संसाधन सर्वर के काम करने से पहले उसे किसी तरह की अनुमति की ज़रूरत है सुरक्षित संसाधन तैयार कर सकें.
• ऑथराइज़ेशन सर्वर: ऑथराइज़ेशन सर्वर लागू होता है का अनुपालन करता है और यह अनुमतियों की पुष्टि की पुष्टि करना और ऐक्सेस जारी करना टोकन जो ऐप्लिकेशन को रिसॉर्स सर्वर पर उपयोगकर्ता के डेटा का ऐक्सेस देते हैं. आपने लोगों तक पहुंचाया मुफ़्त में "टोकन एंडपॉइंट" को कॉन्फ़िगर कर सकता है पर ऐक्सेस किया जा सकता है. इसमें एजुकेटर अपनी भूमिका निभाता है की अनुमति देने वाला सर्वर.
• अनुमति देना: इससे ऐप्लिकेशन को ऐक्सेस वापस पाने की अनुमति मिलती है असली उपयोगकर्ता की ओर से टोकन जनरेट किया जा सकता है. OAuth 2.0, चार खास तरह के "मंज़ूरी टाइप" के बारे में बताता है. "OAuth 2.0 के अनुदान किस तरह के हैं" देखें देखें.
• ऐक्सेस टोकन: वर्णों की एक लंबी स्ट्रिंग जो क्रेडेंशियल के तौर पर काम करती है का इस्तेमाल, सुरक्षित संसाधनों को ऐक्सेस करने के लिए किया जाता है. यह भी देखें "ऐक्सेस क्या है टोकन क्या है?" देखें.
• सुरक्षित संसाधन: संसाधन के मालिक के मालिकाना हक वाला डेटा. उदाहरण के लिए, की संपर्क सूची, खाते की जानकारी या अन्य संवेदनशील जानकारी शामिल है.

Apigee Edge इनमें से किस कैटगरी में आता है

OAuth 2.0 की मदद से, Apigee Edge से प्रॉक्सी किए गए किसी भी एपीआई को सुरक्षित किया जा सकता है. Edge में यह शामिल है ऑथराइज़ेशन सर्वर को लागू करने की सुविधा की मदद से, ऐक्सेस टोकन जनरेट किए जा सकते हैं और उनकी पुष्टि की जा सकती है. डेवलपर, Apigee Edge के साथ अपने ऐप्लिकेशन रजिस्टर करके शुरुआत करते हैं. रजिस्टर किए गए ऐप्लिकेशन, इन चार में से किसी भी अनुमति के ज़रिए, ऐक्सेस टोकन का अनुरोध कर सकते हैं type इंटरैक्शन होते हैं.

Apigee, GA4 में OAuthV2 नीति उपलब्ध कराता है. यह नीति, हर तरह के अनुदान की जानकारी दी गई है. इससे Apigee Edge पर OAuth सेट अप करना ज़्यादा आसान हो जाता है. इसके लिए उदाहरण के लिए, किसी ऐसी नीति को कॉन्फ़िगर किया जा सकता है जिसमें ऐक्सेस टोकन के लिए अनुरोध मिलता है. ज़रूरी क्रेडेंशियल देता है. साथ ही, क्रेडेंशियल के मान्य होने पर ऐक्सेस टोकन दिखाता है.

ध्यान दें कि ऐसे सभी संसाधन सर्वर जिन्हें आपके सुरक्षित एपीआई प्रॉक्सी कॉल, फ़ायरवॉल से सुरक्षित रखना चाहिए (इसका मतलब है कि रिसॉर्स को एपीआई प्रॉक्सी या किसी दूसरे तरीके से ऐक्सेस किए जाने के अलावा, किसी और तरीके से ऐक्सेस नहीं किया जाना चाहिए एपीआई जो पूरी तरह सुरक्षित है).

OAuth 2.0 क्या हैं अनुदान प्रकार?

अलग-अलग तरह की अनुमतियों को अलग-अलग पाथ या इंटरैक्शन के तौर पर देखें. इनका इस्तेमाल करके, ऐप्लिकेशन ऐक्सेस कर सकता है टोकन. हर अनुदान टाइप के लिए एक या उससे ज़्यादा इस्तेमाल के उदाहरण दिए जाते हैं. आपको यह चुनना होगा कि किस तरह की अनुमति अपनी ज़रूरत के हिसाब से टाइप करें. आम तौर पर, हर तरह के अनुदान के अपने फ़ायदे और नुकसान पहुंचता है. साथ ही, आपको अपने कारोबार के इस्तेमाल के उदाहरणों के आधार पर ट्रेडऑफ़ करने होंगे. एक "भरोसेमंद होने" पर ही, हम सबसे ज़्यादा ध्यान देते हैं जो आपके डेटा को ऐक्सेस करेंगे. आम तौर पर, तीसरे पक्ष के ऐप्लिकेशन उन ऐप्लिकेशन की तुलना में कम भरोसेमंद होते हैं जिन्हें Android एंटरप्राइज़.

Apigee Edge, चार मुख्य OAuth 2.0 अनुदान टाइप के साथ काम करता है:

• अनुमति कोड -- सबसे सुरक्षित अनुदान प्रकार माना जाता है. इस तारीख से पहले ऑथराइज़ेशन सर्वर एक ऐक्सेस टोकन जारी करता है, ऐप्लिकेशन को पहले ऑथराइज़ेशन कोड मिलना चाहिए संसाधन सर्वर से निकालता है. आपका ऐप्लिकेशन जब भी किसी ब्राउज़र को के लॉगिन पेज पर क्लिक करने और आपको अपने वास्तविक खाते में लॉग इन करने का न्योता देता है (उदाहरण के लिए, Facebook या Twitter).

लॉग इन करने पर, ऐप्लिकेशन को अनुमति मिल जाएगी इस कोड का इस्तेमाल करके, अनुमति देने वाले सर्वर के साथ ऐक्सेस टोकन मोल-भाव किया जा सकता है. आम तौर पर, यह ग्रांट टाइप का इस्तेमाल तब किया जाता है, जब ऐप्लिकेशन क्लाइंट के बजाय सर्वर पर रहता है. अनुदान का यह टाइप इसे बहुत ज़्यादा सुरक्षित माना जाता है, क्योंकि क्लाइंट ऐप्लिकेशन कभी भी उपयोगकर्ता के उपयोगकर्ता नाम को हैंडल या देखता नहीं या रिसॉर्स सर्वर के लिए पासवर्ड (उदाहरण के लिए, ऐप्लिकेशन कभी भी आपके Twitter क्रेडेंशियल). इस अनुदान प्रकार को "थ्री-लेग्ड" भी कहा जाता है OAuth.

• impressions -- इसे ऑथराइज़ेशन कोड का आसान वर्शन माना जाता है. आम तौर पर, इस तरह की अनुमति का इस्तेमाल तब किया जाता है, जब ऐप्लिकेशन क्लाइंट पर होता है. उदाहरण के लिए, ऐप्लिकेशन का कोड को JavaScript या किसी अन्य स्क्रिप्टिंग भाषा (न कि पर निर्भर रहने और उसे अलग वेब सर्वर पर चलाने के लिए किया जाता है). अनुमति के इस टाइप के फ़्लो में, सर्वर, उपयोगकर्ता की पुष्टि होने पर सीधे ऐक्सेस टोकन देता है. प्राधिकरण कोड डालें. सीधे तौर पर अनुमति देने से कुछ मामलों में, ऐप्लिकेशन के रिस्पॉन्स मिलने में सुधार हो सकता है. हालांकि, इस फ़ायदे को सुरक्षा से जुड़ी संभावित समस्याओं के हिसाब से अहमियत दी जानी चाहिए. आईईटीएफ़ की खास बातें.
• संसाधन मालिक के पासवर्ड के क्रेडेंशियल -- इस फ़्लो में, क्लाइंट को जारी किया जाता है एक ऐक्सेस टोकन, जब अनुमति देने वाला सर्वर उपयोगकर्ता के उपयोगकर्ता नाम/पासवर्ड की पुष्टि करता है. ज़्यादा भरोसेमंद ऐप्लिकेशन के लिए, इस फ़्लो का सुझाव दिया जाता है. इस फ़्लो का एक फ़ायदा यह है कि मान लीजिए पुष्टि करने का बुनियादी तरीका यह है कि उपयोगकर्ता अपना उपयोगकर्ता नाम/पासवर्ड सिर्फ़ एक बार दिखाता है. इसके बाद पर, ऐक्सेस टोकन का इस्तेमाल किया जाता है.
• क्लाइंट के क्रेडेंशियल -- उन स्थितियों के लिए इस्तेमाल करें जहां क्लाइंट ऐप अपनी ओर से काम कर रहा है. इसका मतलब है कि क्लाइंट, संसाधन का मालिक भी है. यह अनुदान आम तौर पर, टाइप का इस्तेमाल तब किया जाता है, जब ऐप्लिकेशन को बैकएंड डेटा स्टोरेज सेवा की ज़रूरत होती है. उदाहरण के लिए. ऐप्लिकेशन को अपना काम करने के लिए इस सेवा का इस्तेमाल करना होगा और सेवा की जानकारी साफ़ तौर पर नहीं दी जाएगी असली उपयोगकर्ता को दिखता है. अनुमति के इस टाइप का इस्तेमाल करने पर, ऐप्लिकेशन को अनुमति देने वाले सर्वर के लिए क्लाइंट आईडी और क्लाइंट सीक्रेट कुंजियां जोड़ी जाती हैं. आपको कुछ और करने की ज़रूरत नहीं है. Edge एक ऐसा बेहतरीन क्लाइंट क्रेडेंशियल मुहैया कराता है जिसे किसी भी उपयोगकर्ता के लिए आसानी से लागू किया जा सकता है एपीआई प्रॉक्सी.

ऐक्सेस का मतलब क्या है टोकन?

ऐक्सेस टोकन, वर्णों की एक लंबी स्ट्रिंग होती है. यह ऐक्सेस करने के लिए इस्तेमाल किए जाने वाले क्रेडेंशियल के तौर पर काम करती है संसाधनों को सुरक्षित रखा जा सके. संसाधन टोकन (जिसे बेयरर टोकन भी कहा जाता है) को अनुमति देने के लिए पास किया जाता है हेडर, जैसे कि:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

रिसॉर्स सर्वर इस बात को समझता है कि ऐक्सेस टोकन "मौजूद है" जैसे उपयोगकर्ता नाम और पासवर्ड. इसके अलावा, ऐक्सेस टोकन कुछ पाबंदियों के साथ जारी किए जा सकते हैं, ताकि, उदाहरण के लिए, ऐप्लिकेशन संसाधन सर्वर पर मौजूद डेटा को पढ़ सकता है, लेकिन लिख नहीं सकता या मिटा नहीं सकता. ध्यान दें कि ऐक्सेस टोकन को रद्द किया जा सकता है, उदाहरण के लिए, ऐप्लिकेशन में छेड़छाड़ की गई हो. इस स्थिति में, आपको इन चीज़ों की ज़रूरत होगी ऐप्लिकेशन का इस्तेमाल जारी रखने के लिए नया ऐक्सेस टोकन पाएं; हालांकि, आपको अपना खाता मैनेजर सुरक्षित संसाधनों के सर्वर पर उपयोगकर्ता नाम या पासवर्ड (उदाहरण के लिए, Facebook या Twitter).

आम तौर पर, ऐक्सेस टोकन की समयसीमा खत्म हो जाती है. ऐसा सुरक्षा की वजहों से किया जाता है. कुछ अनुदान प्रकार रीफ़्रेश टोकन जारी करने की अनुमति देने वाला सर्वर, जिससे ऐप्लिकेशन नया ऐक्सेस टोकन फ़ेच कर पाता है जब पुरानी प्रोफ़ाइल खत्म हो जाती है. टोकन ऐक्सेस और रीफ़्रेश करने के बारे में ज़्यादा जानने के लिए, आईईटीएफ़ OAuth देखें 2.0 का स्पेसिफ़िकेशन.

सीमित ऐक्सेस स्कोप

दायरों के हिसाब से, OAuth 2.0 किसी ऐप्लिकेशन को संसाधन. उदाहरण के लिए, ऐसा हो सकता है कि किसी ऐप्लिकेशन के पास सिर्फ़ कुछ खास संसाधनों का ऐक्सेस हो. ऐसे में, वह ऐप्लिकेशन को अपडेट भी कर सकता है संसाधन शामिल नहीं होते या उन्हें सिर्फ़ रीड-ओनली ऐक्सेस दिया जा सकता है. तथाकथित "थ्री-लेग्ड" के तहत OAuth फ़्लो, आम तौर पर, उपयोगकर्ता किसी सहमति वाले पेज से ऐक्सेस के लेवल के बारे में बताता है. उदाहरण के लिए, वेब पेज जहां उपयोगकर्ता, स्कोप को चुनने के लिए अन्य तरीके से चेकबॉक्स चुनता है).

ऐप्लिकेशन रजिस्टर करना

सभी क्लाइंट (ऐप्लिकेशन) को OAuth 2.0 के ऑथराइज़ेशन सर्वर के साथ रजिस्टर करना होगा, जिससे वे क्या आपको ऐक्सेस टोकन के लिए अनुरोध करना है. किसी ऐप्लिकेशन को रजिस्टर करने पर, आपको कुंजियों का एक सेट वापस मिल जाता है. एक है एक सार्वजनिक पासकोड, जिसे क्लाइंट आइडेंटिफ़ायर कहा जाता है. वहीं, दूसरी सीक्रेट पासकोड को क्लाइंट आइडेंटिफ़ायर कहा जाता है गुप्त. इन कुंजियों के बिना, कोई ऐप्लिकेशन ऑथराइज़ेशन कोड या ऐक्सेस टोकन के लिए अनुरोध जारी नहीं कर सकता को अनुमति देने वाले सर्वर पर. ध्यान दें कि आईईटीएफ़ OAuth स्पेसिफ़िकेशन में इन कुंजियों क्लाइंट को कॉल किया जाता है आईडी और क्लाइंट सीक्रेट, Apigee Edge यूज़र इंटरफ़ेस (यूआई) उन्हें ग्राहक आईडी और ग्राहक सीक्रेट कहते हैं. वे हैं के बराबर है.

OAuth 2.0 के इस्तेमाल के उदाहरणों के बारे में खास जानकारी

आपने OAuth 2.0 के अनुदान टाइप का कौनसा फ़्लो लागू किया है, यह आपके इस्तेमाल के उदाहरण पर निर्भर करता है. जैसे, कुछ अनुदान प्रकार अन्य से ज़्यादा सुरक्षित होते हैं. आपको किस तरह की अनुमति देनी है, यह इस बात पर निर्भर करता है कि वह क्लाइंट ऐप्लिकेशन की विश्वसनीयता को बरकरार रखता है. साथ ही, बहुत सोच-समझकर विचार करने की ज़रूरत है, जैसा कि निम्न तालिका:

इस्तेमाल का उदाहरण	विश्वसनीयता	OAuth 2.0 अनुमति देने के लिए सुझाए गए टाइप	ब्यौरा
B2B (एक्स्ट्रानेट), इंट्रानेट, अन्य	बेहद भरोसेमंद ऐप्लिकेशन, जिन्हें संगठन के डेवलपर या डेवलपर ने लिखा है और जो एपीआई सेवा देने वाली कंपनी के साथ कारोबारी संबंध. ऐसे ऐप्लिकेशन जिन्हें खुद ही संसाधनों को ऐक्सेस करने की ज़रूरत होती है.	क्लाइंट के क्रेडेंशियल	आम तौर पर, यह ऐप्लिकेशन संसाधन का भी मालिक होता है Client-ID और क्लाइंट सीक्रेट कुंजियों की ज़रूरत होती है ऐप्लिकेशन को सेवा देने वाली कंपनी के साथ रजिस्टर होना ज़रूरी है
इंट्रानेट साइटें, पोर्टल	इंटरनल या भरोसेमंद तीसरे पक्ष के डेवलपर के बनाए गए भरोसेमंद ऐप्लिकेशन. बीमा का विकल्प चुनने के लिए, अपनी कंपनी की एचआर साइट पर लॉग इन करना एक अच्छा उदाहरण है. समीक्षाएं सबमिट करने या निजी जानकारी में बदलाव करने के लिए.	पासवर्ड इंप्लिसिट	इसके लिए, क्लाइंट आईडी और सीक्रेट के साथ-साथ उपयोगकर्ता नाम और पासवर्ड की ज़रूरत होगी ऐप्लिकेशन को सेवा देने वाली कंपनी के साथ रजिस्टर होना ज़रूरी है
सार्वजनिक तौर पर उपलब्ध ऐप्लिकेशन	गैर-भरोसेमंद ऐप्लिकेशन, तीसरे पक्ष के उन डेवलपर ने लिखे हैं जिनका कोई भरोसेमंद कारोबार नहीं है एपीआई की सेवा देने वाली कंपनी के साथ संबंध. उदाहरण के लिए, सार्वजनिक एपीआई के लिए रजिस्टर करने वाले डेवलपर आम तौर पर, भरोसेमंद प्रोग्राम नहीं होने चाहिए.	प्राधिकरण कोड	इसके लिए उपयोगकर्ता को तीसरे पक्ष की संसाधन सेवा देने वाली कंपनी (उदाहरण के लिए, Twitter, Facebook) ऐप्लिकेशन को उपयोगकर्ता का उपयोगकर्ता नाम और पासवर्ड कभी नहीं दिखता ऐप्लिकेशन को सेवा देने वाली कंपनी के साथ रजिस्टर होना ज़रूरी है
B2C	इसमें कोई व्यक्तिगत असली उपयोगकर्ता (मोबाइल उपयोगकर्ता) शामिल होता है और उपयोगकर्ता के क्रेडेंशियल सेव किए जाते हैं मोबाइल डिवाइस पर.	इंप्लिसिट	इसके लिए, ऐप्लिकेशन को सेवा देने वाली कंपनी के साथ रजिस्टर होना ज़रूरी है. उपयोगकर्ता के क्रेडेंशियल, ऐप्लिकेशन चलाने वाले डिवाइस में सेव किए जाते हैं.

OAuth 2.0 बनाम API पासकोड सिक्योरिटी

एपीआई पासकोड की पुष्टि करने की सुविधा के लिए ज़रूरी है कि ऐप्लिकेशन, Edge पर पासकोड भेजता हो. कुंजी एक मान्य उपभोक्ता कुंजी होनी चाहिए को एपीआई प्रॉक्सी से जुड़ा हुआ Apigee Edge डेवलपर ऐप्लिकेशन से लेना होगा. अगर किसी वजह से प्रॉक्सी को कॉल करने के लिए, क्लाइंट ऐप्लिकेशन की अनुमति को निरस्त करना होगा, तो ग्राहक कुंजी. उस कुंजी का इस्तेमाल करने वाला कोई भी क्लाइंट ऐप्लिकेशन भी एपीआई प्रॉक्सी को ऐक्सेस नहीं कर पाएगा. इस दूसरी ओर, ऐप्लिकेशन की कुंजियों को वापस लिए बिना OAuth टोकन को किसी भी समय निरस्त किया जा सकता है. ऐप्लिकेशन उपयोगकर्ता की ओर से नए टोकन का अनुरोध कर सकता है. टोकन दिए जाने पर, ऐप्लिकेशन ये काम कर सकता है: API प्रॉक्सी का उपयोग करना जारी रखें.

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

एपीआई पासकोड की पुष्टि से जुड़ी जानकारी के लिए, एपीआई की जानकारी देखें कुंजियां. OAuth टोकन के साथ कस्टम एट्रिब्यूट का इस्तेमाल करने के बारे में जानकारी पाने के लिए, टोकन को पसंद के मुताबिक बनाना और ऑथराइज़ेशन कोड.

सुझाव संसाधन

पढ़ना

OAuth 2.0 के बारे में जानें लेख पढ़ें.