OAuth 2.0: यह क्या है और प्राधिकरण प्रोटोकॉल कैसे काम करता है

OAuth 2.0 क्या है?

OAuth 2.0 एक प्राधिकरण प्रोटोकॉल है जो IETF RFC 6749 में परिभाषित है, जो तीसरे पक्ष के अनुप्रयोगों को उपयोगकर्ता का उपयोगकर्ता नाम और पासवर्ड प्रकट किए बिना उसके संसाधनों तक सीमित पहुँच प्राप्त करने की अनुमति देता है। प्रोटोकॉल पासवर्ड मॉडल की एक मूलभूत समस्या को हल करता है: एक एप्लिकेशन जिसे आप अपना पासवर्ड सौंपते हैं, उसे सभी खाता डेटा तक असीमित पहुँच मिल जाती है। OAuth 2.0 स्पष्ट रूप से सीमित पहुँच क्षेत्र के साथ एक अस्थायी टोकन जारी करके इस दृष्टिकोण को बदलता है।

OAuth 2.0 की वास्तुकला प्रतिनिधि प्राधिकरण है। उपयोगकर्ता (Resource Owner) एक एप्लिकेशन (Client) को एक मध्यस्थ: प्राधिकरण सर्वर (Authorization Server) के माध्यम से संसाधन सर्वर (Resource Server) पर संग्रहीत अपने डेटा तक पहुँचने के लिए अधिकृत करता है। प्राधिकरण सर्वर एक Access Token जारी करता है: एक क्रिप्टोग्राफ़िक स्ट्रिंग जिसे एप्लिकेशन डेटा तक पहुँचने के लिए संसाधन सर्वर को प्रस्तुत करता है। OAuth 2.0 और SAML या OpenID Connect के बीच एक महत्वपूर्ण अंतर: OAuth 2.0 प्राधिकरण कार्य (क्या अनुमति है) को हल करता है, प्रमाणीकरण (उपयोगकर्ता कौन है) को नहीं। प्रमाणीकरण के लिए OAuth 2.0 के ऊपर OpenID Connect (OIDC) प्रोटोकॉल बनाया गया है।

प्रोटोकॉल सभी प्रमुख प्लेटफ़ॉर्म द्वारा समर्थित है। Google Google APIs (Gmail, Drive, Calendar) तक पहुँचने के लिए OAuth 2.0 का उपयोग करता है, Facebook Graph API के लिए, Apple Sign in with Apple (ASAuthorizationAppleIDProvider) के लिए, और GitHub रिपॉजिटरी तक पहुँच के लिए। मोबाइल डेवलपमेंट के संदर्भ में, OAuth 2.0 तृतीय-पक्ष सेवाओं को एकीकृत करने का मानक तंत्र है: सोशल नेटवर्क के माध्यम से लॉगिन, क्लाउड स्टोरेज तक पहुँच, और उपयोगकर्ता की ओर से सामग्री प्रकाशित करना।

OAuth 2.0 की भूमिकाएँ और घटक

OAuth 2.0 प्रोटोकॉल चार भूमिकाएँ परिभाषित करता है जिनकी परस्पर क्रिया पूर्ण प्राधिकरण चक्र बनाती है। मोबाइल एप्लिकेशन में प्रोटोकॉल को सही ढंग से लागू करने के लिए प्रत्येक भूमिका को समझना आवश्यक है।

प्रोटोकॉल की चार भूमिकाएँ

प्रोटोकॉल की प्रमुख संस्थाएँ Access Token, Refresh Token और Authorization Code हैं। Access Token एक अल्पकालिक टोकन है (आमतौर पर 15–60 मिनट) जो प्रत्येक डेटा अनुरोध के साथ संसाधन सर्वर को प्रस्तुत किया जाता है। Refresh Token एक दीर्घकालिक टोकन है (दिन या सप्ताह) जिसका उपयोग उपयोगकर्ता को फिर से लॉग इन किए बिना नया Access Token प्राप्त करने के लिए किया जाता है। Authorization Code एक अस्थायी कोड है जो उपयोगकर्ता प्राधिकरण के बाद जारी किया जाता है और Access Token और Refresh Token के लिए विनिमय किया जाता है।

Grant Types: प्राधिकरण परिदृश्य

OAuth 2.0 कई Grant Types को परिभाषित करता है: टोकन प्राप्त करने के परिदृश्य, प्रत्येक एक विशिष्ट प्रकार के क्लाइंट और सुरक्षा संदर्भ के लिए डिज़ाइन किया गया है। मोबाइल एप्लिकेशन में प्राधिकरण डिज़ाइन करते समय सही Grant Type चुनना एक महत्वपूर्ण वास्तुशिल्प निर्णय है।

