OAuth क्लाइंट कैसे बनाएँ

API संस्करण 2026-10-affable-towhee

इंटीग्रेशन पेज पर “क्लाइंट बनाएँ” दबाने से पहले तीन बातें तय करें: क्लाइंट क्या कर सकता है, कौन-सी प्रोसेस उसका सीक्रेट रखती है, और उसकी कॉल का भुगतान कौन करता है। प्रमाणीकरण गाइड नियम बताती है; यह पेज उन्हें दो काल्पनिक कंपनियों, Luba और Farducks, पर लागू करता है।

Luba: Dive Deck

Luba परिवहन और राइड-शेयर सेवा के रूप में स्वायत्त पनडुब्बियाँ चलाती है। उसका Dive Deck हर यात्री को केबिन की स्क्रीन पर गोते का एक वाक्यांश दिखाता है, उस भाषा में जो वह सीख रहा है, और Luba की ऑपरेशंस टीम देखती है कि भत्ते में से कितना बचा है।

Luba एक क्लाइंट बनाती है, Luba Dive Deck, जिसे “शब्दावली बनाएँ” (vocab:generate) और “उपयोग पढ़ें” (usage:read) की अनुमति है, और जिसका बिल “आपके प्लान की सीमा” (allowance) पर जाता है। दो प्रोसेस इसे साझा करती हैं, और हर एक एक्सचेंज के समय केवल वही स्कोप माँगती है जो उसे चाहिए। जो एक्सचेंज scope छोड़ देता है, उसे क्लाइंट को अनुमत हर स्कोप मिलता है; जो एक्सचेंज ऐसा स्कोप माँगता है जिसकी क्लाइंट को अनुमति नहीं है, वह पूरा का पूरा invalid_scope के साथ अस्वीकार कर दिया जाता है, उसे कभी चुपचाप सीमित नहीं किया जाता।

डिस्पैच सर्वर हर गोते के वाक्यांश लिखता है। वह केवल vocab:generate माँगता है, इसलिए उससे लीक हुआ टोकन Luba का उपयोग नहीं पढ़ सकता।

export LINGARA_TOKEN="$(curl -sS --fail-with-body -X POST "https://api.getlingara.com/oauth/token" \
  -u "$LINGARA_CLIENT_ID:$LINGARA_CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  --data-urlencode "scope=vocab:generate" | jq -r '.access_token // error(.error)')"

curl -N -X POST "https://api.getlingara.com/v1/vocab/stream" \
  -H "Authorization: Bearer $LINGARA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"level":2,"source_lang":"en","target_lang":"zh","count":8}'

ऑपरेशंस डैशबोर्ड उसी क्लाइंट ID और सीक्रेट वाली दूसरी सर्वर-साइड प्रोसेस है। वह केवल usage:read माँगता है, और पढ़ता है कि भत्ते में से कितना बचा है।

export LINGARA_TOKEN="$(curl -sS --fail-with-body -X POST "https://api.getlingara.com/oauth/token" \
  -u "$LINGARA_CLIENT_ID:$LINGARA_CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  --data-urlencode "scope=usage:read" | jq -r '.access_token // error(.error)')"

curl "https://api.getlingara.com/v1/usage" \
  -H "Authorization: Bearer $LINGARA_TOKEN"

दोनों प्रोसेस Luba के सर्वर पर चलती हैं। केबिन का टैबलेट डिस्पैच सर्वर से वाक्यांश माँगता है और कभी सीक्रेट या टोकन नहीं रखता, क्योंकि जिस डिवाइस को यात्री छू सकता है, उस पर मौजूद कुछ भी पढ़ा जा सकता है। प्रमाणीकरण गाइड का “सीक्रेट और टोकन सर्वर पर रखें” खंड बताता है कि क्यों।

यही क्लाइंट एक प्रोजेक्ट के रूप में, जिसे आप क्लोन करके चला सकते हैं: integrations/luba-dive-deck

Farducks: Batter Rewards

Farducks फ़िश एंड चिप्स सुविधा स्टोर की एक चेन है। जब कोई ऑर्डर तला जा रहा होता है, Batter Rewards लॉयल्टी ऐप Farducks के अपने बैकएंड से एक छोटी पाठ योजना माँगता है, फिर उसे वापस पढ़ता है। ऐप और बिलिंग काउंटर Farducks के बैकएंड को कॉल करते हैं, Lingara को कभी नहीं, इसलिए दोनों में से किसी के पास सीक्रेट नहीं होता।

Farducks एक क्लाइंट बनाती है, Farducks Batter Rewards, जिसे “पाठ योजनाएँ बनाएँ” (lesson_plans:write) और “पाठ योजनाएँ पढ़ें” (lesson_plans:read) की अनुमति है, और जिसका बिल “आपके प्लान की सीमा” (allowance) पर जाता है। आज कोई क्लाइंट केवल इसी बिलिंग के साथ बनाया जा सकता है, और क्लाइंट की बिलिंग उसे बनाते समय तय हो जाती है। दूसरा तरीका, metered (“उपयोग के अनुसार भुगतान”), प्रमाणीकरण गाइड के “कॉल का भुगतान कौन करता है” खंड में बताया गया है।

बैकएंड केवल lesson_plans:write माँगता है और योजना बनाता है। जवाब स्ट्रीम होता है, और उसके started इवेंट में योजना का plan_id होता है।

export LINGARA_TOKEN="$(curl -sS --fail-with-body -X POST "https://api.getlingara.com/oauth/token" \
  -u "$LINGARA_CLIENT_ID:$LINGARA_CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  --data-urlencode "scope=lesson_plans:write" | jq -r '.access_token // error(.error)')"

curl -N -X POST "https://api.getlingara.com/v1/lesson-plans" \
  -H "Authorization: Bearer $LINGARA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"context":"Ordering food at a night market","source_lang":"en","target_lang":"zh","level":2}'

ID को उस plan_id पर सेट करें, फिर lesson_plans:read माँगें और योजना वापस पढ़ें। एक एक्सचेंज क्लाइंट के कई स्कोप माँग सकता है, scope में स्पेस से अलग करके; यहाँ हर कमांड एक ही स्कोप माँगती है, क्योंकि हर कमांड एक ही कॉल से बनी है।

export LINGARA_TOKEN="$(curl -sS --fail-with-body -X POST "https://api.getlingara.com/oauth/token" \
  -u "$LINGARA_CLIENT_ID:$LINGARA_CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  --data-urlencode "scope=lesson_plans:read" | jq -r '.access_token // error(.error)')"

curl "https://api.getlingara.com/v1/lesson-plans/$ID" \
  -H "Authorization: Bearer $LINGARA_TOKEN"

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

यही क्लाइंट एक प्रोजेक्ट के रूप में, जिसे आप क्लोन करके चला सकते हैं: integrations/farducks-batter-rewards

आगे कहाँ जाएँ

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

यदि किसी अनुवाद और अंग्रेज़ी संदर्भ में अंतर हो, तो अंग्रेज़ी संदर्भ ही मान्य है।