OAuth क्या है? “Google से sign in” और delegated access समझें

OAuth एक खुला standard है जो किसी उपयोगकर्ता को अपने account तक सीमित पहुँच एक app को देने देता है, बिना अपना password सौंपे। जब आप “Connect Google Calendar” पर क्लिक करते हैं और एक स्क्रीन दिखती है जो पूछती है “क्या यह app आपके events देख सकता है?”, तो वह OAuth है। App को ठीक उतनी ही चीज़ के लिए एक token मिलता है जिसे आपने मंज़ूर किया है, और आप उसे कभी भी रद्द कर सकते हैं। यही तंत्र, एक अतिरिक्त परत OpenID Connect के साथ, “Sign in with Google” और ऐसे बटनों को चलाता है।

AI से बनाते समय OAuth क्यों मायने रखता है

आप app बनाते समय OAuth दो आम स्थितियों में आता है:

Social login। आप चाहते हैं कि आपके उपयोगकर्ता नया password बनाने के बजाय “Sign in with Google” (या Apple, Microsoft, GitHub) से login करें। देखें अपने app में login कैसे जोड़ें।
उपयोगकर्ताओं के दूसरी services पर accounts से जुड़ना। आपके app को किसी उपयोगकर्ता का calendar पढ़ना है, उसके social account पर पोस्ट करना है, उसके cloud drive से files लेनी हैं, या उसका accounting data sync करना है।

दोनों मामलों में आपका AI builder code लिख सकता है, पर कुछ कदम सिर्फ आप कर सकते हैं: provider के साथ developer app बनाना, client ID और client secret लेना, callback URLs दर्ज करना, और कुछ permissions के लिए provider की समीक्षा पास करना। OAuth कैसे काम करता है, यह जानने से वे कदम और उनसे आने वाली errors कम रहस्यमय लगती हैं। Login की बड़ी तस्वीर के लिए देखें authentication क्या है।

रोज़ की मिसाल

एक होटल की key card सोचिए। Check-in पर फ्रंट डेस्क पुष्टि करता है कि आप कौन हैं, फिर आपको एक card देता है जो आपके कमरे और जिम के दरवाज़े खोलता है, दूसरे कमरे या staff क्षेत्र नहीं, और checkout पर काम करना बंद कर देता है। Card में आपका पासपोर्ट नहीं होता। खो जाए तो डेस्क उसे रद्द करके नया जारी कर देता है।

फ्रंट डेस्क authorization server है (Google का sign-in पन्ना)।
आपकी पहचान की जाँच वह है जब आप Google में login करते हैं।
Key card access token है।
“सिर्फ कमरा और जिम” वे scopes हैं जिन्हें आपने मंज़ूर किया।
Checkout token का expire होना है, या आपका access रद्द करना।

जिस app को आप इस्तेमाल कर रहे हैं, उसने आपका Google password कभी नहीं देखा, सिर्फ key card देखा।

OAuth कदम-दर-कदम कैसे काम करता है

Web apps के लिए सबसे आम flow authorization code flow है। जब कोई उपयोगकर्ता किसी scheduling app से अपना Google Calendar जोड़ता है, तो यह होता है:

क्लिक। उपयोगकर्ता “Connect Google Calendar” पर क्लिक करता है।
Provider पर redirect। App browser को Google पर भेजता है, अपने client ID, माँगे गए scopes (calendar events पढ़ना) और redirect URI के साथ, जहाँ Google उपयोगकर्ता को वापस भेजे।
Login और सहमति। उपयोगकर्ता Google में sign in करता है (अगर पहले से नहीं है) और सहमति स्क्रीन देखता है जिसमें लिखा है कि app क्या माँग रहा है। वह Allow पर क्लिक करता है।
Code के साथ वापस। Google browser को app के redirect URI पर एक छोटे-समय के, एक-बार इस्तेमाल होने वाले authorization code के साथ वापस भेजता है।
Server पर बदलना। App का server वह code, और अपना client secret, सीधे Google को भेजता है और एक access token (और अक्सर एक refresh token) प्राप्त करता है।
API इस्तेमाल करें। Server access token के साथ Google Calendar API को कॉल करता है और उपयोगकर्ता के events लेता है।

