Refresh Token मोबाइल ऐप्प्स के लिए — सार, रिफ्रेश तंत्र और सुरक्षित भंडारण

Refresh Token क्या है?

Refresh Token एक क्रेडेंशियल है जिसका उपयोग क्लाइंट एप्लिकेशन वर्तमान access token की समाप्ति के बाद नया access token प्राप्त करने के लिए करता है। access token के विपरीत, refresh_token हर API अनुरोध के साथ नहीं भेजा जाता है — यह क्लाइंट पर एक सुरक्षित भंडार में रखा जाता है और केवल प्रमाणीकरण सर्वर के टोकन endpoint से संपर्क करते समय उपयोग किया जाता है।

मुख्य विचार अलग-अलग जीवनकाल वाले दो टोकन को अलग करना है। छोटे TTL वाला access_token इंटरसेप्ट होने पर हमले की विंडो को कम करता है: यदि access_token चोरी हो जाता है, तो हमलावर इसे केवल कुछ मिनटों के लिए उपयोग कर सकता है। Refresh Token इस तथ्य से सुरक्षित है कि यह सामान्य अनुरोधों के साथ कभी प्रेषित नहीं होता — केवल टोकन endpoint के लिए एक सुरक्षित चैनल के माध्यम से। यह इसकी चोरी को काफी कठिन बना देता है।

OAuth Security Workshop, 2025 के अनुसार, एकल लंबे समय तक चलने वाले access_token को संग्रहीत करने की तुलना में refresh token rotation को लागू करने से सत्र से समझौता होने का जोखिम 85% कम हो जाता है।

Refresh Token कैसे काम करता है

रिफ्रेश प्रक्रिया तब शुरू होती है जब क्लाइंट को HTTP 401 Unauthorized प्रतिक्रिया मिलती है या पता चलता है कि access_token समाप्त हो गया है (JWT में exp की जाँच)। क्लाइंट सर्वर के टोकन endpoint पर grant_type=refresh_token और अनुरोध निकाय में refresh_token के साथ POST अनुरोध भेजता है। सर्वर refresh_token की वैधता, उसकी समाप्ति और client_id से उसके जुड़ाव की जाँच करता है। यदि सब कुछ सही है — सर्वर एक नया access_token और, वैकल्पिक रूप से, एक नया refresh_token लौटाता है।

टोकन रिफ्रेश प्रवाह

रिफ्रेश अनुरोध योजना इस प्रकार दिखती है: क्लाइंट /oauth/token पर पैरामीटर grant_type=refresh_token, refresh_token={token} और client_id={id} के साथ POST भेजता है। सर्वर नए access_token और समाप्ति के साथ JSON लौटाता है:

{
  "access_token": "eyJhbGciOi...नया-टोकन",
  "token_type": "Bearer",
  "expires_in": 1800,
  "refresh_token": "नया-refresh-token"
}

Refresh token rotation (नया refresh_token लौटाना) OAuth 2.0 Security Best Current Practice (RFC 9700) द्वारा अनुशंसित है। पुराना refresh_token उसी समय अमान्य कर दिया जाता है। यदि किसी हमलावर ने पुराना refresh_token चुरा लिया और वैध क्लाइंट से पहले इसका उपयोग करने में सफल रहा, तो सर्वर पुन: उपयोग का पता लगाता है — reuse detection — और पूरे सत्र को अवरुद्ध कर देता है।

Refresh Token बनाम Access Token

Access token और refresh_token विभिन्न कार्य करते हैं और मौलिक रूप से भिन्न सुरक्षा विशेषताएँ रखते हैं। access_token API के लिए एक अस्थायी पास है, जबकि refresh_token नए पास प्राप्त करने के लिए एक दीर्घकालिक अनुमति है।

access_token लंबे समय तक क्यों नहीं चल सकता

