موبائل ایپس کے لیے 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 کی جانچ)۔ کلائنٹ grant_type=refresh_token اور درخواست کے باڈی میں refresh_token کے ساتھ سرور کے ٹوکن endpoint کو 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-ٹوکن"
}

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۔ ٹوکن فائل سسٹم کی سطح پر خفیہ کردہ ہے اور root رسائی کے باوجود بھی ناقابل رسائی رہتا ہے۔ ممنوع: SharedPreferences، NSUserDefaults، سادہ متن والی فائلوں یا بغیر خفیہ کاری کے Base64 میں refresh_token کو ذخیرہ کرنا۔

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 کے لیے ایک "استعمال شدہ" جھنڈا ذخیرہ کرتا ہے۔ تجدید کی درخواست پر، سرور جانچ کرتا ہے — اگر 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
    }
}