मुख्य Grant Types हैं: Authorization Code (सर्वर घटक वाले मोबाइल और वेब अनुप्रयोगों के लिए सबसे सुरक्षित), Authorization Code with PKCE (Proof Key for Code Exchange: सर्वर बैकएंड के बिना मोबाइल और SPA अनुप्रयोगों के लिए), Client Credentials (उपयोगकर्ता की भागीदारी के बिना सर्वर-टू-सर्वर प्रमाणीकरण के लिए), Resource Owner Password Credentials (पदावनत: सीधे पासवर्ड संचारित करता है)। OAuth Security BCP (RFC 9700) की अनुशंसाओं के अनुसार PKCE सार्वजनिक क्लाइंट (मोबाइल एप्लिकेशन, SPA) के लिए अनिवार्य विस्तार है।

मुख्य Grant Types

• Authorization Code + PKCE: देशी मोबाइल अनुप्रयोगों के लिए अनुशंसित Grant Type। क्लाइंट एक क्रिप्टोग्राफ़िक code_verifier उत्पन्न करता है, code_challenge (SHA-256 हैश) की गणना करता है, और सर्वर टोकन के लिए कोड का आदान-प्रदान करते समय मिलान सत्यापित करता है। यह एप्लिकेशन और सर्वर के बीच authorization code को इंटरसेप्ट होने से रोकता है
• Client Credentials: मशीन-टू-मशीन प्राधिकरण के लिए उपयोग किया जाता है जहाँ क्लाइंट ज्ञात और प्रमाणित है। एप्लिकेशन अपने client_id और client_secret का उपयोग करके टोकन प्राप्त करता है। उपयोगकर्ता की भागीदारी की आवश्यकता नहीं है। विशिष्ट परिदृश्य: एक सर्वर एप्लिकेशन बैच डेटा प्रोसेसिंग के लिए API को कॉल करता है
• Device Authorization Grant: बिना ब्राउज़र वाले उपकरणों (Smart TV, IoT) के लिए। उपयोगकर्ता किसी अन्य उपकरण पर एक लिंक का अनुसरण करता है और एक कोड दर्ज करता है। उदाहरण के लिए, स्मार्टफ़ोन के माध्यम से टीवी पर Netflix को अधिकृत करते समय उपयोग किया जाता है
• Resource Owner Password Credentials: एक पदावनत Grant Type जो OAuth Security BCP द्वारा निषिद्ध है। पासवर्ड सीधे क्लाइंट को प्रेषित किया जाता है, जो शून्य-ज्ञान प्रमाणीकरण सिद्धांत का उल्लंघन करता है। केवल विरासत प्रणालियों से माइग्रेशन के लिए उपयोग किया जाता है

मोबाइल अनुप्रयोगों के लिए PKCE के साथ Authorization Code Flow

PKCE के साथ Authorization Code Flow देशी मोबाइल अनुप्रयोगों के लिए अनुशंसित OAuth 2.0 कॉन्फ़िगरेशन है। PKCE (Proof Key for Code Exchange) सुरक्षा की एक अतिरिक्त परत जोड़ता है जो authorization code इंटरसेप्शन हमलों को रोकता है। प्रोटोकॉल IETF RFC 7636 में वर्णित है।

PKCE चरण-दर-चरण अनुक्रम

चरणों का अनुक्रम: (1) क्लाइंट एक यादृच्छिक code_verifier उत्पन्न करता है (43–128 वर्णों की एक स्ट्रिंग जिसमें केवल आरक्षित वर्ण नहीं हैं), (2) क्लाइंट code_challenge = SHA-256(code_verifier) की गणना करता है, (3) क्लाइंट Authorization Server पर उपयोगकर्ता प्राधिकरण के लिए एक ब्राउज़र खोलता है, code_challenge पास करता है, (4) सफल प्राधिकरण के बाद, सर्वर कस्टम URI योजना (ऐप डीप लिंक) के माध्यम से एप्लिकेशन को authorization code लौटाता है, (5) क्लाइंट सर्वर को authorization code + code_verifier भेजता है, (6) सर्वर SHA-256(code_verifier) === code_challenge सत्यापित करता है और Access Token + Refresh Token जारी करता है।

PKCE का लाभ: भले ही कोई हमलावर URI योजना में authorization code को इंटरसेप्ट कर ले, वह code_verifier के बिना इसे टोकन के लिए विनिमय नहीं कर सकता, जो केवल वैध क्लाइंट को ज्ञात है। मोबाइल अनुप्रयोगों में, ब्राउज़र खोलने के लिए Chrome Custom Tabs (Android) या ASWebAuthenticationSession (iOS) का उपयोग करना चाहिए: यह सुनिश्चित करता है कि सिस्टम ब्राउज़र एप्लिकेशन की मेमोरी से code_verifier तक नहीं पहुँच सकता।

AppAuth के माध्यम से Android पर OAuth 2.0 का कार्यान्वयन

