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 के साथ भी 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 से गुज़रते हैं जो प्रतिक्रिया स्थिति की जाँच करता है और डेवलपर की भागीदारी के बिना आवश्यकता होने पर टोकन को नवीनीकृत करता है।