चरण 4 का callback कुछ ऐसा दिखता है:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

और चरण 5 का token response JSON में ऐसा होता है:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

डिज़ाइन का महत्वपूर्ण बिंदु: token का आदान-प्रदान server-से-server होता है, इसलिए client secret और tokens को कभी browser से नहीं गुज़रना पड़ता।

	यह किस सवाल का जवाब देता है	उदाहरण
OAuth 2.0	“इस app को उपयोगकर्ता की ओर से क्या करने की अनुमति है?” (authorization)	उपयोगकर्ता का calendar पढ़ना
OpenID Connect (OIDC)	“यह उपयोगकर्ता कौन है?” (authentication), OAuth पर बना	“Google से sign in” एक सत्यापित email लौटाता है
आपका अपना login	“क्या यह उस account के लिए सही password है?”	Email और password (hashed) आपके database में सहेजे गए

कई apps इन्हें मिलाते हैं: email-और-password login, साथ में OIDC के ज़रिए “Google से sign in”, और दूसरी services के लिए अलग OAuth connections।

मुख्य शब्द

शब्द	अर्थ
Provider / authorization server	वह service जिसमें उपयोगकर्ता login करता है और access देता है, जैसे Google, Microsoft, GitHub।
Client	आपका app, provider के साथ पंजीकृत रूप में।
Client ID	Provider के साथ आपके app का सार्वजनिक पहचानकर्ता।
Client secret	Provider के साथ आपके app का निजी password। केवल server पर।
Scope	एक खास permission, जैसे “calendar पढ़ना” या “email पता देखना”।
Consent screen	वह पन्ना जहाँ उपयोगकर्ता माँगे गए scopes देखता और मंज़ूर करता है।
Redirect URI / callback URL	वह जगह जहाँ provider उपयोगकर्ता को वापस भेजता है। पहले से पंजीकृत होना चाहिए और हूबहू मेल खाना चाहिए।
Access token	API कॉल करने के लिए छोटे-समय का credential।
Refresh token	नए access tokens लेने के लिए लंबे समय का credential। इसे password की तरह सहेजें।
ID token	OIDC में, एक हस्ताक्षरित token जो बताता है कि उपयोगकर्ता कौन है।
PKCE	एक अतिरिक्त जाँच (“proof key”) जो रोकती है कि अवरोधित codes इस्तेमाल हों। सभी clients के लिए सुझाई जाती है।
state	एक यादृच्छिक मान जो flow को नकली अनुरोधों से बचाता है।

आम गलतफहमियाँ

“OAuth एक login system है।” सादा OAuth access देता है; OpenID Connect पहचान संभालता है। किसी उपयोगकर्ता की पहचान साबित करने के लिए सिर्फ access token इस्तेमाल करने से असली सुरक्षा bugs हुए हैं।
“App को मेरा password मिल जाता है।” ऐसा कभी नहीं होता। यही इसका मकसद है।
“ज़्यादा scopes माँगना हानिरहित है।” उपयोगकर्ता व्यापक अनुरोधों से सतर्क रहते हैं, और Google जैसे providers संवेदनशील या प्रतिबंधित scopes के लिए app समीक्षा माँग सकते हैं। सिर्फ वही माँगें जो चाहिए।
“Client secret को frontend में रखा जा सकता है।” Browser code में जो भी है वह सार्वजनिक है। उसे server-side secrets में रखें।
“टेस्टिंग में चला तो production में भी चलेगा।” Providers अक्सर असत्यापित apps को सीमित करते हैं, जैसे सूचीबद्ध test users तक, और आपके live domain का redirect URI अलग से पंजीकृत करना होता है।
“Tokens हमेशा चलते हैं।” Access tokens जल्दी expire होते हैं, और उपयोगकर्ता access रद्द कर सकते हैं। आपके app को दोनों को सही ढंग से संभालना होगा।

