Access Token در توسعه iOS و Android — مفاهیم کلیدی، انواع توکن و نحوه عملکرد

Access Token چیست؟

Access Token — رشته‌ای است که کلاینت (برنامه موبایل، SPA، سرور) برای احراز هویت درخواست‌های HTTP به endpointهای محافظت‌شده API استفاده می‌کند. توکن توسط سرور مجوز پس از تأیید هویت کاربر و اعطای مجوزهای مربوطه (scope) به برنامه صادر می‌شود.

Access token عنصر مرکزی پروتکل OAuth 2.0 و تمام سیستم‌های ساخته‌شده بر اساس آن — OpenID Connect، Firebase Authentication، Auth0، Keycloak — است. بدون access token هیچ درخواستی به API محافظت‌شده پردازش نخواهد شد: سرور HTTP 401 Unauthorized برمی‌گرداند. توکن مستقیماً کاربر را شناسایی نمی‌کند — تأیید می‌کند که کلاینت حق انجام عمل خاصی را از طرف کاربر دارد (مجوزدهی)، نه اینکه کاربر کیست (احراز هویت).

طبق داده‌های Okta، 2025، بیش از 80٪ از APIهای عمومی از Bearer scheme با access token در هدر Authorization استفاده می‌کنند و روش‌های قدیمی احراز هویت — Basic Auth و API Key — را کنار می‌گذارند. Access token همچنین اساس delegated authorization — مدلی که در آن کاربر به برنامه دسترسی محدود به داده‌های خود در سرویس دیگر می‌دهد — است. به عنوان مثال، هنگامی که یک برنامه موبایل ویرایش عکس از طریق OAuth 2.0 به Google Drive دسترسی درخواست می‌کند، کاربر صفحه رضایت با scopeهای مشخص را می‌بیند و پس از تأیید، access token با این مجوزها دریافت می‌کند.

Access Token چگونه کار می‌کند

مکانیزم کار access token بر اساس Bearer scheme است: کلاینت هدر Authorization: Bearer <token> را به هر درخواست HTTP اضافه می‌کند. سرور منابع (API) توکن را دریافت کرده، اعتبار آن را بررسی می‌کند و مشخص می‌کند که چه منابعی در دسترس هستند. بررسی می‌تواند به دو صورت انجام شود: محلی (برای JWT) یا از طریق introspection endpoint (برای opaque token).

Bearer Token scheme

Bearer token به این معنی است که هر کس توکن را ارائه دهد (bearer — دارنده)، دسترسی مربوطه را دریافت می‌کند. این الزامات بالایی برای محافظت از توکن در هنگام انتقال و ذخیره‌سازی ایجاد می‌کند. Bearer scheme از کلاینت نمی‌خواهد که مالکیت توکن را به صورت رمزنگاری اثبات کند — فقط کافی است آن را ارسال کند. بنابراین HTTPS اجباری است: بدون رمزنگاری ترافیک، مهاجم می‌تواند توکن را رهگیری کرده و بلافاصله از آن استفاده کند.

طبق داده‌های Cloudflare، 2025، رهگیری Bearer token از طریق اتصال HTTP محافظت‌نشده به طور متوسط ۱۲ ثانیه پس از ارسال درخواست اتفاق می‌افتد. استفاده از HTTPS و TTL کوتاه access token (15–30 دقیقه) خطر را عملاً به صفر می‌رساند. حفاظت اضافی در سطح برنامه — بررسی origin درخواست از طریق OAuth 2.0 Token Binding (RFC 8471): کلاینت مالکیت کلید TLS مرتبط با توکن را اثبات می‌کند که سرقت توکن از طریق رهگیری را بی‌فایده می‌کند.

انواع Access Token

Access token در دو فرمت وجود دارد: opaque (غیرشفاف) و JWT (خودکفا). انتخاب بین آنها یکی از تصمیمات کلیدی معماری در طراحی سیستم احراز هویت است.

Opaque در مقابل JWT

Opaque token برای سیستم‌هایی که نیاز به لغو فوری دسترسی و بررسی متمرکز مجوزها دارند ترجیح داده می‌شود. JWT — برای معماری میکروسرویسی که عملکرد و به حداقل رساندن تماس‌های شبکه مهم است. بسیاری از ارائه‌دهندگان (Auth0, Keycloak) هر دو فرمت را پشتیبانی می‌کنند و امکان تنظیم نوع توکن را برای هر کلاینت فراهم می‌کنند. انتخاب بین opaque و JWT یک مصالحه بین کنترل و عملکرد است: opaque کنترل کامل را به سرور می‌دهد، JWT — حداقل تأخیر را.

چرخه حیات Access Token

چرخه حیات access token از چهار فاز تشکیل شده است: صدور (issuance)، انتقال، استفاده و انقضا. هر فاز الزامات امنیتی و محدودیت‌های پروتکلی خود را دارد.

انقضا و تمدید

Access token عمر محدودی دارد — معمولاً 15–60 دقیقه. مقدار expires_in در پاسخ سرور مجوز هنگام صدور توکن مشخص می‌شود. پس از پایان این مدت، توکن نامعتبر می‌شود و کلاینت باید از طریق مکانیزم refresh token یک توکن جدید دریافت کند. کلاینت می‌تواند انقضا را به دو روش بررسی کند: از طریق فیلد exp در JWT (محلی) یا از طریق پاسخ HTTP 401 (برای opaque token).

طبق داده‌های Auth0 Best Practices، 2025، TTL بهینه access token برای برنامه‌های موبایل 15–30 دقیقه است. TTL خیلی کوتاه (کمتر از 5 دقیقه) بار اضافی بر روی token endpoint در هر تمدید ایجاد می‌کند — با ۱۰۰۰۰ کاربر و TTL 5 دقیقه، سرور تا ۲۰۰۰ درخواست تمدید در دقیقه در ساعات اوج دریافت می‌کند. 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? {
        // خواندن از 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 واحد عبور می‌کنند که وضعیت پاسخ را بررسی می‌کند و در صورت لزوم توکن را بدون دخالت برنامه‌نویس تمدید می‌کند.