iOS اور Android ڈویلپمنٹ میں Access Token — کلیدی تصورات، ٹوکن کی اقسام اور یہ کیسے کام کرتا ہے

Access Token کیا ہے؟

Access Token — ایک سٹرنگ ہے جسے کلائنٹ (موبائل ایپ، SPA، سرور) محفوظ API اینڈپوائنٹس پر HTTP درخواستوں کی تصدیق کے لیے استعمال کرتا ہے۔ ٹوکن اجازت نامہ سرور کے ذریعے جاری کیا جاتا ہے جب صارف اپنی شناخت کی تصدیق کرتا ہے اور ایپلیکیشن کو مناسب اجازتیں (scope) دیتا ہے۔

Access token OAuth 2.0 پروٹوکول اور اس پر بنائے گئے تمام سسٹمز — OpenID Connect، Firebase Authentication، Auth0، Keycloak — کا مرکزی عنصر ہے۔ Access token کے بغیر، محفوظ API پر کوئی درخواست عمل میں نہیں آئے گی: سرور HTTP 401 Unauthorized لوٹاتا ہے۔ ٹوکن صارف کی براہ راست شناخت نہیں کرتا — یہ تصدیق کرتا ہے کہ کلائنٹ کو صارف کی طرف سے کوئی مخصوص کارروائی کرنے کا حق ہے (اجازت)، نہ کہ صارف کون ہے (تصدیق)۔

Okta، 2025 کے مطابق، 80% سے زیادہ عوامی APIs Authorization ہیڈر میں access token کے ساتھ Bearer اسکیما استعمال کرتی ہیں، پرانے تصدیقی طریقوں — Basic Auth اور API Key — کو ختم کرتی ہوئی۔ Access token تفویض کردہ اجازت (delegated authorization) کی بنیاد بھی ہے — ایک ماڈل جس میں صارف کسی ایپلیکیشن کو کسی دوسری سروس پر اپنے ڈیٹا تک محدود رسائی دیتا ہے۔ مثال کے طور پر، جب کوئی فوٹو ایڈیٹنگ موبائل ایپ OAuth 2.0 کے ذریعے Google Drive تک رسائی کی درخواست کرتی ہے، صارف مخصوص scopes کی فہرست والی ایک رضامندی کی سکرین دیکھتا ہے، اور تصدیق کے بعد ان اجازتوں کے ساتھ ایک access token حاصل کرتا ہے۔

Access Token کیسے کام کرتا ہے

میکانزم access token Bearer اسکیما پر مبنی ہے: کلائنٹ ہر HTTP درخواست میں Authorization: Bearer <token> ہیڈر شامل کرتا ہے۔ وسائل کا سرور (API) ٹوکن وصول کرتا ہے، اسے توثیق کرتا ہے، اور طے کرتا ہے کہ کن وسائل تک رسائی ہے۔ توثیق دو طریقوں سے ہو سکتی ہے: مقامی طور پر (JWT کے لیے) یا introspection اینڈپوائنٹ کے ذریعے (opaque ٹوکن کے لیے)۔

Bearer Token اسکیما

Bearer token کا مطلب ہے کہ جو کوئی بھی ٹوکن پیش کرتا ہے (bearer) اسے متعلقہ رسائی مل جاتی ہے۔ یہ ٹرانسمیشن اور اسٹوریج کے دوران ٹوکن کے تحفظ کے لیے اعلیٰ تقاضے عائد کرتا ہے۔ Bearer اسکیما کے لیے کلائنٹ کو کرپٹوگرافی طور پر ٹوکن کی ملکیت ثابت کرنے کی ضرورت نہیں ہے — صرف اسے منتقل کرنا کافی ہے۔ لہذا، HTTPS لازمی ہے: ٹریفک انکرپشن کے بغیر، حملہ آور ٹوکن کو روک سکتا ہے اور فوری طور پر استعمال کر سکتا ہے۔

