OAuth म्हणजे काय? “Google सह साइन इन” आणि प्रतिनिधी ॲक्सेस समजावून

OAuth हा एक खुला मानक आहे, जो वापरकर्त्याला त्याचा पासवर्ड न देता एका ॲपला दुसऱ्या सेवेतील त्याच्या खात्यात मर्यादित ॲक्सेस देण्याची परवानगी देतो. जेव्हा तुम्ही “Connect Google Calendar” वर क्लिक करता आणि “Allow this app to see your events?” असे विचारणारी स्क्रीन दिसते, तेव्हा ते OAuth आहे. ॲपला तुम्ही मंजूर केलेल्या गोष्टीसाठीच एक token मिळतो, जो तुम्ही कधीही रद्द करू शकता. तीच यंत्रणा, OpenID Connect नावाच्या अतिरिक्त थरासह, “Google सह साइन इन” आणि तत्सम बटणांना शक्ती देते.

AI सोबत बनवताना OAuth का महत्त्वाचे आहे

ॲप बनवताना दोन सामान्य परिस्थितींमध्ये OAuth दिसतो:

1. सोशल लॉगिन. तुमच्या वापरकर्त्यांनी दुसरा पासवर्ड बनवण्याऐवजी “Google सह साइन इन” (किंवा Apple, Microsoft, GitHub) करावे असे तुम्हाला वाटते. तुमच्या ॲपमध्ये लॉगिन कसे जोडायचे पाहा.
2. वापरकर्त्यांच्या इतर सेवांमधील खात्यांशी जोडणी. तुमच्या ॲपला वापरकर्त्याचे कॅलेंडर वाचायचे आहे, त्याच्या सोशल खात्यावर पोस्ट करायचे आहे, त्याच्या क्लाउड ड्राइव्हवरून फाइल्स आणायच्या आहेत किंवा त्याचा अकाउंटिंग डेटा सिंक करायचा आहे.

दोन्ही प्रकरणांत तुमचा AI बिल्डर कोड लिहू शकतो, पण काही पायऱ्या फक्त तुम्हीच करू शकता: प्रोव्हायडरसोबत डेव्हलपर ॲप तयार करणे, client ID आणि client secret मिळवणे, callback URLs नोंदवणे, आणि काही परवानग्यांसाठी प्रोव्हायडरच्या पुनरावलोकनातून जाणे. OAuth कसे चालते हे माहीत असल्यास त्या पायऱ्या — आणि त्या निर्माण करणाऱ्या एररस् — खूप कमी गूढ वाटतात. लॉगिनचे मोठे चित्र पाहण्यासाठी authentication म्हणजे काय पाहा.

रोजच्या आयुष्यातील उदाहरण

हॉटेलच्या की-कार्डचा विचार करा. चेक-इन करताना फ्रंट डेस्क तुम्ही कोण आहात याची खातरजमा करते, मग तुम्हाला असे कार्ड देते जे तुमची खोली आणि जिम उघडते — इतर खोल्या किंवा स्टाफचे भाग नव्हे — आणि चेकआउटवर ते चालणे थांबवते. कार्डमध्ये तुमचा पासपोर्ट नसतो. कार्ड हरवल्यास डेस्क ते रद्द करते आणि नवीन देते.

• फ्रंट डेस्क म्हणजे authorization server (Google चे साइन-इन पेज).
• तुमची ओळख तपासणी म्हणजे Google मध्ये तुमचे लॉगिन.
• की-कार्ड म्हणजे ॲक्सेस token.
• “फक्त खोली आणि जिम” म्हणजे तुम्ही मंजूर केलेले scopes.
• चेकआउट म्हणजे token ची मुदत संपणे, किंवा तुम्ही ॲक्सेस रद्द करणे.

तुम्ही वापरत असलेल्या ॲपला तुमचा Google पासवर्ड कधीच दिसत नाही, फक्त की-कार्ड दिसते.

OAuth टप्प्याटप्प्याने कसे चालते

वेब ॲप्ससाठी सर्वात सामान्य फ्लो म्हणजे authorization code flow. वापरकर्ता एका शेड्युलिंग ॲपला त्याचे Google Calendar जोडतो तेव्हा काय होते ते येथे आहे:

1. क्लिक. वापरकर्ता “Connect Google Calendar” वर क्लिक करतो.
2. प्रोव्हायडरकडे redirect. ॲप ब्राउझरला त्याच्या client ID, हव्या असलेल्या scopes (कॅलेंडर इव्हेंट्स वाचणे) आणि Google ने वापरकर्त्याला परत पाठवायचा redirect URI सह Google कडे पाठवतो.
3. लॉग इन आणि संमती. वापरकर्ता (आधीच नसल्यास) Google मध्ये साइन इन करतो आणि ॲप काय मागत आहे ते दाखवणारी संमती स्क्रीन पाहतो. तो Allow वर क्लिक करतो.
4. कोडसह परत. Google ब्राउझरला ॲपच्या redirect URI वर एका अल्पकाळ टिकणाऱ्या, एकदाच वापरता येणाऱ्या authorization code सह परत पाठवते.
5. सर्व्हरवर बदलणे. ॲपचा सर्व्हर तो कोड, त्याच्या client secret सह, थेट Google ला पाठवतो आणि एक access token (आणि अनेकदा refresh token) मिळवतो.
6. API वापरणे. सर्व्हर ॲक्सेस token सह Google Calendar API कॉल करतो आणि वापरकर्त्याचे इव्हेंट्स मिळवतो.

