मोबाइल और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

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

OAuth 2.0 की मदद से, उपयोगकर्ता अपने उपयोगकर्ता नाम, पासवर्ड, और अन्य जानकारी को निजी रखते हुए, किसी ऐप्लिकेशन के साथ खास डेटा शेयर कर सकते हैं. उदाहरण के लिए, कोई ऐप्लिकेशन OAuth 2.0 का इस्तेमाल करके, उपयोगकर्ताओं से अनुमति ले सकता है, ताकि वह उनके Google Drive में फ़ाइलें सेव कर सके.

इंस्टॉल किए गए ऐप्लिकेशन, अलग-अलग डिवाइसों पर डिस्ट्रिब्यूट किए जाते हैं. साथ ही, यह माना जाता है कि ये ऐप्लिकेशन ��ोपनीय जानकारी को सुरक्षित नहीं रख सकते. उपयोगकर्ता के ऐप्लिकेशन पर मौजूद होने या ऐप्लिकेशन के बैकग्राउंड में चलने के दौरान, ये Google API ऐक्सेस कर सकते हैं.

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

विकल्प

मोबाइल ऐप्लिकेशन के लिए, Android या iOS के लिए, 'Google साइन इन' का इस्तेमाल किया जा सकता है. Google साइन-इन क्लाइंट लाइब्रेरी, पुष्टि करने और उपयोगकर्ता की अनुमति देने की प्रोसेस को मैनेज करती हैं. साथ ही, इन लाइब्रेरी को लागू करना, यहां बताए गए निचले लेवल के प्रोटोकॉल के मुकाबले आसान हो सकता है.

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

लाइब्रेरी और सैंपल

हमारा सुझाव है कि इस दस्तावेज़ में बताए गए OAuth 2.0 फ़्लो को लागू करने के लिए, यहां दी गई लाइब्रेरी और सैंपल का इस्तेमाल करें:

• Android के लिए AppAuth लाइब्रेरी
• iOS के लिए AppAuth लाइब्रेरी
• ऐप्लिकेशन के लिए OAuth: Windows के लिए सैंपल

ज़रूरी शर्तें

अपने प्रोजेक्ट के लिए एपीआई चालू करना

Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को, उन एपीआई को API Consoleमें चालू करना हो��ा.

अपने प्रोजेक्ट के लिए एपीआई चालू करने के लिए:

1. Open the API Library में Google API Console.
2. If prompted, select a project, or create a new one.
3. API Library में, प्रॉडक्ट फ़ैमिली और लोकप्रियता के हिसाब से व्यवस्थित किए गए सभी उपलब्ध एपीआई की सूची होती है. अगर आपको जो एपीआई चालू करना है वह सूची में नहीं दिख रहा है, तो उसे खोजने के लिए खोज बार का इस्तेमाल करें या उस प्रॉडक्ट फ़ैमिली में सभी देखें पर क्लिक करें जिससे वह एपीआई जुड़ा है.
4. वह एपीआई चुनें जिसे आपको चालू करना है. इसके बाद, चालू करें बटन पर क्लिक करें.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

अनुमति देने वाले क्रेडेंशियल बनाना

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

1. Go to the Credentials page.
2. क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी पर क्लिक करें.
3. यहां दिए गए सेक्शन में, क्लाइंट टाइप के बारे में बताया गया है. ये ऐसे क्लाइंट टाइप हैं जिनके साथ Google का अनुमति देने वाला सर्वर काम करता है. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें, अपने OAuth क्लाइंट को नाम दें, और फ़ॉर्म में अन्य फ़ील्ड को ज़रूरत के मुताबिक सेट करें.

ऐक्सेस के स्कोप की पहचान करना

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

हमारा सुझाव है कि OAuth 2.0 ऑथराइज़ेशन लागू करने से पहले, उन स्कोप की पहचान करें जिन्हें ऐक्सेस करने के लिए आपके ऐप्लिकेशन को अनुमति की ज़रूरत होगी.

OAuth 2.0 एपीआई स्कोप दस्तावेज़ में, उन स्कोप की पूरी सूची होती है जिनका इस्तेमाल Google API को ऐक्सेस करने के लिए किया जा सकता है.

OAuth 2.0 ऐक्सेस टोकन पाना

