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% এর বেশি পাবলিক API 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-র সাথেও man-in-the-middle আক্রমণ প্রতিরোধ করে।

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-এর মধ্য দিয়ে যায় যা প্রতিক্রিয়া স্থিতি পরীক্ষা করে এবং ডেভেলপারের অংশগ্রহণ ছাড়াই প্রয়োজন হলে টোকেন পুনর্নবীকরণ করে।