पायरी 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 ची देवाणघेवाण सर्व्हर-ते-सर्व्हर होते, त्यामुळे client secret आणि tokens ला ब्राउझरमधून कधीच जावे लागत नाही.

OAuth विरुद्ध OpenID Connect विरुद्ध तुमचे स्वतःचे लॉगिन

अनेक ॲप्स त्यांना एकत्र करतात: ईमेल-आणि-पासवर्ड लॉगिन, OIDC द्वारे “Google सह साइन इन”, आणि इतर सेवांशी वेगळी OAuth जोडणी.

मुख्य संज्ञा

सामान्य गैरसमज

• “OAuth ही लॉगिन प्रणाली आहे.” साधा OAuth ॲक्सेस देतो; OpenID Connect ओळख हाताळतो. कोण आहे याचा पुरावा म्हणून साधा access token वापरल्याने खरे सुरक्षा बग्स झाले आहेत.
• “ॲपला माझा पासवर्ड मिळतो.” ते कधीच होत नाही. हेच तर त्याचे उद्दिष्ट आहे.
• “जास्त scopes मागणे निरुपद्रवी आहे.” वापरकर्ते व्यापक विनंत्यांबद्दल अधिक सावध असतात, आणि Google सारखे प्रोव्हायडर्स संवेदनशील किंवा प्रतिबंधित scopes साठी ॲप पुनरावलोकन मागू शकतात. तुम्हाला जे लागते तेवढेच मागा.
• “क्लायंट सिक्रेट फ्रंटएंडमध्ये ठेवता येते.” ब्राउझर कोडमधील काहीही सार्वजनिक असते. ते सर्व्हर-साइड सिक्रेट्स मध्ये ठेवा.
• “चाचणीत चालते, म्हणजे प्रॉडक्शनमध्येही चालेल.” प्रोव्हायडर्स अनेकदा सत्यापित नसलेल्या ॲप्सना मर्यादित करतात — उदाहरणार्थ, सूचीबद्ध चाचणी वापरकर्त्यांपुरते — आणि तुमच्या लाइव्ह डोमेनसाठी redirect URI वेगळा नोंदवावा लागतो.
• “Tokens कायमचे टिकतात.” Access tokens लवकर संपतात, आणि वापरकर्ते ॲक्सेस रद्द करू शकतात. तुमच्या ॲपने दोन्ही व्यवस्थित हाताळले पाहिजे.

तुमच्या AI बिल्डरला काय मागावे

• “OpenID Connect वापरून ‘Google सह साइन इन’ जोडा, एका सुस्थापित auth लायब्ररीसह — OAuth फ्लो हाताने लिहू नका.”
• “PKCE सह authorization code flow वापरा आणि state पॅरामीटर तपासा.”
• “Client ID आणि client secret सर्व्हरवरील environment variables मधून वाचा.”
• “फक्त आवश्यक scopes मागा: फक्त-वाचन कॅलेंडर ॲक्सेस.”
• “प्रोव्हायडरच्या कन्सोलमध्ये मला नोंदवावे लागणारे प्रत्येक redirect URL सांगा — प्रिव्ह्यू, प्रकाशित URL आणि माझे कस्टम डोमेन यासाठी.”
• “Refresh tokens डेटाबेसमध्ये एन्क्रिप्ट करून साठवा, आणि मुदत संपलेले किंवा रद्द झालेले tokens वापरकर्त्याला पुन्हा कनेक्ट करण्यास सांगून हाताळा.”
• “वापरकर्त्यांना त्यांच्या सेटिंग्ज पेजवरून इंटिग्रेशन डिस्कनेक्ट करू देऊ द्या.”

OAuth आणि Mythex

Mythex मध्ये तुम्ही बनवलेल्या ॲप्ससाठी अंगभूत एंड-यूजर लॉगिन नाही; त्याचे डॉक्स “स्वतःचे आणा” (bring-your-own) दृष्टिकोन वर्णन करतात — तुम्ही auth लायब्ररी किंवा होस्टेड प्रोव्हायडर निवडता, त्याच्या keys प्रोजेक्ट सिक्रेट्स म्हणून साठवता, आणि एजंट कोड लिहितो. यासाठी authentication जोडण्याच्या रेसिपी मध्ये सुरुवातीचा प्रॉम्प्ट आहे. Mythex स्वतःमध्येही तुम्हाला OAuth भेटेल: तुम्ही Google सह साइन अप करू शकता, रेपो सिंकसाठी GitHub जोडणे GitHub OAuth वापरते, आणि MCP द्वारे Mythex ला जोडणारे AI क्लायंट्स OAuth संमती पेजमधून जातात. अधिक माहितीसाठी authentication म्हणजे काय आणि टू-फॅक्टर ऑथेंटिकेशन म्हणजे काय पाहा.

प्रश्न