यहां दिए गए चरणों से पता चलता है कि आपका ऐप्लिकेशन, उपयोगकर्ता की ओर से एपीआई अनुरोध करने के लिए, उसकी सहमति पाने के लिए, Google के OAuth 2.0 सर्वर के साथ कैसे इंटरैक्ट करता है. Google API का ऐसा अनुरोध पूरा करने से पहले, आपके ऐप्लिकेशन के पास वह अनुमति होनी चाहिए जिसके ��िए उपयोगकर्ता की अनुमति की ज़रूरत होती है.

पहला चरण: कोड की पुष्टि करने वाला कोड और चैलेंज जनरेट करना

Google, कोड एक्सचेंज के लिए पुष्टि करने वाली कुंजी (PKCE) प्रोटोकॉल के साथ काम करता है, ताकि इंस्टॉल किए गए ऐप्लिकेशन फ़्लो को ज़्यादा सुरक्षित बनाया जा सके. अनुमति के हर अनुरोध के लिए, एक यूनीक कोड पुष्टि करने वाला टूल बनाया जाता है. साथ ही, "code_challenge" नाम की बदली गई वैल्यू को अनुमति देने वाले सर्वर पर भेजा जाता है, ताकि अनुमति का कोड मिल सके.

कोड की पुष्टि करने वाला टूल बनाना