Cloudflare، 2025 کے مطابق، غیر محفوظ HTTP کنکشن پر Bearer token کی روک تھام درخواست بھیجنے کے بعد اوسطاً 12 سیکنڈ میں ہوتی ہے۔ HTTPS اور مختصر access token TTL (15–30 منٹ) کا استعمال خطرے کو تقریباً صفر کر دیتا ہے۔ اضافی ایپلیکیشن سطح کا تحفظ — OAuth 2.0 Token Binding (RFC 8471) کے ذریعے درخواست کی اصل کی تصدیق: کلائنٹ ٹوکن سے منسلک TLS کلید کی ملکیت ثابت کرتا ہے، جس سے روک تھام کے ذریعے ٹوکن چوری بے کار ہو جاتی ہے۔

Access Token کی اقسام

Access Token دو فارمیٹس میں موجود ہے: opaque اور JWT (خود کفیل)۔ ان کے درمیان انتخاب تصدیقی نظام کو ڈیزائن کرتے وقت اہم آرکیٹیکچرل فیصلوں میں سے ایک ہے۔

Opaque vs JWT

Opaque token ان سسٹمز کے لیے ترجیح دی جاتا ہے جنہیں فوری رسائی منسوخی اور مرکزی حقوق کی تصدیق کی ضرورت ہوتی ہے۔ JWT مائیکرو سروسز آرکیٹیکچر کے لیے ہے جہاں کارکردگی اور نیٹ ورک کالز کو کم سے کم کرنا اہم ہے۔ بہت سے فراہم کنندگان (Auth0، Keycloak) دونوں فارمیٹس کو سپورٹ کرتے ہیں اور ہر کلائنٹ کے لیے ٹوکن کی قسم ترتیب دینے کی اجازت دیتے ہیں۔ Opaque اور JWT کے درمیان انتخاب کنٹرول اور کارکردگی کے درمیان ایک سمجھوتہ ہے: opaque سرور کو مکمل کنٹرول دیتا ہے، JWT کم سے کم تاخیر فراہم کرتا ہے۔

Access Token کا لائف سائیکل

لائف سائیکل access token چار مراحل پر مشتمل ہے: جاری کرنا، منتقلی، استعمال اور میعاد ختم ہونا۔ ہر مرحلے کی اپنی حفاظتی ضروریات اور پروٹوکول کی حدود ہیں۔

میعاد ختم ہونا اور تجدید

Access Token کی محدود عمر ہوتی ہے — عام طور پر 15–60 منٹ۔ expires_in کی قدر ٹوکن جاری کرتے وقت اجازت نامہ سرور کے جواب میں بتائی جاتی ہے۔ اس وقت کے بعد، ٹوکن نا کار ہو جاتا ہے اور کلائنٹ کو refresh token میکانزم کے ذریعے نیا ٹوکن حاصل کرنا ہوتا ہے۔ کلائنٹ دو طریقوں سے میعاد ختم ہونے کی جانچ کر سکتا ہے: JWT میں exp فیلڈ سے (مقامی طور پر) یا HTTP 401 جواب سے (opaque ٹوکن کے لیے)۔

Auth0 Best Practices، 2025 کے مطابق، موبائل ایپلیکیشنز کے لیے بہترین access token TTL 15–30 منٹ ہے۔ بہت چھوٹا TTL (5 منٹ سے کم) ہر تجدید پر ٹوکن اینڈپوائنٹ پر ضرورت سے زیادہ بوجھ ڈالتا ہے — 10,000 صارفین اور 5 منٹ کے TTL کے ساتھ، سرور کو عروج کے اوقات میں فی منٹ 2,000 تجدید کی درخواستیں موصول ہوتی ہیں۔ بہت لمبا TTL (2 گھنٹے سے زیادہ) ٹوکن لیک ہونے پر حملے کی کھڑکی بڑھاتا ہے — حملہ آور رسائی خود بخود مسدود ہونے سے پہلے کئی گھنٹوں تک سمجھوتہ شدہ ٹوکن استعمال کر سکتا ہے۔