access_token के लिए छोटा TTL एक जानबूझकर सुरक्षा समझौता है। यदि access_token चोरी हो जाता है (ट्रैफ़िक इंटरसेप्शन, लॉग लीकेज, या डिवाइस पर मैलवेयर के माध्यम से), तो जिस अवधि के दौरान हमलावर इसका उपयोग कर सकता है वह 15–60 मिनट तक सीमित है। refresh_token सुरक्षित है क्योंकि यह हर अनुरोध के साथ कभी प्रेषित नहीं होता — इसे इंटरसेप्ट करने के लिए टोकन endpoint पर लक्षित हमले की आवश्यकता होती है। Auth0 Security Team, 2025 के अनुसार, 90% समझौता किए गए access_token असुरक्षित नेटवर्क कनेक्शन के माध्यम से इंटरसेप्ट किए गए थे — ठीक वही जिससे refresh_token अपनी वास्तुकला द्वारा सुरक्षित है।

Refresh Token सुरक्षा

refresh_token की सुरक्षा संपूर्ण प्रमाणीकरण योजना का एक महत्वपूर्ण तत्व है। चूँकि refresh_token विस्तारित अवधि के लिए खाते तक पूर्ण पहुँच प्रदान करता है, इसलिए इसकी सुरक्षा अधिकतम होनी चाहिए। OWASP और OAuth Security Best Practices विशिष्ट आवश्यकताएँ प्रकाशित करते हैं।

मोबाइल उपकरणों पर refresh token संग्रहीत करना

उचित भंडारण प्लेटफ़ॉर्म पर निर्भर करता है। iOS पर — kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly एक्सेस के साथ Keychain। यह सुनिश्चित करता है कि डिवाइस पासकोड हटाए जाने पर टोकन दुर्गम है। Android पर — Android Keystore में मास्टर कुंजी के साथ AndroidX Security लाइब्रेरी से EncryptedSharedPreferences। टोकन फ़ाइल सिस्टम स्तर पर एन्क्रिप्ट किया जाता है और रूट एक्सेस के साथ भी दुर्गम रहता है। निषिद्ध: refresh_token को SharedPreferences, NSUserDefaults, प्लेन-टेक्स्ट फ़ाइलों या एन्क्रिप्शन के बिना Base64 में संग्रहीत करना।

Google Security Blog, 2025 के अनुसार, AES256-GCM के साथ EncryptedSharedPreferences, डिवाइस तक भौतिक पहुँच होने पर सामान्य SharedPreferences की तुलना में टोकन लीकेज के जोखिम को 99.7% कम करता है। सुरक्षा बढ़ाने के लिए, भंडारण को अलग करने की भी सिफारिश की जाती है: access_token मेमोरी में (अल्पकालिक पहुँच) संग्रहीत किया जा सकता है, जबकि refresh_token केवल संरक्षित सिस्टम भंडारण (Keychain / Keystore) में संग्रहीत किया जाना चाहिए। यदि ऐप को सिस्टम से foreground सिग्नल मिलता है, तो उपयोगकर्ता के इंटरैक्ट करना शुरू करने से पहले refresh_token की वैधता की जाँच की जाती है और यदि आवश्यक हो तो नवीनीकृत किया जाता है।

Refresh Token Rotation

Refresh token rotation एक तंत्र है जहाँ access_token को रिफ्रेश करने का प्रत्येक अनुरोध एक नया refresh_token लौटाता है, और पुराना रद्द कर दिया जाता है। यदि किसी हमलावर ने refresh_token चुरा लिया और इसका उपयोग करता है, तो वैध क्लाइंट को अगले रिफ्रेश प्रयास पर एक त्रुटि मिलेगी — सर्वर पता लगाता है कि refresh_token पहले ही उपयोग किया जा चुका है (reuse detection)। Rotation, मोबाइल वातावरण में लंबे समय तक चलने वाले टोकन के साथ काम करने वाले सभी सिस्टम के लिए OAuth 2.0 Security Best Current Practice (RFC 9700) की एक अनिवार्य अनुशंसा है।

पुन: उपयोग का पता लगाना