code_verifier, एन्क्रिप्शन के लिए इस्तेमाल होने वाली एक स्ट्रिंग है. इसमें, [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" जैसे वर्ण इस्तेमाल किए जाते हैं. इसकी लंबाई 43 से 128 वर्णों के बीच हो सकती है.

कोड की पुष्टि करने वाले पासकोड में इतना एन्ट्रापी होना चाहिए कि उसकी वैल्यू का अनुमान लगाना मुश्किल हो.

कोड चैलेंज बनाना

कोड चैलेंज बनाने के दो तरीके हैं.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

दूसरा चरण: Google के OAuth 2.0 सर्वर को अनुरोध भेजना

उपयोगकर्ता की अनुमति पाने के लिए, https://accounts.google.com/o/oauth2/v2/auth पर Google के ऑथराइज़ेशन सर्वर को अनुरोध भेजें. यह एंडपॉइंट, ऐक्टिव सेशन लुकअप को हैंडल करता है, उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. एंडपॉइंट को सि��्फ़ एसएसएल के ज़रिए ऐक्सेस किया जा सकता है. साथ ही, यह एंडपॉइंट एचटीटीपी (गैर-एसएसएल) कनेक्शन को स्वीकार नहीं करता.

अनुमति देने वाला सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए इन क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:

अनुमति देने वाले यूआरएल के सैंपल

नीचे दिए गए टैब में, रीडायरेक्ट यूआरआई के अलग-अलग विकल्पों के लिए, अनुमति वाले यूआरएल के सैंपल दिखाए गए हैं.

redirect_uri पैरामीटर की वैल्यू को छोड़क��, दोनों यूआरएल एक जैसे हैं. यूआरएल में, ज़रूरी response_type और client_id पैरामीटर के साथ-साथ, वैकल्पिक state पैरामीटर भी शामिल होता है. हर यूआरएल में, पढ़ने में आसानी के लिए लाइन ब्रेक और स्पेस होते हैं.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

तीसरा चरण: Google, उपयोगकर्ता से सहमति मांगता है

इस चरण में, उपयोगकर्ता यह तय करता है कि आपके ऐप्लिकेशन को अनुरोध किया गया ऐक्सेस देना है या नहीं. इस चरण में, Google एक सहमति वाली विंडो दिखाता है. इसमें आपके ऐप्लिकेशन का नाम और Google API की उन सेवाओं की जानकारी दिखती है जिन्हें ऐप्लिकेशन, उपयोगकर्ता के क्रेडेंशियल की मदद से ऐक्सेस करने की अनुमति मांग रहा है. साथ ही, इसमें ऐक्सेस के दायरे की खास जानकारी भी दिखती है. इसके बाद, उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए एक या एक से ज़्यादा स्कोप का ऐक्सेस देने की सहमति दे सकता है या अनुरोध को अस्वीकार कर सकता है.

इस चरण में, आपके ऐप्लिकेशन को कुछ करने की ज़रूरत नहीं है. इस दौरान, वह Google के OAuth 2.0 सर्वर से जवाब का इंतज़ार करता है. इससे यह पता चलता है कि ऐप्लिकेशन को ऐक्सेस दिया गया है या नहीं. इस जवाब के बारे में अगले चरण में बताया गया है.

चौथा चरण: OAuth 2.0 सर्वर के जवाब को मैनेज करना

आपके ऐप्लिकेशन को अनुमति का जवाब किस तरह मिलता है, यह इस बात पर निर्भर करता है कि वह किस रीडायरेक्ट यूआरआई स्कीम का इस्तेमाल करता है. स्कीम के बावजूद, जवाब में अनुमति कोड (code) या गड़बड़ी (error) का मैसेज दिखेगा. उदाहरण के लिए, error=access_denied से पता चलता है कि उपयोगकर्ता ने अनुरोध अस्वीकार कर दिया है.

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

पांचवां चरण: रीफ़्रेश और ऐक्सेस टोकन के लिए ऑथराइज़ेशन कोड बदलना

ऑथराइज़ेशन कोड को ऐक्सेस टोकन से बदलने के लिए, https://oauth2.googleapis.com/token एंडपॉइंट को कॉल करें और ये पैरामीटर सेट करें:

यहां दिया गया स्निपेट, अनुरोध का सैंपल दिखाता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google इस अनुरोध का जवाब, एक JSON ऑब्जेक्ट के तौर पर देता है. इसमें कुछ समय के लिए मान्य ऐक्सेस टोकन और रीफ़्रेश टोकन होता है.

रिस्पॉन्स में ये फ़ील्ड शामिल होते हैं:

यहां दिया गया स्निपेट, जवाब का एक सैंपल दिखाता है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

छठा चरण: देखें कि उपयोगकर्ताओं ने कौनसे स्कोप दिए हैं

एक साथ कई स्कोप का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए सभी स्कोप को अनुमति न दें. आपके ऐप्लिकेशन को हमेशा यह देखना चाहिए कि उपयोगकर्ता ने किन स्कोप को अनुमति दी है. साथ ही, ज़रूरी सुविधाओं को बंद करके, स्कोप के अस्वीकार होने की समस्या को मैनेज करना चाहिए. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी वाली अनुमतियों को मैनेज करने का तरीका लेख पढ़ें.

यह देखने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को किसी खास स्कोप का ऐक्सेस दिया है या नहीं, ऐक्सेस टोकन के जवाब में scope फ़ील्ड देखें. access_token से मिले ऐक्सेस के दायरे, स्पेस से अलग किए गए और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं.

उदाहरण के लिए, ऐक्सेस टोकन के जवाब के इस सैंपल से प��ा चलता है कि उपयोगकर्ता ने आपके ऐप्लिकेशन को, Drive में सिर्फ़ पढ़ने की अनुमति वाली गतिविधि और Calendar इवेंट की अनुमतियों का ऐक्सेस दिया है:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google API को कॉल करना

जब आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाता है, तो किसी उपयोगकर्ता खाते की ओर से Google API को कॉल करने के लिए, टोकन का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि एपीआई को ऐक्सेस का ज़रूरी दायरा दिया गया हो. ऐसा करने के लिए, एपीआई के अनुरोध में ऐक्सेस टोकन शामिल करें. इसके लिए, access_token क्वेरी पैरामीटर या Authorization एचटीटीपी हेडर Bearer की वैल्यू शामिल करें. जब भी हो सके, एचटीटीपी हेडर का इस्तेमाल करें. ऐसा इसलिए, क्योंकि क्वेरी स्ट्रिंग, सर्वर लॉग में दिखती हैं. ज़्यादातर मामलों में, Google API के कॉल सेट अप करने के लिए क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Drive Files API को कॉल करते समय.

OAuth 2.0 Playground पर जाकर, Google के सभी एपीआई आज़माए जा सकते हैं और उनके दायरे देखे जा सकते हैं.

एचटीटीपी GET के उदाहरण

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, drive.files एंडपॉइंट (Drive Files API) को कॉल करने का तरीका कुछ ऐसा दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन डालना होगा:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

यहां पुष्टि किए गए उपयोगकर्ता के लिए, access_token क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, उसी एपीआई को कॉल किया गया है:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl के उदाहरण

इन कमांड की जांच, curl कमांड-लाइन ऐप्लिकेशन की मदद से की जा सकती है. यहां एक उदाहरण दिया ��या है, जिसमें एचटीटीपी हेडर के विकल्प का इस्तेमाल किया गया है. यह विकल्प इस्तेमाल करना सबसे सही है:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर का विकल्प भी चुना जा सकता है:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

ऐक्सेस टोकन रीफ़्रेश करना

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

ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन Google के ऑथराइज़ेशन सर्वर (https://oauth2.googleapis.com/token) को एचटीटीपीएस POST अनुरोध भेजता है. इस अनुरोध में ये पैरामीटर शामिल होते हैं:

यहां दिया गया स्निपेट, अनुरोध का सैंपल दिखाता है:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

जब तक उपयोगकर्ता ने ऐप्लिकेशन को दिया गया ऐक्सेस रद्द नहीं किया है, तब तक टोकन सर्वर एक JSON ऑब्जेक्ट दिखाता है. इसमें नया ऐक्सेस टोकन होता है. यहां दिया गया स्निपेट, रिस्पॉन्स का एक उदाहरण दिखाता है:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

ध्यान दें कि जारी किए जाने वाले रीफ़्रेश टोकन की संख्या सीमित होती है. हर क्लाइंट/उपयोगकर्ता के कॉम्बिनेशन के लिए एक सीमा और सभी क्लाइंट के लिए हर उपयोगकर्ता के लिए एक सीमा तय होती है. आपको रीफ़्रेश टोकन को लंबे समय तक स्टोर करने की सुविधा में सेव करना चाहिए. साथ ही, जब तक वे मान्य हैं, तब तक उनका ��स्तेमाल करना जारी रखना चाहिए. अगर आपका ऐप्लिकेशन बहुत ज़्यादा रीफ़्रेश टोकन का अनुरोध करता है, तो हो सकता है कि वह इन सीमाओं तक पहुंच जाए. ऐसे में, पुराने रीफ़्रेश टोकन काम करना बंद कर देंगे.

टोकन रद्द करना

कुछ मामलों में, हो सकता है कि उपयोगकर्ता किसी ऐप्लिकेशन को दिया गया ऐक्सेस रद्द करना चाहे. उपयोगकर्ता, खाता सेटिंग पर जाकर, ऐक्सेस रद्द कर सकता है. ज़्यादा जानकारी के लिए, तीसरे पक्ष की ऐसी साइटों और ऐप्लिकेशन से साइट या ऐप्लिकेशन का ऐक्सेस हटाएं जिनके पास आपके खाते का ऐक्सेस है के सहायता दस्तावेज़ में, 'साइट या ऐप्लिकेशन का ऐक्सेस हटाएं' सेक्शन देखें.

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

प्रोग्राम के हिसाब से किसी टोकन को रद्द करने के लिए, आपका ऐप्लिकेशन https://oauth2.googleapis.com/revoke को अनुरोध भेजता है और टोकन को पैरामीटर के तौर पर शामिल करता है:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

टोकन, ऐक्सेस टोकन या रीफ़्रेश टोकन हो सकता है. अगर टोकन ऐक्सेस टोकन है और उससे जुड़ा कोई रीफ़्रेश टोकन है, तो रीफ़्रेश टोकन भी रद्द कर दिया जाएगा.

अगर रद्द करने की प्रोसेस पूरी हो जाती है, तो रिस्पॉन्स का एचटीटीपी स्टेटस कोड 200 होगा. गड़बड़ी की स्थितियों के लिए, गड़बड़ी के कोड के साथ एक एचटीटीपी स्टेटस कोड 400 दिखाया जाता है.

ऐप्लिकेशन को रीडायरेक्ट करने के तरीके

अपने ऐप्लिकेशन को सुरक्षित रखना

इसके बारे में और पढ़ें

IETF के सबसे सही मौजूदा तरीके नेटिव ऐप्लिकेशन के लिए OAuth 2.0 में, यहां बताए गए कई सबसे सही तरीके शामिल हैं.