Access Token سیکیورٹی

سیکیورٹی access token کی سیکیورٹی تمام مراحل میں یقینی بنائی جانی چاہیے: ڈیوائس پر اسٹوریج کے دوران، نیٹ ورک پر منتقلی کے دوران اور سرور پر پروسیسنگ کے دوران۔ بنیادی سفارش یہ ہے کہ access token کو کبھی بھی ان جگہوں پر ذخیرہ نہ کریں جو دوسری ایپلیکیشنز یا پروسیسز کے لیے قابل رسائی ہوں۔

ذخیرہ اور منتقلی کے دوران تحفظ

موبائل ڈیوائسز پر، access token ذخیرہ کیا جاتا ہے: iOS پر — Keychain میں kSecAttrAccessibleAfterFirstUnlock وصف کے ساتھ (ٹوکن پہلی انلاک کے بعد قابل رسائی ہوتا ہے، چاہے ڈیوائس مقفل ہو — بیک گراؤنڈ اپ ڈیٹس کے لیے)؛ Android پر — EncryptedSharedPreferences میں۔ Access token کو کبھی NSUserDefaults، SharedPreferences، بیرونی اسٹوریج پر فائلوں یا ایپلیکیشن لاگز میں محفوظ نہیں کرنا چاہیے۔ منتقلی کے دوران — صرف HTTPS TLS 1.3 یا 1.2 کے ساتھ۔ ہر API درخواست کے لیے، access token کو Authorization: Bearer ہیڈر میں بھیجا جانا چاہیے، URL پیرامیٹرز (query string) میں نہیں — URLs سرور اور براؤزر لاگز میں محفوظ ہو جاتے ہیں۔

OWASP Mobile Top 10، 2025 کے مطابق، ڈیوائس پر ٹوکن کا نامناسب ذخیرہ (M1: Improper Platform Usage) اور غیر محفوظ ڈیٹا منتقلی (M3: Insecure Communication) اکاؤنٹ کے سمجھوتہ کرنے والی تین سب سے عام موبائل کمزوریوں میں شامل ہیں۔ ایک اضافی اقدام — access token والی تمام درخواستوں کے لیے certificate pinning کا استعمال: کلائنٹ صرف معیاری CA چین کے ذریعے ہی نہیں بلکہ پہلے سے محفوظ کردہ سرٹیفکیٹ فنگر پرنٹ (SHA-256 fingerprint) کے ذریعے بھی سرور کے سرٹیفکیٹ کی تصدیق کرتا ہے۔ یہ سمجھوتہ شدہ CA کے ساتھ بھی مین-ان-دی-مڈل حملوں کو روکتا ہے۔

Kotlin میں کوڈ مثال

ذیل میں Android کے لیے Kotlin میں ایک مثال ہے، جو Authorization ہیڈر میں access token کے ساتھ درخواست بھیجنے اور refresh token کے ذریعے خودکار تجدید کے ساتھ 401 کو ہینڈل کرنے کا مظاہرہ کرتی ہے۔ کسٹم Interceptor کے ساتھ OkHttp استعمال کیا گیا ہے۔

data class TokenStore {
    fun getAccessToken(): String? {
        // Reading from EncryptedSharedPreferences
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

مثال دو طریقے دکھاتی ہے: خودکار ٹوکن مینجمنٹ کے لیے OkHttp Interceptor کا استعمال اور HttpURLConnection کے ذریعے براہ راست بھیجنا۔ OkHttp Interceptor کو ترجیح دی جاتی ہے — یہ ٹوکن شامل کرنے اور تجدید کرنے کی منطق کو مرکزی بناتا ہے، ہر درخواست میں کوڈ کی نقل کو ختم کرتا ہے۔ تمام درخواستیں ایک ہی interceptor سے گزرتی ہیں جو جواب کی حالت چیک کرتا ہے اور ڈویلپر کی مداخلت کے بغیر ضرورت پڑنے پر ٹوکن کی تجدید کرتا ہے۔