अपने AI builder से क्या माँगें

“OpenID Connect के साथ “Google से sign in” जोड़ो, किसी अच्छी तरह से रखी जाने वाली auth library के साथ, OAuth flow हाथ से मत लिखो।”
“PKCE के साथ authorization code flow इस्तेमाल करो और state parameter की जाँच करो।”
“Client ID और client secret server पर environment variables से पढ़ो।”
“सिर्फ ज़रूरी scopes माँगो: केवल-पढ़ने वाला calendar access।”
“मुझे बताओ कि provider के console में कौन-से हर redirect URL दर्ज करने हैं: preview, published URL और मेरे custom domain के लिए।”
“Refresh tokens को database में encrypted रखो, और expired या रद्द tokens को इस तरह संभालो कि उपयोगकर्ता से फिर से connect करने को कहा जाए।”
“उपयोगकर्ताओं को अपनी settings पेज से integration disconnect करने दो।”

Mythex और OAuth

Mythex के पास उन apps के लिए अंतर्निहित end-user login नहीं है जो आप बनाते हैं; इसके docs एक bring-your-own तरीका बताते हैं: आप कोई auth library या hosted provider चुनते हैं, उसकी keys को project secrets में रखते हैं, और agent code लिखता है। authentication जोड़ने की recipe में इसके लिए एक starter prompt है। Mythex में आप खुद भी OAuth से मिलते हैं: आप Google से sign up कर सकते हैं, repo sync के लिए GitHub जोड़ना GitHub OAuth इस्तेमाल करता है, और Mythex से MCP पर जुड़ने वाले AI clients एक OAuth consent पन्ने से गुज़रते हैं। ज़्यादा जानकारी के लिए देखें authentication क्या है और two-factor authentication क्या है।

सवाल

सरल शब्दों में OAuth क्या है?

OAuth एक मानक तरीका है जिससे कोई उपयोगकर्ता एक app को दूसरी service पर अपने account तक पहुँच दे सकता है, जैसे किसी scheduling app को अपना Google Calendar पढ़ने देना, बिना उस app को अपना password दिए। उपयोगकर्ता खास permissions मंज़ूर करता है, और app को एक token मिलता है जो सिर्फ उन्हीं के लिए काम आता है।

क्या OAuth वही है जो “Google से sign in” है?

“Google से sign in” OAuth 2.0 और OpenID Connect पर बना है। OpenID Connect OAuth के ऊपर की एक परत है, जो यह बताने का मानक तरीका जोड़ती है कि उपयोगकर्ता कौन है। OAuth अपने आप में access देने के बारे में है; OpenID Connect उसे login बनाता है।

OAuth access token क्या है?

Access token वह credential है जिसे app किसी service के API को भेजता है, यह साबित करने के लिए कि उसे access मिला है। यह आम तौर पर थोड़े समय के लिए होता है और उपयोगकर्ता द्वारा मंज़ूर किए गए permissions (scopes) तक सीमित होता है। Refresh token, अगर जारी हुआ हो, तो app को उपयोगकर्ता से दोबारा पूछे बिना नए access tokens लेने देता है।

redirect_uri_mismatch का क्या मतलब है?

इसका मतलब है कि sign-in के दौरान आपके app द्वारा भेजा गया callback URL, provider के developer console में दर्ज URL से हूबहू मेल नहीं खाता। हर उस पते के लिए जहाँ आपका app चलता है, सटीक URL जोड़ें, जिसमें https, domain, path और कोई trailing slash भी शामिल हो।

क्या OAuth सुरक्षित है?

OAuth 2.0 व्यापक रूप से इस्तेमाल होता है और सही तरीके से लागू होने पर सुरक्षित है: PKCE के साथ authorization code flow, सटीक redirect URLs, state parameter, और client secret व tokens को server पर रखना। ज़्यादातर समस्याएँ लागू करने में शॉर्टकट से आती हैं, इसीलिए किसी अच्छी तरह से रखी जाने वाली library का इस्तेमाल सुझाया जाता है।