AppAuth IETF द्वारा अनुशंसित देशी अनुप्रयोगों के लिए OAuth 2.0 और OpenID Connect का संदर्भ कार्यान्वयन है। लाइब्रेरी PKCE, Chrome Custom Tabs, authorization code वापस करने के लिए कस्टम URI योजनाएँ और स्वचालित टोकन रिफ्रेश का समर्थन करती है। Android के लिए AppAuth `net.openid:appauth:0.11.1` निर्भरता के माध्यम से उपलब्ध है।

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// प्राधिकरण के लिए Chrome Custom Tab लॉन्च करना
startActivityForResult(intent, REQUEST_CODE_AUTH)

authorization code (onActivityResult) प्राप्त करने के बाद, एप्लिकेशन इसे TokenRequest के माध्यम से Access Token और Refresh Token में बदलता है। टोकन EncryptedSharedPreferences (Android Security Crypto) के माध्यम से एन्क्रिप्शन के साथ SharedPreferences में सहेजे जाते हैं। Refresh Token को KeyStore में संग्रहीत किया जाना चाहिए: एक हार्डवेयर-आधारित कुंजी स्टोर जो अन्य अनुप्रयोगों के लिए दुर्गम है। हर बार Access Token की समय सीमा समाप्त होने पर, एप्लिकेशन नया प्राप्त करने के लिए Refresh Token का उपयोग करता है: उपयोगकर्ता को फिर से प्रमाणित करने की आवश्यकता नहीं है।

// authorization code को टोकन में बदलना
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token और Refresh Token प्राप्त हुए
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // EncryptedSharedPreferences में सहेजें
        saveTokens(accessToken, refreshToken)
    }
}

उपरोक्त कोड PKCE के साथ पूर्ण OAuth 2.0 प्रवाह प्रदर्शित करता है: OpenID Connect Discovery के माध्यम से सर्वर कॉन्फ़िगरेशन बनाना, code_verifier के साथ प्राधिकरण अनुरोध उत्पन्न करना, Chrome Custom Tab लॉन्च करना, कस्टम URI योजना के माध्यम से authorization code प्राप्त करना, और Token Request के माध्यम से टोकन के लिए कोड का आदान-प्रदान करना। Access Token की समय सीमा समाप्ति को संभालना महत्वपूर्ण है: Resource Server से HTTP 401 प्रतिक्रिया प्राप्त करने पर, एप्लिकेशन को नया Access Token प्राप्त करने के लिए Refresh Token का उपयोग करना चाहिए और अनुरोध को फिर से निष्पादित करना चाहिए।

OAuth 2.0 सुरक्षा: सामान्य हमले और सुरक्षा

OAuth 2.0 कई हमले वैक्टर वाला एक जटिल प्रोटोकॉल है। IETF Security BCP (RFC 9700) OAuth 2.0 कमजोरियों की 20 से अधिक श्रेणियों का वर्णन करता है। मोबाइल अनुप्रयोगों के लिए, सबसे महत्वपूर्ण हैं: कस्टम URI योजनाओं के माध्यम से authorization code इंटरसेप्शन, कॉलबैक एंडपॉइंट पर CSRF हमले, असुरक्षित स्टोरेज से Refresh Token की चोरी, और इंटेंट इंटरसेप्शन के माध्यम से क्लाइंट प्रतिरूपण।

इन हमलों से सुरक्षा में अनिवार्य उपाय शामिल हैं: (1) S256 code_challenge के साथ PKCE: URI योजना के इंटरसेप्ट होने पर भी authorization code इंटरसेप्शन को रोकता है; (2) CSRF को रोकने के लिए nonce या state पैरामीटर का उपयोग: सर्वर सत्यापित करता है कि authorization code मूल अनुरोध से मेल खाता है; (3) Refresh Token को केवल KeyStore (Android) या Keychain (iOS) में संग्रहीत करना: SharedPreferences या UserDefaults में नहीं; (4) परिवहन स्तर पर MITM से बचाव के लिए Certificate Pinning के साथ TLS का उपयोग; (5) redirect_uri का सत्यापन: प्राधिकरण सर्वर को पंजीकृत URI के साथ इसका सख्ती से मिलान करना चाहिए।

IETF से अतिरिक्त अनुशंसाएँ: मोबाइल अनुप्रयोगों को AppAuth या समान लाइब्रेरी का उपयोग करना चाहिए जो सुरक्षा ऑडिट से गुज़री हों; OAuth के लिए WebView पर भरोसा न करें (WebView डेटा को मुख्य एप्लिकेशन से अलग नहीं करता); स्वचालित Refresh Token रोटेशन लागू करें (प्रत्येक Refresh Token का उपयोग केवल एक बार किया जा सकता है); Android के लिए TrustManager और iOS के लिए URLSession के माध्यम से Certificate Pinning जोड़ें। OpenID Connect Discovery (well-known endpoint) प्राधिकरण सर्वर के सही एंडपॉइंट स्वचालित रूप से निर्धारित करने और फ़िशिंग पृष्ठों पर रीडायरेक्ट से बचने में मदद करता है।