Access Token في تطوير iOS و Android — المفاهيم الأساسية وأنواع التوكنات وكيف يعمل

ما هو Access Token؟

Access Token — هو سلسلة يستخدمها العميل (تطبيق محمول، SPA، خادم) لمصادقة طلبات HTTP إلى نقاط نهاية API المحمية. يتم إصدار الرمز من قبل خادم الترخيص بعد أن يؤكد المستخدم هويته ويمنح التطبيق الأذونات المناسبة (النطاق).

يعتبر access token عنصراً مركزياً في بروتوكول OAuth 2.0 وجميع الأنظمة المبنية عليه — OpenID Connect، Firebase Authentication، Auth0، Keycloak. بدون access token، لن تتم معالجة أي طلب إلى API محمية: يقوم الخادم بإرجاع HTTP 401 Unauthorized. لا يحدد الرمز المستخدم بشكل مباشر — بل يؤكد أن العميل لديه الحق في تنفيذ إجراء معين نيابة عن المستخدم (الترخيص)، وليس من هو المستخدم (المصادقة).

وفقاً لـ Okta، 2025، أكثر من 80% من APIs العامة تستخدم نظام Bearer مع access token في رأس Authorization، مما يحل محل طرق المصادقة القديمة — Basic Auth و API Key. كما أن access token هو الأساس للترخيص المفوض — نموذج يمنح فيه المستخدم للتطبيق وصولاً محدوداً إلى بياناته على خدمة أخرى. على سبيل المثال، عندما يطلب تطبيق محمول لتحرير الصور الوصول إلى Google Drive عبر OAuth 2.0، يرى المستخدم شاشة موافقة تسرد النطاقات المحددة، وبعد التأكيد يحصل على access token بهذه الأذونات.

كيف يعمل Access Token

آلية عمل access token تعتمد على نظام Bearer: يضيف العميل الرأس Authorization: Bearer <token> إلى كل طلب HTTP. يتلقى خادم الموارد (API) الرمز، ويتحقق من صحته، ويحدد الموارد التي يمكن الوصول إليها. يمكن أن يتم التحقق بطريقتين: محلياً (لـ JWT) أو من خلال نقطة نهاية introspection (لـ opaque tokens).

نظام Bearer Token

Bearer token يعني أن أي شخص يقدم الرمز (bearer) يحصل على الوصول المقابل. يفرض هذا متطلبات عالية لحماية الرمز أثناء النقل والتخزين. لا يتطلب نظام Bearer من العميل إثبات ملكية الرمز بشكل تشفيري — يكفي مجرد نقله. لذلك، HTTPS إلزامي: بدون تشفير حركة المرور، يمكن للمهاجم اعتراض الرمز واستخدامه فوراً.

وفقاً لـ Cloudflare، 2025، يحدث اعتراض Bearer token عبر اتصال HTTP غير آمن في المتوسط خلال 12 ثانية بعد إرسال الطلب. استخدام HTTPS و TTL قصير لل access token (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. يمكن للعميل التحقق من الانتهاء بطريقتين: من خلال حقل exp في JWT (محلياً) أو من خلال استجابة HTTP 401 (لـ opaque tokens).

وفقاً لـ Auth0 Best Practices، 2025، TTL الأمثل لـ access token لتطبيقات المحمول هو 15–30 دقيقة. TTL قصير جداً (أقل من 5 دقائق) يخلق حملاً زائداً على نقطة نهاية الرمز عند كل تحديث — مع 10,000 مستخدم و TTL 5 دقائق، يتلقى الخادم ما يصل إلى 2,000 طلب تحديث في الدقيقة في ساعات الذروة. TTL طويل جداً (أكثر من ساعتين) يزيد نافذة الهجوم عند تسرب الرمز — يمكن للمهاجم استخدام الرمز المخترق لعدة ساعات قبل حظر الوصول تلقائياً.

أمان 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) — تنتهي عناوين URL في سجلات الخوادم والمتصفحات.

وفقاً لـ OWASP Mobile Top 10، 2025، التخزين غير الصحيح للرموز على الجهاز (M1: Improper Platform Usage) والنقل غير الآمن للبيانات (M3: Insecure Communication) هما من بين أكثر ثلاث ثغرات محمولة شيوعاً تؤدي إلى اختراق الحسابات. إجراء إضافي — استخدام certificate pinning لجميع الطلبات مع access token: يتحقق العميل من شهادة الخادم ليس فقط من خلال سلسلة CA القياسية، ولكن أيضاً من خلال بصمة الشهادة المحفوظة مسبقاً (SHA-256 fingerprint). يمنع هذا هجمات man-in-the-middle حتى مع اختراق CA.

مثال كود في Kotlin

فيما يلي مثال بلغة Kotlin لنظام Android، يوضح إرسال طلب مع access token في رأس Authorization ومعالجة 401 مع التحديث التلقائي عبر refresh token. يتم استخدام OkHttp مع Interceptor مخصص.

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 واحد يتحقق من حالة الاستجابة ويحدث الرمز عند الضرورة دون تدخل المطور.