पता लगाने का एल्गोरिदम इस प्रकार काम करता है: सर्वर प्रत्येक जारी किए गए refresh_token के लिए डेटाबेस में एक "used" फ़्लैग संग्रहीत करता है। रिफ्रेश अनुरोध पर, सर्वर जाँचता है — यदि refresh_token पहले से उपयोग किए गए के रूप में चिह्नित है, तो पुन: उपयोग का प्रयास हुआ है। सर्वर तुरंत उस सत्र के सभी refresh_token को अमान्य कर देता है और पहुँच अवरुद्ध कर देता है। वैध उपयोगकर्ता को लॉगिन पृष्ठ पर पुनर्निर्देशित किया जाता है। यह refresh_token चोरी के हमलों को रोकता है: हमलावर को पहुँच मिलती है, लेकिन पता चलते ही सत्र अवरुद्ध हो जाता है।

OAuth Security Workshop, 2025 के अनुसार, rotation + reuse detection को लागू करने से चुराए गए refresh_token के माध्यम से सफल हमले की संभावना 23% से घटकर 0.3% हो जाती है। पुन: उपयोग का पता लगाने को लागू करने के लिए, सर्वर client_id के साथ जारी किए गए अंतिम refresh_token के हैश को संग्रहीत करता है। रिफ्रेश अनुरोध पर, सर्वर प्रस्तुत refresh_token की तुलना संग्रहीत से करता है — यदि वे मेल नहीं खाते हैं, तो पुन: उपयोग हुआ है और पूरी टोकन श्रृंखला रद्द कर दी जाती है।

invalid_grant त्रुटि प्राप्त करने पर, क्लाइंट को पूर्ण लॉगआउट करना होगा: सभी संग्रहीत टोकन (access और refresh) साफ़ करें, डिवाइस पर वर्तमान सत्र समाप्त करें, और उपयोगकर्ता को लॉगिन स्क्रीन पर पुनर्निर्देशित करें। पुन: प्रमाणीकरण पिछली श्रृंखला से असंबंधित एक नई टोकन श्रृंखला बनाता है। इस त्रुटि को अनदेखा करना और रिफ्रेश का पुन: प्रयास करना पुन: उपयोग का पता लगने के कारण अवरोध का कारण बनेगा।

Kotlin में कार्यान्वयन

Android के लिए Kotlin में क्लाइंट-साइड टोकन रिफ्रेश को लागू करने का एक उदाहरण। ऐप HTTP 401 प्रतिक्रिया को इंटरसेप्ट करता है, रिफ्रेश अनुरोध को ट्रिगर करता है, और नए access_token के साथ मूल अनुरोध को पुन: प्रयास करता है। OkHttp Interceptor का उपयोग किया जाता है — प्रत्येक अनुरोध में तर्क को दोहराए बिना स्वचालित टोकन प्रबंधन के लिए एक महत्वपूर्ण घटक।

class AuthInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val accessToken = getAccessToken()
        val authRequest = request.newBuilder()
            .addHeader("Authorization", "Bearer $accessToken")
            .build()

        val response = chain.proceed(authRequest)
        if (response.code != 401) return response

        // Access token समाप्त हो गया — refresh token के माध्यम से रिफ्रेश कर रहे हैं
        val newToken = refreshAccessToken() ?: return response
        return chain.proceed(request.newBuilder()
            .addHeader("Authorization", "Bearer $newToken")
            .build())
    }

    private fun refreshAccessToken(): String? {
        val refreshToken = getRefreshToken() ?: return null
        val client = OkHttpClient()
        val body = FormBody.Builder()
            .add("grant_type", "refresh_token")
            .add("refresh_token", refreshToken)
            .build()

        val request = Request.Builder()
            .url("https://auth.example.com/oauth/token")
            .post(body)
            .build()

        val response = client.newCall(request).execute()
        val json = JSONObject(response.body?.string() ?: return null)
        val newAccessToken = json.getString("access_token")
        // rotation के दौरान नया refresh token सहेजें
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}